So kann beim Schema Upgrade für Windows 2008 (fast) nichts schiefgehen

So kann beim Schema Upgrade für Windows 2008 (fast) nichts schiefgehen

  • Comments 4
  • Likes

Hallo, Thomas hier. Immer wieder werden wir gefragt, wie man sich am Besten gegen etwaige Probleme beim Schema-Upgrade für Windows 2008 absichert. Deshalb habe ich einmal die wesentlichen Schritte für die Vor- und Nachbereitung zusammengestellt, die übrigens auch für alle anderen Schema-Updates analog verwendet werden können.

1. Stellen Sie sich die folgenden Fragen:

a.) Habe ich mir die Dokumentation zu ADPREP in der Technet (http://technet.microsoft.com/en-us/library/dd464018.aspx) genau angeschaut?

b.) Habe ich ein getestetes Konzept für die Recovery meines kompletten Forest in der Schublade?

Wenn nicht, hier abbrechen und dieses Konzept implementieren und vor allen Dingen testen. Hilfestellung hierzu findet man im Whitepaper “Planning for Active Directory Forest Recovery” unter http://www.microsoft.com/downloads/details.aspx?amilyid=afe436fa-8e8a-443a-9027-c522dee35d85&displaylang=en

Die Erfahrung lehrt, dass, wenn ein solches Konzept vorhanden ist und dessen Anwendung regelmäßig trainiert wird, Murphy die Lust zum Zuschlagen blitzartig vergeht.

c.) Funktioniert die AD-Replikation auf jedem DC meines Forests?

Wenn Sie Überwachungstools wie den Microsoft System Center Operations Manager einsetzen lässt sich die Frage relativ schnell beantworten.

Ansonsten ist es erforderlich, den Befehl

repadmin /replsum /bysrc /bydest /sort:delta >replsum<Sitename>.txt

in jeder Site auszuführen und die Textdateien auf Inkonsistenzen zu untersuchen.

d.) Wie aktuell sind meine System State Backups und lassen sich diese auch zurück sichern?

Dieses lässt sich ganz einfach überprüfen und als "Belohnung" hat man dann gleich die Testumgebung für das Schema Update:

  • Erstellen Sie die System State Backups Ihres Schema Masters und auf je einem DC aus jeder Child Domäne mit NTBACKUP und sichern Sie diese auf die lokale Festplatte Ihrer Domänen Controller.
  • Nehmen Sie jetzt die so entstandenen System State Backups und spielen Sie sie  in Ihrer (virtuellen) vom Produktivnetz komplett isolierten Testumgebung ein.
  • Wenn Sie die Fehler wegen fehlender Replikationspartner im Eventlog stören, entfernen Sie in der Testumgebung alle anderen DCs aus der AD Datenbank indemSie den Schritten aus KB 216498 How to remove data in Active Directory after an unsuccessful domain controller demotion http://support.microsoft.com/default.aspx?scid=kb;EN-US;216498 für jeden nicht mehr vorhandenen DC folgen.

e.) Funktioniert der Schema Upgrade in einer abgeschotteten Testumgebung?

Führen Sie jetzt die einzelnen ADPREP Schritte (/forestprep, /domainprep /gpprep und eventuell /rodcprep) in Ihrer Testumgebung durch.
Achtung: Bei 32-bit Systemen muss mit Windows 2008 R2 adprep32 verwendet werden.

Kontrollieren Sie nach jedem Schritt den Erfolg anhand der folgenden Kriterien:

  • Keine Fehlermeldung auf der Kommandozeile. Wenn Fehler auftreten, finden Sie detaillierte Informationen im Verzeichnis %windir%\adprep\logs.       
  • Falls Probleme auftreten sollten, schauen Sie unter - Ask the Directory Services Team : Troubleshooting ADPREP Errors http://blogs.technet.com/askds/archive/2008/12/15/troubleshooting-adprep-errors.aspx nach einer etwaigen Lösung.
  • Die Operational GUIDs unter CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain  sind auf allen DCs vorhanden. Eine  Liste finden Sie unter Windows Server 2008: Forest-Wide Updates http://technet.microsoft.com/en-us/library/cc771922.aspx
  • Die Operational GUIDs unter CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,[DC=ChildDomain],DC=ForestRootDomain sind auf allen DCs der    jeweiligen Domäne vorhanden. Eine Liste finden Sie unter Windows Server 2008: Domain-Wide Updates http://technet.microsoft.com/en-us/library/cc770385.aspx
  • Die letzten beiden Punkte überprüft man am einfachsten mit ADSIEDIT.msc:

