Server Migration - DC

[kosta88 2]

Norbert, wenn alle Stricke reißen - ja.

 

Zum Thema Replikation:

Habe gerade AD Replication Status Tool ausgeführt und festgestellt:

Gleich wie in dcdiag, Error 8457 und 8456, Der Zielserver/Quellserver nehmen keine Replikationsanforderungen entgegen.

Weiterhin sehe ich auf Technet ein Hinweis auf DSA not writeable registry Eintrag. Dieser Eintrag existiert, unter Parameters, und hat einen Wert 4.

 

Wie ich da lese könnte was mit dem USN Rollback zu tun haben und vor allem was mit dem Snapshot - kommt mir bisschen bekannt vor, ob vielleicht das mit dem was ich oben geschrieben habe zusammenhängt

bearbeitet 21. Oktober 2016 von kosta88

[NorbertFe 1.804]

Ne nicht wenn alle Stricke reißen. Normalerweise zweiten dc hochziehen und dann Exchange migrieren. Warum? Weils funktioniert und die User kaum beeinflusst. Oder warum findest du deine Variante besser? Dein fsmo Problem: konfigurier mal beide dcs auf den selben DNS als primären Server.

[kosta88 2]

Meine Variante finde ich besser weil SBS (soweit mir gesagt wurde) ohne Exchange aktiv nicht laufen kann. Ergo *muss* ich SBS nach der Exchange Migration abschalten, und wenn ich mit den FSMO Rollen Probleme habe (also nicht sauber übertragen kann, sondern nur per Seize), dann verzögert sich die Möglichkeit für die Abschaltung.

Einstellen beide auf die selbe DNS als primär (SBS IP) hat nichts gebracht.

bearbeitet 21. Oktober 2016 von kosta88

[NorbertFe 1.804]

Tolle Gerüchte. Worauf bezieht sich das "deines Wissens" wieso sollte selbst wenn dem so wäre die Exchange Migration bis zur Deinstallation nicht bereits abgeschlossen sein? Und wenn die fsmo das letzte Probleme sei sollten schaltet man den Mist einfach nach der Exchange Deinstallation ab und seized die fsmo. Aber mach mal, ich sag das bestimmt alles nur so, weil ich das nur mal gelesen hab.

[GuentherH 61]

weil SBS (soweit mir gesagt wurde) ohne Exchange aktiv nicht laufen kann.

 

Sorry, aber das ist absoluter Nonsens. Ein SBS ist ein Standard Windows Server der als DC läuft und einen Exchange Server installiert hat. Und genauso will dieses System auch bei einer Migration behandelt werden, genauso wie es Norbert beschrieben hat. 

Und auch beim Entfernen eines migrierten SBS ist die Vorgangsweise wie bei einer Standardinstallation gleich. Zuerst Exchange deinstallieren und dann nach Übertragen der Rollen den DC herunterstufen und den Server aus der Domäne entfernen.

Alles andere sind Gerüchte, Schauergeschichten oder Märchen. Aber es gibt ja auch noch Leute, die an den Weihnachtsmann glauben :)

 

LG Günther

[kosta88 2]

So, wir haben versucht die Exchange Installation zu machen: geht auch nicht weiter.

 

Folgendes gemacht:

RSAT-ADDS installiert.

.\setup /PrepareAD /IAcceptExchangeServerLicenseTerms

 

Dann LDIF.ERR ausgelesen:

Entry DN: CN=ms-Exch-ELC-Expiry-Action,CN=Schema,CN=Configuration,DC=soer,DC=local
Fehler für Eintrag mit Beginn in Zeile 1: Ausgelastet
Serverseitiger Fehler: 0x21a2 Der FSMO-Rollenbesitz konnte nicht überprüft werden, da die zugehörige Verzeichnispartition nicht mit mindestens einem Replikationspartner repliziert wurde.
Erweiterter Serverfehler:
000021A2: SvcErr: DSID-030A0AF2, problem 5001 (BUSY), data 0
Fehler im Programm

 

Als Benutzer Administrator (Dom-Admin).
 

Wie soll ich die Rollen übertragen? Es geht jetzt nicht, wieso soll es später gehen? Seizen kann ich ja, aber nun ja: Exchange Installation klappt auch nicht.

Weiterhin, wenn ich in AD Sites and Services auf dem neuen DC (SCH-DC01) auf "Jetzt replizieren" klicke, kommt die Meldung:

Fehler aufgetreten, "Der Quellserver nimmt zurzeit keine Replikationsanforderungen entgegen". Vorgang wird nicht fortgesetzt.

 

