Hallo,
wir haben schon vor einiger Zeit einen EX2016 in Betrieb genommen, um den EX2010 außer Betrieb nehmen zu können. Grundsätzlich hat die Inbetriebnahme (auch wegen der sehr guten Anleitungen hier) gut funktioniert. Nachdem alle Mailboxen nach und nach auf den EX2016 migriert sind, soll der alte EX2010 zurückgebaut werden. Hierbei bin ich dann auf drei Arbitration-Mailboxen und die DiscoverySearchMailbox gestoßen. Nach einigem Lesen und der Erkenntnis, dass diese Mailboxen auch auf den EX2016 migriert werden sollen (müssen), habe ich mittels ECP einen Migrationsjob mit diesen vier Mailboxen erstellt und gestartet.
Als nach ein paar Tagen kein Fortschritt zu erkennen war (alle vier Mailboxen hingen im Status "queued") habe ich den Job gestoppt und gelöscht. Ich habe daraufhin weiter recherchiert und herausgefunden, dass neue Migrationsjobs immer in "StatusDetails" den Wert "StalledDueToTarget_ContentIndexing" haben. Deshalb habe ich den Status der DBs überprüft und festgestellt, dass die Ziel-DB der Migrationsjobs nicht "Healthy" gewesen ist. Nachdem ich dieses Problem beheben konnte, verharren neue Jobs aber weiter im o.g. Status - selbst dann, wenn ich die Indizierung ausschalte. Was ich bei neuen Migrationsjobs allerdings merkwürdig finde, ist der Zeitstempel des Jobs - das ist nämlich der Zeitpunkt meines ersten Migrationsversuchs der vier Mailboxen und nicht der aktuelle Zeitpunkt. Auch kann ich in den Details des MoveRequest sehen, dass vier Elemente verarbeitet werden sollen, obwohl ich in den neuen Jobs immer nur eine einzelne Mailbox migrieren möchte...
Für mich sieht es danach aus, dass der erste Versuch mit allen vier Mailboxen noch irgendwo "gepuffert" ist und sobald ich eine der vier betroffenen Mailboxen verschieben möchte der Status des alten Jobs aktiv wird. Was kann ich machen?
Lösch den Job doch einfach nochmal und schieb den Kram einfach rüber per
get-mailbox -server alterexchange -arbitration | new-moverequest -targetDB irgendeineDBauf2016
Den „alten“ Job habe ich schon gelöscht, get-moverequest liefert kein Ergebnis. Erstelle ich dann einen neuen moverequest mit einem der vier Postfächer, bleibt er wieder im selben Status hängen. Wenn ich dann mit
get-moverequest | get-moverequeststatistics | fl
die Details abfrage, ist die letzte Aktualisierung des Jobs der 28.12.2020! Das ist der Tag, an dem ich erstmalig versucht hatte, die Postfächer zu migrieren.
Ich habe auch schon mal testweise die Postfächer innerhalb des alten Exchange verschoben, das ging ohne Probleme. Eine andere ZielDB auf dem Exchange16 hat auch nichts gebracht...
Nach weiterer Recherche bin ich auf die Problematik der fehlenden Sicherheitsgruppe "Content Submitters" gestoßen - könnte das die Ursache sein?
Sonst keiner eine Idee?
Nach weiterer Recherche bin ich auf die Problematik der fehlenden Sicherheitsgruppe "Content Submitters" gestoßen - könnte das die Ursache sein?
Sonst keiner eine Idee?
Das Erstellen der genannten Gruppe und Zuweisen der nötigen Rechte hat nichts gebracht... Nach Erstellen eines neuen Moverequest zeigen die Moverequeststatistics die Werte von Dezember 20 an, als wenn die Postfächer eine Art "Flag" hätten, was signalisieren soll, dass da der alte Job noch Zugriff drauf hat!?
Bei der weiteren Recherche bin ich auf den Hinweise gestoßen, die Probleme könnten mit Fehlern in der AD-Replikation zu tun haben. Ich habe dann bei einem DC tatsächlich feststellen können, dass dieser sich nicht mit den anderen beiden DCs austauschen kann, der Ordner "Policies" im SYSVOL-Verzeichnis auf den lokalen Platten waren bei diesem einen DC älter als auf den anderen beiden (die hatten die selben Versionen). Unglücklicherweise war genau dieser "veraltete" DC der "ConfigurationServer" vom Exchange. Die Fehler, die im Eventlog des Exchange zu finden waren, tauchen nicht mehr auf, seitdem ich den "alten" DC heruntergefahren habe. Gebracht hat mir das jetzt allerdings wenig, neue Moverequest landen immer noch im selben Status mit den selben Details von Dezember 20 ?
Könnte es hilfreich sein, den Exchange-Repliaktionsdienst neuzustarten und kann ich das gefahrlos im laufenden Betrieb machen?
Könnte es hilfreich sein, den Exchange-Repliaktionsdienst neuzustarten und kann ich das gefahrlos im laufenden Betrieb machen?
Schaden kanns nicht. Was soll denn passieren?
Schaden kanns nicht. Was soll denn passieren?
Ich hätte einen Totalabsturz nicht mehr ausgeschlossen, so fragil, wie sich das alles gibt...
Am Ende des Tages habe ich den Server neugestartet, womit letztlich dieser "gepuffferte" Zustand endlich weg ist und die Postfächer migriert werden konnten. Das hat aber auch erst etwas gebracht, nachdem der kappute DC aus war. Da sind wohl einige unsaubere Umstände/Zustände zusammen gekommen.