Farewell Small Business Essentials Server
Dieser Blog war nur eine Frage der Zeit, aber es war klar, dass er kommen wird (und leider muss). Nachdem mit dem Windows Server 2019 lediglich das Lizenz-Modell des SBE übriggeblieben ist, gibt es zwei Möglichkeiten in welche Richtung eine Small Business Server Umgebung entwickelt werden kann.
- Windows Server Standard
- Synology NAS
Den Weg in Richtung Windows Server Standard (also aktuell Windows Server 2019 oder 2022) wähle ich, wenn sich in der SBE-Umgebung eine Anwendungslandschaft etabliert hat, sprich einige Applikationsserver vorhanden sind und dazu auch noch virtualisiert wird.
Spoiler
Man kann aus zwei Synology NAS Systemen (dem darauf laufendem Synology Directory Server) und zwei Intel NUC PCs (als Hyper-V Hosts) ebenfalls eine interessante Infrastruktur bauen, dass soll aber das Thema in einem anderen Blog sein.
Migration
Die Umstellung auf Windows Server Standard verläuft wie im Folgenden dargestellt.
- Installation des neuen Servers als Member-Server in der bestehenden Domain
- Erstellen eines domain-basierten DFS-Roots
- Migration von vorhandenen Freigaben und der bereitgestellten Daten in das domain-basierte DFS
- Anpassung von Gruppen-Richtlinien und des Login-Scripts auf die Freigaben die nun über das DFS auf dem neuen Server (der ja aktuell noch als Member-Server läuft) abgebildet werden
- Heraufstufen (Promote) des neuen Member-Servers zu einem zweiten Domain-Controller und anpassen dessen DNS-Einträge
- Verschieben der FSMO auf den neuen Server
- Entfernen der Active Directory Zertifikatsdienste (mit der Webregistrierung muss beginnen werden) und zwingend danach einen Neustart durchführen
- Herunterstufen (Demote) des alten Servers
- Spätestens jetzt eventuell vorhandene Drucker auf dem Server migrieren
- Den alten Server aus der Domäne entfernen, oder besser erst einmal 14 Tage ausgeschaltet lassen (falls man was vergessen hat)
- Den domain functional level und den forrest functional level heraufstufen
Jeden der genannten Schritte werde ich hier nicht im Detail ausführen, dafür verkaufen andere Webseiten ganze Migration-Guides und ich denke, dass robocopy geläufig sein sollte.
Was ich aber für sinnvoll halte ist, sein (mein) Schaffen zu überprüfen. Sprich verhalten sich die Systeme so wie ich mir das vorstelle. Darum werde ich unten eine Reihe von Tests beschreiben, mit denen eine Prüfung zum jeweiligen Stand möglich ist.
Zu den Schritten 1 bis 4
Die Installation des Member-Servers ist selbstredend und da er im Verlauf der Migration ein Domain-Controller wird, sollte er auch gleich eine statische IP bekommen.
Wenn alle Scripte und GPOs angepasst sind, sollten auf den neu eingerichteten Member-Server auch die Zugriffe erfolgen. Genauso wichtig ist es, dass der alte Domain-Controller keine Zugriffe über SMB mehr zeigt.
# Anzeige von offenen Dateien über die SMB-Shares auf dem noch aktuellen Domain-Controller
Get-SmbOpenFile
Das folgende Beispiel finde ich gut, da es einen “false positive” zeigt.
Eine Session (dazu noch eine Anmelde-Sitzung) haben wir, dass NAS zur Datensicherung vergnügt sich noch mit diesem DC. Sobald wir den neuen DC und damit auch einen weiteren DNS haben, muss auf allen Clients dieser neue DNS auch eingetragen werden (der alte DC ist ab Schritt 8 nicht mehr vorhanden).
Zu Schritt 5
Mit Install-WindowsFeature muss auf dem Member-Server sowohl das Active-Directory als auch der DNS installiert werden, was in einem Schritt möglich ist.
# Installation des Active Directory und DNS
Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeAllSubFeature
Nun lauert im Server-Manager versteckt was früher der DCPromo war, in Form eines Wizards zur Fertigstellung des Domain-Controllers. In diesem Fall wird der Server als weiterer DC in die bestehende Domain und Forest integriert.
Zu Schritt 6
Der neue Server muss nun, wenn er funktional wirklich ein Domain-Controller ist, den NETLOGON- und den SYSVOL-Share bereitstellen. Bei mehreren Migrationen von Windows Server 2012 SBE (auch R2) auf Windows Server 2019 war das nicht der Fall und jedes Mal, war eine dysfunktionale SYSVOL-Replikation der Grund.
Die Lösung dazu aber immer beeindruckend einfach, der als neuer Domain-Controller gedachte Windows Server 2019 wurde wieder aus dem AD entfernt (demoted) und die Replikation auf dem Windows Server 2012 repariert. Danach den Windows Server 2019 wieder zum Domain-Controller promoten und schauen, ob die beiden Shares nun verfügbar sind. Alle Maßnahmen, bei denen man die Shares auf anderem Wege erstellt hat, führten zumindest bei mir, früher oder später zu Problemen.
# Anzeige des SysVol und Netlogon Shares
Get-SmbShare | Where-Object { $_.Description -match "Logon server share" }
Zum Verschieben der FSMO-Rollen, wird der folgende PowerShell-Befehl verwendet.
# Verschieben der FSMO-Rollen
Move-ADDirectoryServerOperationMasterRole -Identity Neuer-Domain-Controller -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
Sollte der Befehl funktionieren, hat man mit einem Rutsch alle Rollen migriert. Ich schreibe hier bewusst im Konjunktiv, da auch hier gelegentlich das Problem aufgetreten ist, dass der Befehl nicht wie erwartet funktioniert.
Dann haben die beiden folgenden Möglichkeiten bisher zum Erfolg geführt.
- Verwenden von Move-ADD… mit immer nur einer Rolle
- Verschieben der Rollen in den entsprechenden MMCs
# Abfrage ob die FSMO-Rollen nun auf den neuen DC sind
netdom query fsmo
Klar, kann man die Rollen auch mit PowerShell abfragen, dazu sind aber zwei Befehle notwendig, bzw. man muss in unterschiedlichen Kontexten arbeiten.
# Abfrage ob die FSMO-Rollen nun auf den neuen DC sind
Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster
Hier alle drei Aufrufe als Screenshot.
Abschließend schaue ich immer, ob die wichtigen Active Directory Dienste laufen.
# Anzeige von wichtigen Diensten für das Active Directory
Get-Service adws,kdc,netlogon,dns
Wie vielleicht bisher schon zu sehen war, teste ich möglichst viel und zwischendurch, um ein Gefühl zu bekommen, ob die Migration sauber läuft. Das hat sich über die Jahre hin als sinnvoll herausgestellt, da oftmals nur kleine Korrekturen zwischendurch notwendig waren und nicht am Ende ein großes nicht sauber funktionierendes Nichts steht 
Zwischen Schritt 6 und 7 kann man ein paar Tage vergehen lassen. Man muss hier lediglich mit den Meldungen des alten Windows Server 2012 SBE leben, der ein Fehlen der FSMO-Rollen zurecht, als Lizenzverstoß reklamiert.
Zu Schritt 7
Bevor nun der alte Windows Server 2012 SBE seine Rolle als Domain-Controller verliert, müssen die Active Directory Certificate Services deinstalliert werden. Macht man das von Hand, zuerst die Certification Authority Web Enrollment und dann den Rest danach deinstallieren.
# Anzeige der Roles und Features
Get-WindowsFeature -Name ADCS-Web-Enrollment, ADCS-Cert-Authority, AD-Certificate
Auch mit PowerShell muss das in zwei Schritten erfolgen.
# Deinstallation der Active Directory Certificate Services
Remove-WindowsFeature -Name ADCS-Web-Enrollment
Remove-WindowsFeature -Name AD-Certificate
Nun ist ein Neustart zwingend notwendig, auch wenn das durch die PowerShell-Ausgaben nicht den Eindruck erweckt. Wird der vergessen, jagt man hinterher eine Reihe von komischen Dingen nach. Also nun einfach durchstarten (den alten Domain-Controller).
# Neustart des alten Servers
Restart-Computer -Force
Nach dem Neustart kann der alte Domain-Controller heruntergestuft werden.
Zu Schritt 8
Alle Informationen dazu kann man bei Microsoft hier nachlesen. Obwohl ein großer Freund von PowerShell, führe ich diesen Schritt immer in der GUI durch. Dazu im Server Manager einfach die Rolle Active Directory Domain Services entfernen.
Der Remove Roles and Features Wizard bietet einem danach die Möglichkeit den Server herunterzustufen.
Der Vorgang ist selbsterklärend, am Ende dessen muss eine Meldung ähnlich der folgenden vorhanden sein.
Ok, hier noch die Aktion in PowerShell.
# Windows PowerShell script for AD DS Deployment
Import-Module ADDSDeployment
Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -Force:$true
Mit einem Klick auf Demote im Wizard wird der Prozess gestartet und der Server startet nach dem Herunterstufen neu. Davor ist es sinnvoll einen Blick in die DNS-Einstellungen der Netzwerkkarte zu werfen, steht dort wie bei vielen Domain-Controllern in SBE-Umgebungen “nur” 127.0.0.1, ist es notwendig den DNS vom neuen Domain Controller mit einzutragen. Sonst geht die Anmeldung mit einem Konto aus der Domain schief.
Zum Schluss
Eigentlich war es das, aber die Erfahrungen der letzten Migrationen haben gezeigt das immer noch der eine oder andere Rest des alten Domain-Controllers zurückbleibt.
Diesen haben ich als Namespace-Server im DFS entfernt. Damit das ohne Probleme funktioniert sollte der alte Server noch vorhanden sein und für kurze Zeit als Member-Server arbeiten dürfen.
Der alte Domain-Controller (der nun keiner mehr ist) darf nun auch nicht mehr in der SYSVOL-Replication auftauchen.
Ein weiteres Problem, eher optischer Natur ist der Verbleib des alten Servers als Name-Server in der Reverse Lookup Zone (falls man überhaupt eine hat).
Hier diesen entfernen und wie im Bild oben zu sehen ist, für den neuen die aktuelle IP auflösen lassen. Im Allgemeinen ist es sinnvoll den DNS nach alten Einträgen zu durchsuchen und diese zu löschen.
Enjoy it, b!
) erfolgen. Wie dieser angelegt wird ist unter anderem in folgendem Artikel beschrieben:
Windows SBS and Essentials Blog 