Jetzt frage ich nochmals die Frage von oben: ist es "safe" "repadmin /options SBS01 -DISABLE_INBOUND_REPL" und "repadmin /options SBS01 -DISABLE_OUTBOUND_REPL" auszuführen?

bearbeitet 21. Oktober 2016 von kosta88

[NorbertFe 1.804]

Dann hol jemanden, der sowas kann. Wenn du bei allem sofort Probleme hast, ist das wahrscheinlich für alle die sicherste Lösung.

[NilsK 2.785]

Moin,

 

also, wenn dein Problem darin besteht, dass die Replikation abgeschaltet ist, dann würde ich grundsätzlich zwei Schritte für sinnvoll halten:

• Herausfinden, warum das so ist, die Ursache ggf. korrigieren
• Die Replikation einschalten

Da die funktionierende Replikation der Normalzustand ist, was für Probleme befürchtest du dann, wenn du sie einschaltest?

 

Gruß, Nils

[kosta88 2]

Norbert, es sind mehrere Personen im Projekt impliziert.

 

Nils, es geht nicht um das einschalten soweit, sondern darum was das Befehl bewirken kann, ob das Befehl auch was zerstören kann.

bearbeitet 21. Oktober 2016 von kosta88

[NorbertFe 1.804]

Ich bin raus. Viel Erfolg.

[NilsK 2.785]

Moin,

 

also - AD repliziert normalerweise. Was soll die Replikation dann zerstören?

 

Die eigentlich interessante Frage ist, warum die Replikation überhaupt aus ist. In diesem Thread kommen die Informationen ja nur krümelweise, daher musst du da selbst forschen. Du hast oben was von einem Snapshot erwähnt und von USN Rollback. Das kann in der Tat ein Problem sein und würde auch dazu führen, dass die Replikation aus ist. Vielleicht findet sich im Verzeichnisdienst-Eventlog noch der Fehler 2103, der dann protokolliert wird.

 

Das allerdings würde nur auftreten, wenn es mehr als einen DC gibt. Davon war bislang nicht die Rede, wir sind alle hier von einem einzigen DC (dem SBS) ausgegangen. Also vielleicht dann doch mal Karten auf den Tisch.

 

Gruß, Nils

[kosta88 2]

So, versuchen wir es nochmals:

 

Wir migrieren von SBS01 (SBS2008) auf SCH-DC01 (SRV2012R2).

Wir vermuten dass dieser SBS01 in der Vergangenheit aus einer Migration von SRV2003 entstanden ist - wir haben den Kunden übernommen, und sind auch nicht sicher.

SBS01 ist eine VM auf DIS (Hostname des Hosts), SCH-DC01 ist eine VM auf dem neuen HP G9.

Die Hauptaufgaben jetzt sind FSMO-Rollen übertragen und Exchange anschließend (oder umgekehrt!) installieren, um die Exchange Migration von SBS01 auf SCH-DC01 zu machen.

 

Was bisher geschah:

SCH-DC01 installiert, in die bestehende Domäne gesetzt.

DHCP verschoben.

Gesehen dass die Benutzer, OUs, DNS Einträge übertragen worden sind, damit beschlossen dass die Replikation funktioniert.

Backups geprüft, alles OK.

 

Als nächstes waren die Updates dran: einige WU auf SBS01 waren offen, und Exchange musste gepatched werden. SP3 wurde installiert, CU21 noch nicht.

Die Firma meldet fehlende Emails. Die Analyse hat gezeigt dass ein Snapshot um 04:00 im Hyper-V erstellt wurde, sehr vermutlich durch die automatische tägliche BackupExec Sicherung. Es ist sehr möglich dass hier zu einem Fehler gekommen ist.

Die kommenden Tage bestätigen dass BE die Sicherung täglich versucht aber scheitert. Immer wieder hängt dieser Snapshot um 04:00.

 

Status Quo ist dass wir derzeit keine aktuelle Sicherung haben, da sie täglich scheitert.

 

Zu den Themen FSMO:

Wollten die FSMOs übertragen, sowohl versucht am SBS01 wie auch SCH-DC01, ging nicht, Fehlermeldung FSMO-Inhaber nicht erreichbar.

Ebenso mit NTDSUTIL transfer versucht, gleiche Fehlermeldung:

