Win2008: SYSVOL-Migration von FRS auf DFSR

Hi,

die Umstellung des SYSVOLs von der altbewährten Replikation mit FRS auf die neue Replikationstechnologie DFSR ist ein spannendes Thema, das sicher noch vor vielen liegt.

Ich möchte dazu heute ein paar Fakten erzählen und beschränke mich dabei hauptsächlich auf das, was wir unternehmen müssen und was wir dann im System oder im AD (Active Directory) sehen und kontrollieren können. Auf die internen Abläufe dahinter möchte ich an dieser Stelle nicht eingehen.

Es gibt eine sehr gute englische Dokumentation dazu, die auch die Details behandelt, die im Hintergrund ablaufen:

https://blogs.technet.com/filecab/search.aspx?q=sysvol+migration&p=1

Die schlechte Nachricht zuerst: Man kann nicht umstellen, solange die Umgebung gemischt ist. Alle DCs (Domänenkontroller) der Domäne, die ich umstellen will, müssen Windows Server 2008 als Betriebssystem haben. Und der Functional Level der Domäne muß bereits auf Windows 2008 angehoben sein.

Die gute Nachricht ist: Das SYSVOL wird immer nur pro Domäne repliziert, d.h. nicht alle Domänen müssen bereits auf Windows 2008 sein, sondern nur die, für die ich die Umstellung in Angriff nehmen will.

Forest-weit, d.h. für die komplette Gesamtstruktur, ist eine Schema-Erweiterung erforderlich. Da kommen wir nicht drum herum. Denn ohne diese Schema-Erweiterung kennt das AD (Active Directory) die DFSR-Objekte nicht, über die alle Konfigurationsinformationen für DFSR Replikationsgruppen und Replicated Folder im AD gespeichert werden.

Das sind die Voraussetzungen.

Bevor es dann losgeht, empfehle ich ein Backup des SYSVOLs. Ich gehe da gerne auf Nummer SEHR sicher.

Außerdem sollte die FRS Replikation des SYSVOLs zu dem Zeitpunkt möglichst reibungslos funktionieren.

Wir empfehlen, daß in dieser Zeit, also während der Migration, möglichst wenig (am besten gar keine) Änderungen am Inhalt des SYSVOLs, also Gruppenrichtlinien und Skripte im wesentlichen, gemacht werden.

Und zwei Punkte sind noch wichtig, die eigentlich so selbstverständlich sind, daß man oft nicht dran denkt: Der Dienst DFSR muß auf allen DCs der Domäne laufen und die AD-Replikation muß funktionieren, weil ja die komplette Konfiguration im AD gespeichert und dort entsprechend repliziert wird.

Nun sind es 4 Hauptschritte:

0. Start

1. Prepared

2. Redirected

3. Eliminated

Alle vier Schritte werden manuell angestoßen. Man kann also ganz in Ruhe und wie es der Betrieb erlaubt, einen Schritt nach dem anderen machen.

Jeder dieser großen Schritte umfaßt mehrere Aktionen, die innerhalb des Schrittes ablaufen. Man könnte sagen, mehrere kleine Schritte, die z.T. lokal auf den einzelnen DCs der Domäne erfolgen und dort entsprechend in der Registry als „localState“ abgespeichert werden. Da die lokalen Stati nur temporär sind, muß man Glück haben, wenn man die Werte tatsächlich sehen will. Stabil sind nur die globalen Stati. Und da wir wegen der lokalen auch direkt nichts unternehmen müssen, möchte ich hier im Detail nicht darauf eingehen, welcher Aktion bzw. Änderung jeweils welcher lokale Status zugeordnet ist.

0 – also der Start-Zustand ist unser Ausgangszustand, in dem sich unser SYSVOL befindet, bevor wir mit der Umstellung beginnen. Es scheint überflüssig, ihm einen eigenen Status zuzuweisen, aber ich hoffe, es wird am Ende deutlich, warum auch dieser Status wichtig ist für den Gesamtprozeß.

1 – Prepared

Hier kommt erstmals das Tool ins Spiel, mit dem die komplette Umstellung durchgeführt wird:
DFSRMIG.

Wir brauchen es hauptsächlich mit 2 Parametern:

DFSRMIG /SETGLOBALSTATE und
DFSRMIG /GETMIGRATIONSTATE

Dieses Tool ist nur auf Windows Server 2008 DCs supported. Es kann auf jedem „vollständigen“ DC ausgeführt werden, d.h. es kann nicht auf RO DCs (Read-Only) ausgeführt werden. Der DC, auf dem ich das Tool ausführe, muß eine gute Verbindung zum PDC haben, denn das Tool verbindet sich zum PDC, und nur dort werden die globalen Objekte und Konfigurationen von DFSR angelegt. Vom PDC werden dann alle Änderungen rausrepliziert im Rahmen des normalen, vom Administrator eingestellten Zeitplans. Und erst wenn die Replikation dann bei dem DC angekommen ist, auf dem die Migration initiiert wurde, beginnt dann die Migration. Wenn der DC den PDC nicht erreichen kann, schlägt der Befehl fehl.

Daher empfehlen wir, das Tool auf dem PDC selbst auszuführen. Das gewährleistet am besten eine gute Erreichbarkeit und einen schnellen Start der Migration.

Um den Übergang von Status 0 auf Status 1 anzustoßen, ist der Befehl in der Kommandozeile
DFSRMIG / SETGLOBALSTATE 1.

Das stößt verschiedene Aktionen an:

- Die DFSR-Objekte für das SYSVOL werden im AD angelegt, zum einen unter jedem DC-Objekt und zum anderen im SYSTEM-Container.