2. Hat alles funktioniert, dann ab in die Live-Umgebung.

  1. Überprüfen Sie noch einmal die Replikation des gesamten Forest wie oben unter c.) beschrieben.
  2. In der Live-Umgebung muss der Schema-Master für das Upgrade isoliert werden. Hierfür existieren unterschiedliche Ansätze:
    1. Deaktivieren der Replikation auf dem Schema Master mit dem Befehl repadmin /options +DISABLE_OUTBOUND_REPL
      Dieser Ansatz ist dann zu wählen, wenn sichergestellt werden kann, dass kein anderer Administrator während des Upgrades den Befehl repadmin /force ausführt, da dieser das +DISABLE_OUTBOUND_REPL außer Kraft setzt.
    2. Verbringen des Schema Masters und eines anderen DCs in eine eigene Site, die vom restlichen Netzwerk isoliert ist. Die IP-Adressen dürfen hierfür nicht geändert werden. Am besten zwei Maschinen aus demselben Netzwerksegment verwenden und über einen Switch ohne Verbindung zum Hauptnetzwerk verbinden. Dieses ist die sicherste Methode in großen Umgebungen.
    3. Eintragen einer Sperrzeit von 1-2 Stunden auf allen Site-Links, die die Schema-Master Site mit dem Rest der Welt verbinden und Durchführen des Upgrades in diesem Zeitraum. Dieses stellt eine zusätzliche Absicherung dar und kann mit 2.1 und 2.2 kombiniert werden.
  3. Führen Sie adprep /forestprep aus und überprüfen Sie den Erfolg wie oben unter e.) beschrieben.
  4. Falls Probleme auftreten sollten, schauen Sie unter -   Ask the Directory Services Team : Troubleshooting ADPREP Errors http://blogs.technet.com/askds/archive/2008/12/15/troubleshooting-adprep-errors.aspx nach einer etwaigen Lösung. 
  5. Schalten Sie die Replikation entweder über repadmin /options -DISABLE_OUTBOUND_REPL bzw.durch Verbinden des Switches mit dem Hauptnetzwerk wieder ein.
  6. Starten Sie die Replikation via repadmin /syncall oder warten Sie das normale Replikationsintervall ab.
  7. Überprüfen Sie die Replikation der Änderungen mithilfe der Operational GUIDs für CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=ForestRootDomain zumindest stichprobenartig. Beobachten Sie hier besonders die DCs mit der größten Replikationslatenz.
  8. Warten Sie noch einen kompletten Replikationszyklus ab, bevor Sie fortfahren.
  9. Hat alles funktioniert kann nun der adprep /domainprep /gpprep auf den Infrastruktur Mastern aller Domänen, die mit Windows Server 2008 DCs ausgestattet werden sollen durchgeführt werden.
  10. Da hier keine dramatischen Eingriffe mehr geschehen kann auf die Absicherung wie in den Schritten 1. bis 8. dargestellt verzichtet werden.
  11. Besonders unkritisch ist der adprep /rodcprep Befehl, da dieser beliebig oft ausgeführt werden kann.

Viel Erfolg und viele Grüße
Thomas

Comments
  • Hallo Thomas,

    genialer Beitrag! Ergibt es in diesem Zusammenhang Sinn, wenn der Befehl "repadmin /syncall" direkt nach dem Schema-Update (ein- oder mehrmals) ausgeführt wird? Oder  sollte hier besser die Standard-Replikation abgewartet werden?

    LG

    Holger Tempel

  • Befehl lautet:

    repadmin /options <DCNAME> -DISABLE_OUTBOUND_REPL

  • Moin,

    von der Isolation des Schema-Masters (oben 2.2) wird von Microsoft ausdrücklich abgeraten!

    blogs.technet.com/.../friday-mail-sack-i-live-again-edition.aspx

    Auf keinen Fall ist es ein "Muss".

    Gruß, Nils

  • Hallo Nils, das ist derzeit ein Thema, bei dem sich die Geister scheiden. Es gibt gleichzeitig auch Empfehlungen Forest Cloning nicht zu verwenden, wenn auch für einen etwas anderen Zweck; siehe blogs.technet.com/.../active-directory-mergers-acquisitions-and-divestitures.aspx.

    Hintergrund ist hier, daß zu einem späteren Zeitpunkt die zuvor gesplitteten Forests doch wieder replizieren und dann ungewünschte Resultate entstehen, bis hin zu einem zerstörten Forest.

    Die hier im Blog beschriebene Isolierung für das Schema Upgrade mag kein explizit getestetes Szenario sein, kann aber beim Wegbrechen einer entsprechenden WAN Verbindung (mit Schema-Master und einem DC in der Site) auch so passieren - und das läßt sich nach unserer bisherigen Erfahrung immer recovern.

    Die Argumentation, daß Administratoren häufig(er) "vergessen", die Outbound Replikation wieder zu aktivieren, ist nicht mehr wahrscheinlich, als das Zusammenführen vormals gesplitteter Forests - beides sind vermeidbare Fehler, wenn man einen guten Plan hat und den konsequent umsetzt...

    Grüße, Rol

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment