Bei einem Neukunden haben wir einen Windows Server 2012 Essentials in nicht gerade all zu gutem Zustand vorgefunden. Bevor nun zum einen die Hardware komplett die Grätsche macht, den Geist aufgibt oder wie man es sonst noch nennen mag und uns weitere Macken der Essentials-Umgebung das Administrator-Leben schwer machen, sollte der Server ausgetauscht werden.
Der Ablauf ist eigentlich wie bei jeder Active Directory-/Domänencontroller-Migration:
- Den neuen Server, inkl. aller aktueller Updates, installieren.
- Über den Server-Manager oder die Powershell die “Active Directory-Domänendienste” hinzufügen.
- Den neuen Server in die Domäne aufnehmen.
- Zum Domänencontroller hochstufen.
- Die FSMO-Rollen verschieben. Dazu in der Powershell folgenden Befehl ausführen:
Move-ADDirectoryServerOperationMasterRole -Identity <NeuerDC> -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
Die Sicherheitsabfrage entsprechend bestätigen.
- Nach erfolgtem Verschieben der FSMO-Rollen den Status prüfen. In einer Eingabeaufforderung folgenden Befehl ausführen:
netdom query fsmo
Ferner in den Ereignisprotokollen nachsehen, ob Warnungen oder Fehler aufgetreten sind!
- Bevor man den alten Server herunterstufen und aus der Domäne entfernen kann müssen zunächst die “Active Directory-Zertifikatsdienste” samt aller Komponenten entfernt werden. Von der Reihenfolge her muss erst die “Zertifikatsstellen-Webregistrierung” und dann die gesamte Rolle entfernt werden. Ein Neustart ist an dieser Stelle zwingend notwendig.
- Den alten Server über den Server-Manager oder die Powershell herunterstufen.
Tipp: Das Herunterstufen kann man in der Powershell testen:Test-ADDSDomainControllerUninstallation
- Den alten Server aus der Domäne entfernen.
- Optional: Die Domänenfunktionsebenen heraufsetzen.
Vor- und/oder Nacharbeiten
Geht man von einer Essentials-Umgebung weg, sollte man auf den Arbeitsplätzen den “Windows Server Essentials Connector” deinstallieren.
In den Benutzerobjekten sollte die Pfade zu Basis- und Profil-Ordnern überprüft und ggf. geändert werden.
Ferner sollte man die Gruppenrichtlinien-Objekte mal durchschauen, ob Server-spezifische Einstellungen vorhanden sind. Beispiele dafür sind Netzlaufwerke, Netzwerkdrucker, WSUS, usw.
Gleiches gilt für DHCP und DNS.
Troubleshooting
Während der Migration mussten wir feststellen, das auf dem neuen Domänencontroller zunächst die Freigaben “NETLOGON” und “SYSVOL” fehlten. Dies kann passieren, wenn man die Replikation noch nicht abgewartet hat oder, sofern das gesamte Netzwerk schon etwas älter ist, beispielweise ursprünglich mal von Windows 2000 Server oder Windows Server 2003 migriert wurde und anschl. beim Wechsel auf Windows Server 2012 nicht von DFS auf DFRS umgestellt wurde.
Letzteres war hier nicht der Fall, ersteres schon eher. Jedenfalls half es auf dem alten Server den Anweisungen aus dem Ereignis 2213 zu folgenden und etwas zu warten.
Nachdem der alte Server weg war tauchten immer noch Meldungen im Ereignisprotoll der DFRS-Replikation auf. Ein Blick unter
Active Directory-Standorte und -Dienste - Sites - Default-First-Site-Name - Server
offenbarte, das doch noch ein Rest vorhanden war. Dort den alten Server entfernt und etwas Geduld mitgebracht tauchten (bislang) keine neuen Fehlermeldungen mehr auf.
Randbemerkung
Mit diesem Wechsel hat sich dann auch die etwas unschöne Sache mit dem “Nicht-Ändern-können” der Kennwortrichtlinie erledigt. Beim Essentials geht das entweder über das Dashboard oder die GPO. Leider klappe beides nicht. Das Dashboard meldete zwar immer Erfolg. In der GPO kam das allerdings nicht an.
Ein direktes Ändern mittels GPO, ganz gleich ob mit einer neuen Richtlinien oder beim Editieren einer Bestehenden, endete immer mit folgender Fehlermeldung:
Das Objekt, also die Datei genau genommen, ist im übrigen vorhanden und andere Einstellungen kann man auch erfolgreich vornehmen.
Quellen:
Microsoft Tech Community – How to Migrate Active Directory from Windows Server 2012 R2 to 2019
Andreas’ Blog – SYSVOL-Migration von FRS auf DFSR
Dimitris Tonias – Demote a Windows Server 2016 Domain Controller
Update 27.11.2019
“Kleiner” Nachtrag zum Troubleshooting wenn die Freigaben “SYSVOL” und “NETLOGON” fehlen:
Ist “SYSVOL” selbst nach Stunden (oder Tagen) nicht repliziert, so hilft es auf dem Quellserver den Dienst “DFS-Replikation” (DFSR) neu zu starten und anschließend in das Ereignisprotokoll unter “Anwendungs- und Dienstprotokolle – DFS-Replikation” nach folgendem Eintrag zu suchen:
Protokollname: DFS Replication Quelle: DFSR Datum: 27.11.2019 14:17:52 Ereignis-ID: 2213 Aufgabenkategorie:Keine Ebene: Warnung Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: SRV01.domain.local Beschreibung: Vom DFS-Replikationsdienst wurde die Replikation für das Volume "C:" beendet. Dieser Fall tritt ein, wenn eine DFSR-JET-Datenbank nicht ordnungsgemäß heruntergefahren wird und die automatische Wiederherstellung deaktiviert ist. Sichern Sie zum Beheben dieses Problems die Dateien in den betroffenen replizierten Ordnern, und setzen Sie die Replikation anschließend mithilfe der WMI-Methode "ResumeReplication" fort. Weitere Informationen: Volume: C: GUID: 67DC0EE9-D681-11E5-93ED-806E6F6E6963 Wiederherstellungsschritte 1. Sichern Sie die Dateien in allen replizierten Ordnern auf dem Volume. Andernfalls gehen möglicherweise aufgrund einer unerwarteten Konfliktauflösung im Rahmen der Wiederherstellung der replizierten Ordner Daten verloren. 2. Setzen Sie die Replikation für dieses Volume mithilfe der WMI-Methode "ResumeReplication" der DfsrVolumeConfig-Klasse fort. Geben Sie hierzu an einer Eingabeaufforderung mit erhöhten Rechten beispielsweise den folgenden Befehl ein: wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="67DC0EE9-D681-11E5-93ED-806E6F6E6963" call ResumeReplication
Die “GUID” kann natürlich abweichen. Führt man den vorgeschlagenen Befehl in einer Eingabeauffoderung mit erhöhten Rechten aus, erscheint folgende Ausgabe:
C:\Windows\system32>wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig wh
ere volumeGuid="67DC0EE9-D681-11E5-93ED-806E6F6E6963" call ResumeReplication
(\\SRV01\root\microsoftdfs:DfsrVolumeConfig.VolumeGuid="67DC0EE9-D681-11E5-93
ED-806E6F6E6963")->ResumeReplication() wird ausgeführt
Methode wurde ausgeführt.
Ausgabeparameter:
instance of __PARAMETERS
{
ReturnValue = 0;
};
Im Ereignisprotokoll sollte relativ schnell alles in Ordnung sein und die Replikation startet sofort.
Quellen:
Microsoft Support – DFS Replication: How to troubleshoot missing SYSVOL and Netlogon shares
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Hi Andy,
vielen Dank für deine ausführliche Beschreibung. Die Migration der Domäne hat geklappt. Alle FSMO Rollen sind auf dem neuen Server 2019. Jetzt habe ich aber leider immernoch die Beschränkung mit 25 Usern (Grundsystem war ein 2008 Essential System). LG
Hallo Omar,
wie die Beschränkung ist noch da? Das ist mir bislang bei noch keiner Essentials- oder Foundation-Migration unter gekommen, sofern der alte Server heruntergestuft und entfernt wurde (versteht sich).
Ist der alte Server noch im Netz, und sei es nur als Member-Server, meckert er bei mehr als 15/25-Usern fleißig weiter.
Hallo Andy,
kann eine Windows Server 2012 R2 Foundation Installation auf die gleiche Weise auf einen Windows Server 2019 Standard migriert werden?
Ja.
Hi Andy, sorry vielmals. Ich habe gar nicht mitbekommen, dass du mir geantwortest hast. Es war tatsächlich so, dass ich eine Rolle vergessen hatte. Nach dem Umzug der letzten Rolle scheint es jetzt zu laufen. Vielen Dank nochmal
Sehr gut geschrieben.
Ist die Migration ander herum, vom 2012 Standard auf 2019 Essentials auch so möglich?
Von “groß” zu “klein” musste ich bislang noch nie migrieren, vermutlich, wenn es nur um die FSMO-Rollen geht, wird das schon klappen.
Auf jeden Fall bevor man so etwas live macht, in einer Testumgebung mit einem Backup des Live-Systems durchspielen.
Hallo Andy,
wir laufen derzeit auf einer 2012 Standard Activ Diretory Domäne und wollen auf 2019 migrieren.
Unser Dienstleister hat jetzt gemeint, dass wir das ganze in 2 Schritten machen müssen:
Also von 2012 auf 2016 und dann erst auf 2019. Was Du schreibst, steht dem ja dann entgegen. Ist also nicht
notwendig, wenn ich das richtig verstehe?
Viele Grüße
Raier
Hallo Rainer,
die Standard-Ausgaben unterscheiden sich vom Essentials Server.
Ich kenne nun eure Umgebung nicht daher ist es schwer zu sagen, ob zunächst der Schritt zu Server 2016 gegangen werden muss, bevor man auf 2019 oder gleich auf 2022 gehen kann.
Da sind solche Faktoren wie verwendete Rollen-Dienste und Dritt-Anbieter-Anwendungen zu beachten.
Ihr könnt ja bei eurem Dienstleister mal nach den genauen Hintergründen fragen, dann kann man das besser Hinterfragen bzw. Abklären.
Hallo Andy,
hast Du schon mal einen Server 2012 Essentials auf Server 2019 Essentials hochmigriert? Wie ist hier die Vorgehensweise, ist das so wie in diesem Blog beschrieben, da Microsoft sagt, bitte die Software im Migrationsmodus installieren und dann die weiteren Schritte befolgen.
Hab einen voreingerichteten Server 2019 Essentials und würde ungern nochmals von vorne beginnen.
Gruß und Danke vorab
Hallo Thomas,
mit Essentials Servern arbeite ich nicht mehr, daher gibt es meinerseits keinen Erfahrungswert mit dieser Migration.
Hallo Andy,
ich muss einen Windows Serveer Essential 2016 auf einen Windows Server 2022 Std. migrieren. Sollte wohl gleiches Vorgehen sein. Ich verstehe nur nicht Deine Randbemerkung mit “Mit diesem Wechsel hat sich dann auch die etwas unschöne Sache mit dem “Nicht-Ändern-können” der Kennwortrichtlinie erledigt…..”
Bitte mal erläutern.
Gruß Marcel
Die Bemerkung kommt aus einer Kunden-Situation heraus, dort konnte unter Essentials die Kennwortrichtlinie nicht verändert werden, nach dem Upgrade ging das dann.
“nach dem Upgrade ging das dann.”
Du meinst nach der Migration
Inplace Upgrade/Migration, ja.
“Inplace Upgrade/Migration, ja.”
Hast du nun in der Konstellation den Essentional also erst Upgegradet und dann die Migration auf eine neue Hardware gemacht?
In diesem Szenario war es so, das auf einem neuen Server der W2022 installiert ist und ganz klassisch die Migration der Domäne durchgeführt wurde.
So will ich die Migration auch durchführen. Eben ganz klassisch. Und da ist mit Deiner Randbemerkung mit der PW Richtlinie zu rechnen oder nicht?
Ich kann nicht sagen, ob diese Thematik mit der PW-Richtlinie bei allen Essentials vorkommt, wir hatten bei diesem einen Kunden dieses Problem, das unter Essentials die Richtlinie nicht geändert werden konnte. Nach der Migration ging es dann.
Also konnte unabhängig von einer Migration grundlegend diese nicht verändert werden. Auch als er noch nicht migriert worden ist.
Genau so war es.
Aber nach der Migration?
Nach der Migration gab es das Problem mit der Richtlinie nicht mehr.