- DFSR legt ein Verzeichnis SYSVOL_DFSR an – neben dem altbekannten SYSVOL, auf der gleichen Platte – und kopiert den ganzen Inhalt aus dem SYSVOL dorthin.
D.h. wir haben jetzt den kompletten SYSVOL-Inhalt zweimal, hier heißt es also: Ausreichend Plattenplatz bereithalten.
DFSR repliziert ab dann seine Kopie des SYSVOLs eigenständig in der Domäne. Wie bei jedem DFSR Replicated Folder fängt die Replikation auch hier mit einer initialen Replikation an, mit allen Besonderheiten, die wir auch bei benutzerdefinierten Replicated Folders beobachten.
Wenn die initiale Synchronisation beendet ist, wechselt der „globalState“ auf 1.

In diesem Zustand gilt:

Die Benutzer greifen weiterhin auf das SYSVOL zu, alle Änderungen an Group Policies werden dort gemacht und FRS repliziert auch weiterhin alle Änderungen am SYSVOL.

Der Status 1 wird im AD gespeichert und somit repliziert. So wird mit der Replikation und indem die verschiedenen Aktionen nach und nach auf allen DCs der Domäne ausgeführt werden, letztendlich jeder DC in den globalState 1 gesetzt.

Um zu prüfen, ob alle DCs diesen globalen Status erreicht haben, gibt es den Befehl

DFSRMIG /GETMIGRATIONSTATE

Ich empfehle, mindestens mit diesem Befehl zu prüfen, ob alle DCs den ersten Schritt vollendet haben.

2 - Redirected

Dieser Schritt beginnt mit

DFSRMIG /SETGLOBALSTATE 2.

Damit beginnen folgende Umstellungen:

- Auf dem PDC wird der Inhalt vom SYSVOL noch einmal nach SYSVOL_DFSR kopiert bzw. die Änderungen werden dorthin kopiert. Vom PDC werden diese Änderungen dann mit DFSR rausrepliziert.
Das geschieht deshalb, weil ja zwischen dem ersten Schritt (Prepared) und dem zweiten Schritt ein großer Zeitabstand liegen kann, in dem möglicherweise Änderungen an Gruppenrichtlinien und / oder Skripten notwendig waren, die nun nicht verloren gehen sollen.

- DFSR beendet dann die SYSVOL Freigabe auf SYSVOL und erstellt sie neu für SYSVOL_DFSR. Die User greifen nun auf das neue Share zu und alle Änderungen werden ab sofort dort gemacht.

- Zwischen dem NTDS Dienst und dem DFSR Dienst wird eine Abhängigkeit erstellt, um sicherzustellen, daß beim Maschinenstart beide starten.

- FRS repliziert seine Kopie des SYSVOL nachwievor.

Diese beiden Schritte können jeweils rückgängig gemacht werden, falls etwas schief geht oder man sich um entscheidet. D.h. wir können von hier wieder zurück auf „Start“ gehen oder auf „Prepared“, wenn notwendig. Deshalb ist auch der Zustand „Start“ als eigener Zustand wichtig.

Auch dafür ist DFSRMIG das Mittel der Wahl:

DFSRMIG /SETGLOBALSTATE 1 oder 0.

Der nächste Schritt ist endgültig, außer natürlich wenn man Backups einbezieht.

Deshalb ist es hier auch ganz wichtig, daß sichergestellt ist, daß die ersten beiden Schritte auf allen DCs einwandfrei und vollständig geklappt haben.

Auch hier kann man natürlich wieder eine Prüfung mit

DFSRMIG /GETMIGRATIONSTATE

machen. Ich persönlich gehe aber immer gerne auf Nummer ganz sicher und würde daher zumindest stichprobenartig auch direkt auf die DCs schauen, insbesondere auf einige der schlechter angebundenen DCs.

3 – Eliminated

Auch dieser Schritt beginnt mit dem für diese Umstellung einzig wahren Tool:

DFSRMIG /SETGLOBALSTATE 3.

Dieser Schritt führt hauptsächlich Aufräumarbeiten durch – beseitigt alles Wissen über FRS in Zusammenhang mit dem SYSVOL.

Im Einzelnen geschieht nun:

- Die Service Abhängigkeit zwischen NTDS und FRS wird beendet und der FRS Dienst gestoppt.

- Alle FRS Objekte im AD, die mit SYSVOL zu tun haben, werden gelöscht.

- Das SYSVOL Verzeichnis wird gelöscht, sofern es nicht im Zugriff ist. D.h. wenn Ihr so neugierig seid wie ich und im Explorer nachschaut, ob es denn schon gelöscht ist, kann es sein, daß es nicht gelöscht werden kann. Der Inhalt sollte aber in jedem Fall gelöscht werden, und das leere SYSVOL-Verzeichnis stört ja zunächst nicht weiter und kann dann später, wenn alles andere fertig ist, manuell gelöscht werden.

- Falls FRS auf dem DC außer dem SYSVOL anderen Inhalt repliziert, wird der Dienst zum Schluß wieder gestartet.

- Der SYSVOL Inhalt kann jetzt nur noch ausschließlich via DFSR repliziert werden. Dieser Schritt kann auch nicht rückgängig gemacht werden, weil die gesamte FRS-SYSVOL Infrastruktur nun gelöscht ist. Deshalb ist es so wichtig, daß in den Schritten davor kontrolliert wird, daß alles wie gewünscht funktioniert und alle DCs die Änderungen mitbekommen haben.

Ab diesem Zeitpunkt ist FRS Vergangenheit.

Der König ist tot, es lebe der König. ;-)

Gruß

Barbara

Comments

• Anonymous
  October 28, 2008
  Hi! Super Anleitung, vielen Dank!

• Anonymous
  October 14, 2010
  Danke für die Info :-)