ldap_modify_sW-Fehler 0x34(52 (Nicht verfügbar).
LDAP-Fehlermeldung: 000020AF: SvcErr: DSID-03210EC0, problem 5002 (UNAVAILABLE), data 8456
Win32-Fehler:  0x20af(Der angeforderte FSMO-Vorgang konnte nicht ausgeführt werden. Der aktuelle FSMO-Inhaber war nicht erreichbar.))
Abhängig vom Fehlercode kann dies auf einen Verbindungs-, LDAP- oder Funktionsübertragungsfehler hinweisen.
Server "sch-dc01" kennt 5 Funktionen.
Schema - CN=NTDS Settings,CN=SBS01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=soer,DC=local
Namensmaster - CN=NTDS Settings,CN=SBS01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=soer,DC=local
PDC - CN=NTDS Settings,CN=SBS01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=soer,DC=local
RID - CN=NTDS Settings,CN=SBS01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=soer,DC=local
Infrastruktur - CN=NTDS Settings,CN=SBS01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=soer,DC=local

 

 

Troubleshooting:

dcdiag auf SBS01 ausgeführt, im Anhang. Hier ist ein Hinweis für repadmin, "Die eingehende/ausgehende Replikation ist deaktiviert."

AD Replication Status Tool am SCH-DC01 im Anhang.

Troubleshooting von ADRS:

8457/8456 weist hin auf einen Registry Eintrag: DSA not writable. Unter HKLM\System\CurrentControlSet\Services\NTDS\Parameters finde ich diesen Eintrag, Wert 4, lt. MS-Docu:

A value of 4 means that a USN rollback occurred because the Active Directory database was incorrectly rolled back in time. Operations that are known to cause a USN rollback include the following...

"The booting from previously saved virtual machine snapshots of domain controller role computers on Hyper-V or VMWARE hosts" - könnte eventuell mit dem BE Problem zusammenhängen?

 

Wir haben dann noch in EventViewer geschaut:

 

Dateireplikationsdienst berichtet:

___________________________

Der Dateireplikationsdienst hat durchschnittlich mindestens 15 Dateiupdates in den letzten 3 Stunden ermittelt und unterdrückt, weil die Updates die Inhalte der Datei nicht verändert haben. Die Ablaufverfolgungs- einträge in den Debugprotokolldateien des Dateireplikationsdienstes enthalten den Dateinamen und die Ereigniszeit der unterdrückten Updates. Die Ablaufverfolgungseinträge enthalten das Datum und die Uhrzeit gefolgt von :T: als Präfix.
 
Updates, die die Inhalte der Dateien nicht ändern, werden unterdrückt, um unnötige Replikationsaktivitäten zu verhindern. Folgende sind allgemeine Beispiele für Updates, die die Inhalte der Dateien nicht verändern.
 
 [1] Eine Datei mit der Kopie der gleichen Datei überschreiben.
 [2] In einer Datei mehrfach die gleichen ACLs setzen.
 [3] Identische Kopie der Datei einer bestehenden Datei wiederherstellen.
 
Unterdrückung von Updates kann durch das Ausführen von "regedit" deaktiviert werden.
 
Klicken Sie auf "Start" und dann auf "Ausführen", und geben Sie "regedit" ein.
 
Erweitern Sie HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Services, NtFrs, Parameters, und erstellen oder aktualisieren Sie den Wert "Aktualisierungen identischer Dateien unterdrücken" auf 0 (Standard ist 1), um das Replizieren von identischen Updates zu erzwingen.

 

___________________________

 

Der Dateireplikationsdienst hat einen aktivierten Datenträgerschreibungs-Cache in dem Laufwerk mit dem Verzeichnis "c:\windows\ntfrs\jet" auf dem Computer "SBS01" ermittelt. Der Dateireplikationsdienst kann eventuell nicht wiederhergestellt werden, wenn die Stromzufuhr des Laufwerks unterbrochen wird und wichtige Aktualisierungen verloren gehen.

 

___________________________

 

 

So, wie würde ich jetzt am besten vorangehen?

 

Vorher wurde empfohlen ColdSave zu machen - gut, könnte ich machen. Natürlich besteht gewisse Angst die Machine herunterzufahren oder neuzustarten, da wir den Snapshot den wir nicht entfernen können haben. Nun ich hinterfrage hier eines: funktioniert die Wiederherstellung aus dem ColdSave? Das ist doch ein DC und nicht nur irgendein Server?

 

Genau deswegen weiß ich nicht ob ich überhaupt noch neustarten soll, sondern nur die von dcdiag empfohlenen repadmin Befehle ausführe, mit der Hoffnung dass die Replikation richtig klappt, und ich dann Exchange installieren und migrieren kann. Anschließend könnte ich auch repadmin /syncall machen.

 

Hier geht es letztendlich darum, was wir tun sollen um wenigst Risiko einzugehen.

