Migration von MSX2010 auf MSX2016 - Postfachmigration hängt

[MrCocktail 192]

Hi,

 

Im Zweifel versuche doch den Job zu pausieren, dann mit der Prio Emergency zu versehen und wieder anzustarten.

 

 

Gruß

J

[dataKEKS 11]

Leute, ihr glaubt es nicht!

 

Wir haben wirklich alles richtig gemacht bei der Migration, die Quelle der Probleme lag leider wie so oft komplett wo anders...

 

Auch wenn ich euch technisch leider nicht wirklich die Ursache erklären kann, die NTDS.dit auf dem Quellserver (das war mal ne Zweiserver Umgebung mit DC + MSX + + + auf der einen Maschine sowie ein TS) wurde mittlerweile eine sauber aufgeteilte Umgebung mit einem reinen Exchange Server, aber das ändert natürlich nichts mehr am Verhalten des alten Exchange.

 

Ja, mit Eventlog prüfen in allen Unterbereichen hätte es mir auch früher auffallen können, ich wurde stutzig als mir der Quellserver in der Powershell noch Postfächer für die Datenbank angezeigt hat die schon migriert waren und so kam ich dann eben erst auf die Idee mal wieder ins Eventlog zu sehen...

 

Fehlerbild waren diverse Fehlermeldungen, angefangen bei NTDS (696) NTDSA: Datenbank C:\Windows\NTDS\ntds.dit: Index DRA_USN_index von Tabelle datatable ist beschädigt (0).

 

Noch detailierter wurde es hier:

 

Dieses Ereignis enthält Reparaturvorgänge für das Ereignis "1084", das zuvor protokolliert wurde. Diese Meldung deutet auf ein bestimmtes Problem in Bezug auf die Konsistenz der Active Directory-Domänendienste-Datenbank für dieses Replikationsziel hin. Bei der Übernahme von Replikationsänderungen für das folgende Objekt ist ein Datenbankfehler aufgetreten. Die Datenbank enthält nicht erwartete Inhalte, die verhindern, dass die Änderung durchgeführt wird.

 

Objekt:

CN=Ruiter Tanja,OU=Lehrer,OU=Benutzer,..............

Objekt-GUID:

203ca1ec-0077-4aee-ba28-d3779e42b61a 

Quell-DC:

db2753ff-5192-4b96-867e-c998ef49e18e._msdcs...........

 

Benutzeraktion

 

 Weitere Informationen finden Sie im KB-Artikel 837932 unter "http://support.microsoft.com/?id=837932".Ein Teil der Reparaturvorgänge ist dort aufgelistet.

 1. Stellen Sie sicher, dass genügend freier Speicherplatz auf den Volumes vorhanden ist, auf denen die Directory-Datenbank gehostet wird, und wiederholen Sie den Vorgang. Stellen Sie sicher, dass sich die physikalischen Laufwerke, auf denen NTDS.DIT und die Protokolldateien gehostet werden, nicht auf Laufwerke befinden, auf denen NTFS-Komprimierung aktiviert ist. Prüfen Sie, ob Antivirussoftware auf diese Volumes zugreift.

 2. Es ist eventuell vorteilhaft, wenn der Sicherheitsbeschreibungspropagierer gezwungen wird, die Objektcontainerherkunft in der Datenbank erneut zu erstellen. Dies kann entsprechend den Anweisungen im KB-Artikel 251343 unter "http://support.microsoft.com/?id=251343"durchgeführt werden.

 3. Das Problem kann ggf. auch beim übergeordneten Objekt auf diesem Domänencontroller auftreten. Verschieben Sie das Objekt auf dem Quell-DC zu einem anderen übergeordneten Objekt.

 4. Wenn dieser Computer ein globaler Katalog ist und der Fehler in einer der schreibgeschützten Partitionen auftritt, sollten Sie den Computer als globalen Katalog über das Kontrollkästchen "Globaler Katalog" in der Anwendung "Standorte und Dienste" herabstufen. Wenn der Fehler auf einer Anwendungspartition auftritt, können Sie das Hosten der Anwendungspartition auf diesem Replikat beenden. Dies kann mit dem Befehl NTDSUTIL.EXE durchgeführt werden.

 5. Beziehen die neueste Version von NTDSUTIL.EXE, indem Sie das neueste Service Pack für dieses Betriebssystem installieren. Stellen Sie sicher, dass das DSRM-Kennwort (Directory Services Restore Mode) bekannt ist, bevor Sie den DSRM-Modus starten. Setzen Sie es andernfalls zurück, bevor Sie das System neu starten.

 6. Führen Sie unter einer NT-Eingabeaufforderung im DSRM den Befehl "NTDSUTIL files integrity" aus. Stufen Sie das Replikat herab und überprüfen Sie die Hardware, wenn eine Beschädigung gefunden wurde und andere Replikate vorhanden sind. Stellen Sie das System über eine Sicherung wieder her, und wiederholen Sie diese Verifizierung, wenn keine Replikate vorhanden sind.

 7. Führen Sie eine Offlinedefragmentierung mit dem Befehl "NTDSUTIL files compact" aus.

 8. Der Befehl "NTDSUTIL semantic database analysis" sollte ebenfalls ausgeführt werden. Wenn Fehler gefunden wurden, können diese mit der Funktion "go fixup" behoben werden. Dies sollte nicht mit der Datenbankwartungsfunktion "ESE repair", die in diesem Fall nicht verwendet werden sollte, verwechselt werden, da dies zu Datenverlust bei der Active Directory-Domänendienste-Datenbank führt.

 

 Wenn keine dieser Aktionen erfolgreich ist und der Replikationsfehler weiterhin auftritt, sollten Sie diesen Domänencontroller herab- und anschließend wieder heraufstufen. 

 

Zusätzliche Daten 

Primärer Fehlerwert:

8451 Der Replikationsvorgang ist auf einen Datenbankfehler gestoßen. 

Sekundärer Fehlerwert:

-1414 JET_errSecondaryIndexCorrupted, Secondary index is corrupt. The database must be defragmented

 

Die Lösung war trotz Bauchweh erstaunlich einfach: Server im Verzeichnisdienst Wiederherstellungsmodus starten, mit ESEUTIL die DB defragmentieren und nach einem Neustart und ein paar Minuten warten war das komplette Active Directory endlich wieder sauber und die Exchange Migration lief vollends sauber durch.

 

Lange Suche - Kurze Lösung: AD Replikation bei Exchange Migrationen im Auge behalten!