Wenn man seit Windows 2008 einen Domäne neu erstellt hat, wird die Replikation des SYSVOLs schon mit DFSR (Distributed File System Replication) realisiert. Hat man aber von einer Windows 2000 oder Windows 2003 Domäne migriert wird höchstwahrscheinlich die SYSVOLs immer noch mit FRS (File Replication Service) repliziert – auch wenn man auf Windows 2012 R2 migriert hat.

Der FRS-Dienst (auch NTFRS oder auf deutsch Dateireplikationsdienst genannt) ist aber seit Windows 2003 R2 abgekündigt, fehleranfälliger, schlecht überwachbar, schlechter in der Performance, nicht mehr weiterentwickelt und mittlerweile auch tot (wird in neueren Versionen von Windows nicht mehr enthalten sein).

Spätestens mit der Migration auf Windows 2012 oder 2012 R2 sollte deshalb die SYSVOL-Replikation auf DFSR umgestellt werden.

Hier mal eine Kurzanleitung wie man das macht:

1) Voraussetzungen checken

– Als erstes sollte getestet werden ob die bisherige Replikation funktioniert. Am einfachsten legt man dazu eine Textdatei in die NETLOGON-Freigabe eines Domain-Controllers und überprüft ob diese auf den anderen DCs auftaucht

– Auch das FRS-Ereignisprotokoll auf den DCs sollte überprüft werden und Fehler korrigiert werden

FRS-Eventlog

– Ausserdem muss die Domänenfunktionsebene mindestens Windows2008 sein.
Zum überprüfen kann man auf in der Powershell (als Administrator ausführen) ein Get-ADDomain ausführen

Get-ADDomain

2) Migration starten

Wenn alle Voraussetzungen erfüllt sind kann man an die Migration gehen. Die Migration sollte man am besten vom Domain-Controller ausführen, der die PDC-Rolle innehat. Alle Befehle müssen in einer CMD oder Powershell als Administrator ausgeführt werden.

2.1) Status „Starten“

dfsrmig /setGlobalState 0

Damit werden alle Domänencontroller auf den Status „Starten“ gesetzt. Zum verifizieren starten wir jetzt noch folgenden Befehl:

dfsrmig /GetMigrationState

Dort sollte jetzt „Alle Domänencontroller wurden erfolgreich zum globalen Status („Starten“) migriert“ stehen.

DFS_Start

Dann können wir weitermachen..

2.2) Status „Vorbereitet“

dfsrmig /setGlobalState 1

Damit werden alle Domänencontroller auf den Status „Vorbereitet“ gesetzt.

Nach einer gewissen Zeit sollte der Status auf allen Domänencontroller gesetzt worden sein. Zum überprüfen kann wieder der Befehl

dfsrmig /GetMigrationState

abgesetzt werden.

DFS_Vorbereitet

Wenn die Meldung „Alle Domänencontroller wurden erfolgreich zum globalen Status („Vorbereitet“) migriert“ kommt, können wir wieder weiter machen..

2.3) Status „Umgeleitet“

dfsrmig /setGlobalState 2

Damit werden alle Domänencontroller auf den Status „Umgeleitet“ gesetzt.

Nach einer gewissen Zeit sollte der Status auf allen Domänencontroller gesetzt worden sein. Zum überprüfen kann wieder der Befehl

dfsrmig /GetMigrationState

abgesetzt werden.

DFS_Umgeleitet

Wenn die Meldung „Alle Domänencontroller wurden erfolgreich zum globalen Status („Umgeleitet“) migriert“ kommt, können wir wieder weiter machen..

2.4) Status „Entfernt“

dfsrmig /setGlobalState 3

Damit werden alle Domänencontroller auf den Status „Entfernt“ gesetzt.

Nach einer gewissen Zeit sollte der Status auf allen Domänencontroller gesetzt worden sein. Zum überprüfen kann wieder der Befehl

dfsrmig /GetMigrationState

abgesetzt werden.

DFS_Entfernt

Wenn die Meldung „Alle Domänencontroller wurden erfolgreich zum globalen Status („Entfernt“) migriert“ kommt, sind wir mit der Migration fertig.

3) Migration überprüfen

Durch die Migration wurde der SYSVOL-Ordner unter C:\Windows zu einem SYSVOL_DFSR. ALter Ballast wie der Staging-Ordner wurde entfernt bzw. nicht mitmigriert. Die SYSVOL und NETLOGON-Freigabe zeigen nun auf die Inhalte des neuen SYSVOL_DFSR. Der Dateireplikationsdienst wurde auf allen Domänencontrollern auf deaktiviert gesetzt.

Somit wird ausschließlich über DFSR repliziert – FRS ist somit Geschichte 🙂

Für weitere und detailiertere Informationen kann hier nachgeschaut werden:
Technet Kurzanleitung (deutsch)
Technet (englisch)

Wenn man einen ESXi-Host updaten will und den Update Manager von VMWare nicht verwenden kann oder will, empfehle ich immer das Update mittels dem Offline Bundle.

Das Update mit dem Offline Bundle ist wirklich super einfach und funktioniert eigentlich immer. Ich zeige die Vorgehensweise an einem Upgrade von ESXi 5.1 auf 5.5:

1) Als erstes muss das zu installierende Offline Bundle heruntergeladen werden. Entweder direkt bei VMWare

OfflineBundleDownload

oder beim Hersteller des Servers. Alle großen Hersteller bieten hier auch Offline Bundles an. Wenn der Server mit vorinstalliertem ESXi vom Hersteller läuft, wäre der Hersteller-Download die bevorzugte Wahl.

2) Das Offline Bundle auf den Datastore des ESXi hochladen. Wenn man mehrere ESXi zu upgraden hat, empfiehlt sich da natürlich ein Datastore zu wählen auf den alle ESXi Zugriff haben..

BundleHochladen

BundleHochgeladen

3) Den ESXi-Host in den Wartungsmodus versetzen

Wartungsmodus

4) Mit SSH auf den Host verbinden (falls nötig muss der Dienst noch gestartet werden -> Anleitung wie dies einfach funktioniert)

5) Jetzt geben wir uns alle Profile des Offline Bundle aus

esxcli software sources profile list -d /vmfs/volumes/datastore1/update-from-esxi5.5-5.5_update02-2068190.zip

ShowProfilesBundle

Meistens wird hier das einfache Standard-Profil benötigt – kommt darauf an welches Profil der Host jetzt hat – das sieht man am einfachsten im VMWare Client

ProfileESXi-Host-1

6) Das entsprechende Profil installieren

esxcli software profile update -d /vmfs/volumes/datastore1/update-from-esxi5.5-5.5_update02-2068190.zip -p ESXi-5.5.0-20140902001-standard

Nach kurzer Wartezeit kommt dann folgende Ausgabe

UpdateResultOfflineBundle

Danach den Host rebooten

reboot now

7) Mit dem VMWare-Client anmelden und die Version überprüfen

ProfileESXi-Host-2

8) Wartungsmodus beenden

Jetzt noch den Wartungsmodus beenden

WartungsmodusBeenden

und schon sind wir fertig 🙂