dcdiag.txt

bearbeitet 21. Oktober 2016 von kosta88

[NilsK 2.785]

Moin,

 

also gibt es bereits zwei DCs. Damit gibt es auch das Risiko des USN-Rollback, und aller Wahrscheinlichkeit nach ist genau das eingetreten. Wie das geschehen ist, weiß ich nicht - aber in Verdacht steht natürlich der Hyper-V-Snapshot. Vielleicht hat der Kollege den ja nicht integriert, sondern "angewendet" - was effektiv heißt, dass er auf den Snapshot zurückgesprungen ist.

 

Ein USN Rollback lässt sich nicht wirklich beheben. Da der einzige DC, den ihr entfernen könnt, der neue ist, würde ich diesen wieder entfernen. Dann auf dem alleinstehenden SBS nach Möglichkeit alle weiteren Fehler beheben und die Replikation wieder aktivieren. Danach dann den Zusatz-DC neu installieren.

 

Und seht zu, dass ihr mit anderen Methoden die Daten sichert.

 

Gruß, Nils

[Weingeist 157]

In kann es nur wiederholen, eine SBS-Migration spielt man direkt mit einem ColdClone in einer Testumgebung durch und dokumentiert die Schritte.

Wenn fertig, schaltet man das Produktivsystem aus, hängt die migrierten VM's ins richtige Netz, fährt ein paar Tests und dann gehts entweder mit dem Migration-Test-System weiter und aktualisiert die Daten oder fährt die dokumentierte Migration am Produktivsystem.

Wenn man keine Erfahrung hat sowieso, alles ander ist Wahnsinn. Bei Erfahrung kann das ColdClone auch einfach als richtiges "Status Quo" vor der Migration herhalten.

Am besten auch das Testsystem in einem physischen getrennten Netz/PC. Dann schiesst man die DC's nicht gegenseitig ab wenn man Fehler in der Netzwerkkonfig macht und beide online sind und sich sehen.

 

Als erstes solltes Du endlich mal ein ColdClone ziehen bevor ihr noch mehr kaputt konfiguriert. Des weiteren sollte tunlichst die Backups zusätzlich weggesichert werden, nicht das ihr da noch alles zerstört.

 

Je nach dem welche Replikation Du überhaupt meinst (ohne genau Fehlernummer bringt das nix) ist entweder AD selbst oder nur die zugehörigen Files betroffen. Ich vermute mal die Files. Wurde auf DFS-Replikation anstelle der FRS Replikation umgestellt (Migration von 03) oder standardmässig vorhanden (Neuinstallation) ist das sogar sehr wahrscheinlich. Da braucht es nicht viel, damit es nicht mehr arbeitet. GPO's und Scripts wurden dann käumlich sauber repliziert als Du den neuen DC aufgenommen hast, auch wenn das AD an sich in Ordnung zu sein scheint. Wirst dann erst merken wenn der SBS aus ist oder die Clients unterschiedlich reagieren.

Wenn es an AD selbst liegt und es sich nicht mehr reparieren lassen würde bzw. ihr das nicht hinkriegt und auch keine externe Hilfe wollt, würde ich mal nen Backup vor der Migration in eine Test-VM zurückspielen und schauen ob da AD noch in Ordnung war oder ob es auch schon Replikatfehler hatte.

 

Des weiterne würde ich eine E-Mail Weiterleitung auf euren Provider einrichten. Dann habt ihr im Falle eines kompletten Rollbacks oder sonstigen Problemen wenigstens noch die aktuellen Mails. Könnt natürlich auch alles neue in Outlook exportieren und nach erfolgreicher Migration neues wieder importieren. Sind aber alles Basis-Vorgehensweisen die man sich mit Testsystemen aneignen sollte bevor man sich an die produktiven Systeme wagt.

bearbeitet 21. Oktober 2016 von Weingeist

[kosta88 2]

Danke Nils, genau so hat es funktioniert!

 

Tatsächlich waren die USNs auseinander, 21.10. auf SBS01, 14.10. auf SCH-DC01.

Demote DC01, per repadmin die Replikation wieder relaubt, DC01 -> DC02 unbenannt, Metadata Cleanup gemacht, Promo DC02 und siehe da, Rollen und alles lassen sich übertragen. repadmin /syncall funktioniert auch.

 

Die Vermutung dass BE Snapshot die Probleme verursacht hat bleibt offen, und wir glauben dazu geführt hat, dass die USNs auseinander laufen, es war genau am 14.10.

bearbeitet 21. Oktober 2016 von kosta88