Drucker im Active Directory (AD)

Löscht man einen Drucker, der auch über das Active Directory (AD) gelistet war kann es vorkommen das dieser nach dem Löschen weiterhin angezeigt wird. Richtet sich dann ein Benutzer neue Drucker ein wird dieser, schon gelöschte und damit nicht mehr vorhandene Drucker, erneut angeboten.

image

Damit stellt sich die Frage, wo den der Drucker im Active Directory noch vorhanden ist und wie er entfernt werden kann.

Der Drucker ist über den Server im AD zu finden, auf dem er bereitgestellt wurde. Diese Information muss also noch vorhanden sein. Zur Anzeige aktiviert man Users, Contacts, Groups, and Computers as containers und findet damit unter dem Computer Objekt des Servers die von ihm bereitgestellten Drucker.

image

Das Drucker Objekt, kann dann mit einem Rechtsklick und Delete gelöscht werden.

image

image

Danach ist man den Drucker wirklich los.

Enjoy it, b!

AD-Migration von Windows Server 2012 SBE auf Windows Server 2019

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.

  1. Windows Server Standard
  2. 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.

  1. Installation des neuen Servers als Member-Server in der bestehenden Domain
  2. Erstellen eines domain-basierten DFS-Roots
  3. Migration von vorhandenen Freigaben und der bereitgestellten Daten in das domain-basierte DFS
  4. 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
  5. Heraufstufen (Promote) des neuen Member-Servers zu einem zweiten Domain-Controller und anpassen dessen DNS-Einträge
  6. Verschieben der FSMO auf den neuen Server
  7. Entfernen der Active Directory Zertifikatsdienste (mit der Webregistrierung muss beginnen werden) und zwingend danach einen Neustart durchführen
  8. Herunterstufen (Demote) des alten Servers
  9. Spätestens jetzt eventuell vorhandene Drucker auf dem Server migrieren
  10. Den alten Server aus der Domäne entfernen, oder besser erst einmal 14 Tage ausgeschaltet lassen (falls man was vergessen hat)
  11. 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.

image

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

image

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.

image

# 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.

image

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

image

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 Smile

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

image

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

image

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.

image

Der Remove Roles and Features Wizard bietet einem danach die Möglichkeit den Server herunterzustufen.

image

Der Vorgang ist selbsterklärend, am Ende dessen muss eine Meldung ähnlich der folgenden vorhanden sein.

image

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.

image

Der alte Domain-Controller (der nun keiner mehr ist) darf nun auch nicht mehr in der SYSVOL-Replication auftauchen.

image

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).

image

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!

Fix der SysVol-Replikation (DFS-R)

Neulich stand ich vor dem Problem, dass nach dem Einspielen von neuen Windows 10 ADMX-Dateien diese nicht zwischen den Domain Controllern (DCs) repliziert wurden.

Einen ersten Hinweis gab dazu das DFS Replication Event-Log, mit dem Event 4012.

image

Der Vorschlag direkt im Text ist, den DC der nicht an der Replikation teil nimmt aus der Replication Group zu entfernen und wieder hinzuzufügen ist ehrlichgesagt Bullshit, dass ist bei der SysVol Relikation mit DSF-R nicht möglich. Vielmehr muss man eine authoritative synchronization für das mit DFS-R replizierte SysVol durchführen.

Um trotzdem einen Blick auf die SysVol Replication Group werfen zu können, installiere ich gerne auf allen DCs oder in größeren Umgebungen auf Management Servern die DFS Management Tools aus dem Windows RSAT.

image

Mit PowerShell ist das ebenfalls möglich und kann für viele DCs automatisiert werden.

# Hinzufügen der RSAT DFS-Management Tools
Add-WindowsFeature -Name RSAT-DFS-Mgmt-Con

So, wie funktioniert nun die authoritative synchronization des SysVol?

Authoritative SysVol Replikation

Start von ADSIEDIT (über die Suchfunktion auf dem DC) oder das Startmenü, dort liegt das Tool unter Windows Administrative Tools / ADSI Edit.

image

In diesem Fall war die Ausgangslage wie folgt

  • slabad01.vmlabs.local (DC = OK)
  • slabad02.vmlabs.local (Replikation schlägt fehl)

Der slabad01 sollte also die Autorität für die SysVol Replikation werden und obwohl die Replikation ohnehin nicht mehr funktioniert, muss davor auf allen DCs die DFS Replication beendet und auf Manual gestellt werden.

image

image

Nachdem ADSI Edit (mit administrativen Rechten) gestartet wurde, bleiben die Standard-Einstellungen wie sie sind.

image

Nach dem Klick auf OK, steht uns ein Klick-Marathon bevor. Die KB von Microsoft referenziert hier wie folgt:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=msDFSR-Enabled=FALSE

Das ist zwar korrekt stellt aber die genau umgekehrte Reihenfolge dar wie der eigentliche Weg ist. Dazu folgen wir dem nächsten Bild.

image

In den SYSVOL Subscription Properties setzen wir nun die beiden folgenden Werte:

msDFSR-Enabled=FALSE
msDFSR-options=1

Das nächste Bild zeigt beide Einstellungen.

image

Für alle anderen DC (bei mir ist es nur ein weiterer) muss ebenfalls msDFSR-Enabled=FALSE gesetzt werden.

msDFSR-Enabled=FALSE

Nun wird auf dem DC von dem die Replikation (Authoritative) aus erfolgen soll, die DFS Replikation wieder gestartet und auf Automatic gesetzt.

image

Nun findet sich im Event-Log der DFS Replication die ID 4114, diese indiziert das die Replikation dieses DC nicht aktiv ist (haben wir ja auch mit msDFSR-Enabled=FALSE deaktiviert).

Hoffentlich habt ihr ADSI Edit offen gelassen, nun wird nämlich der Wert für msDFSR-Enabled=TRUE gesetzt und eine Replikation mit DFSRDIAG POLLAD erzwungen.

DFSRDIAG POLLAD

image

Nun finden sich im Event-Log der DFS Replication die ID 4602, die besagt das auf diesem DC das SysVol wieder erfolgreich repliziert wird.

image

Für alle anderen DCs wird nun zuerst der Dienst für die die DFS Replication auf Automatic gesetzt und gestartet. Sobald der Event 4114 im DFS Replication Event-Log aufgetaucht ist, muss mit ADSI Edit für die restlichen DCs msDFSR-Enabled=FALSE wieder auf msDFSR-Enabled=TRUE gesetzt werden.

Im Anschluss muss auch auf jedem anderen DC ein DFSRDIAG POLLAD ausgeführt werden.

Dazu kann man einfach mal nachschauen ob im SysVol die fehlenden Richtlinien ankommen.image

Das Ereignis mit er ID 4604 meldet dann, dass die Replikation mit den anderen DCs eingesetzt hat und damit wäre auch das Problem gelöst.

Zusammenfassung

Zuerst wird auf dem DC der die autoritative Rolle einnehmen soll, die SysVol Replication wieder in Gang gebracht (er repliziert dann mit sich selbst) und im Anschluss die restlichen DCs mit eingebunden.

Enjoy it, b!

Windows 10 Gruppenrichtlinien

Hinweis: Inzwischen bezieht sich der Artikel auf die letzten ADMX-Dateien für Windows 10, also auf die Version 21H2. Darum habe ich ihn in meinem Blog auch auf Januar 2022 vorgezogen.

Damit Windows 10 innerhalb einer Windows Domäne sauber konfiguriert werden kann hat Microsoft die entsprechenden ADMX Vorlagen, welche die Grundlagen für die Gruppenrichtlinien (GPOs) darstellen veröffentlicht:

https://www.microsoft.com/en-us/download/103667

Die Installation der Vorlagen sollte über einen zentralen Speicher (Central Store – OK, ich verwende das deutsche Wort nicht mehr Winking smile ) erfolgen. Wie dieser angelegt wird ist unter anderem in folgendem Artikel beschrieben:

https://support.microsoft.com/en-us/kb/929841

Im Wesentlichen ist das Vorgehen nicht besonders schwierig:

Herunterladen der aktuellen Templates (hier für Windows 10 November 2021 Update (21H2)) unter

https://www.microsoft.com/en-us/download/103667

Installation des Pakets (Administrative Templates (.admx) for Windows 10 November 2021 Update.msi) auf einem Server oder PC was letztendlich in einem Verzeichnis C:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update (21H2)\PolicyDefinitions endet.

Von dort werden die Vorlagen (Templates) in den SysVol Ordner auf den Domain Controller (DC) kopiert:

xcopy "\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update (21H2)\PolicyDefinitions\*" "%LOGONSERVER%\SysVol\%USERDNSDOMAIN%\Policies\PolicyDef
initions\"

Und die Sprachdateien (Language Files) in einen für die Sprache entsprechenden Unterordner. Ich verwende auf meinen Server generell Englisch, da mir das Übersetzen von Fehlermeldungen zu mühsam ist. Damit ist es bei en-US

# kopieren der englischen ADMX Dateien en-us
xcopy "\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update (21H2)\PolicyDefinitions\en-us\*" "%LOGONSERVER%\SysVol\%USERDNSDOMAIN%\Policies\PolicyDefinitions\en-us\"
# kopieren der deutschen ADMX Dateien de-de
xcopy "\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update (21H2)\PolicyDefinitions\de-de\*" "%LOGONSERVER%\SysVol\%USERDNSDOMAIN%\Policies\PolicyDefinitions\de-de\"

Der hier verwendete Xcopy impliziert, dass die Eingabeaufforderung auf Laufwerk C: und elevated (als Administrator) ausgeführt wird.

In SBS Umgebungen eher selten, dafür ein größeren Umgebungen üblich ist der Einsatz von mehreren DCs. Hier sollte, bevor der Store eingerichtet wird, die korrekte Funktion der Replikation geprüft und sichergestellt werden. Die Vorlagen werden dann automatisch zwischen den Domain Controller repliziert.

Beim nächsten Öffnen der Gruppenrichtlinien (Group Policy Managements) werden die neuen ADMX Dateien aus dem Central Policy Store angezogen.

Update 2015-12-02:
Beim Einspielen in einer größeren Umgebung hatte ich prompt das Problem, dass die die DC nicht (mehr) repliziert haben. Aber im Internet ist man ja niemals alleine … hier ein Link zu einer Anleitung mit der sich bei mir der Fehler beheben ließ.

Enjoy it, b!

SYSVOL-Migration von FRS auf DFSR

Microsoft empfiehlt schon seit langer Zeit die Replikation des SYSVOL von FRS (File Replication Service) auf DFSR (Distributed File Service Replication) umzustellen. Um genau zu sein, kam diese Empfehlung mit Windows Server 2003R2 🙂 .  Das ist auch sinnvoll, da DFSR stabiler arbeitet und FRS mit dem Windows Server 1709 nicht mehr unterstützt wird.

Ich habe dann eine Reihe meiner Small Business Domains durchgeschaut und noch eine gefunden in dieser FRS zur Replikation verwendet wird. Das ist immer dann der Fall, wenn von sehr alten Versionen (hier ein Windows Server 2000 basiertes Active Directory) immer wieder auf neue Versionen migriert wurde. Die Historie in dieser Domain ist:

  • Windows Server 2000
  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2012R2

In Domains mit nur einem Domain Controller (DC), wie das bei dem Small Business Server oder Small Business Essentiales üblich ist, kommt es in der Regel zu fast keinen Problemen mit der Replikation. Denn es gibt nur einen DC, das bedeutet aber nicht das hier keine Replikation stattfindet, sondern dass der Server in der Regel sich selbst immer erreichen kann.

FRS oder DFSR?

Wie stellt man überhaupt fest, ob innerhalb des Active Directory (AD) mit FRS oder DFSR repliziert wird? Das kann über mehrere Möglichkeiten herausgefunden werden.

Im Ereignis-Protokoll auf einem (in einer SBS/SBE Domain auf dem einem) DC sind aktuelle Einträge vorhanden.

image

Im DFS Management wird KEINE Gruppe angzeigt, wie im folgenden Bild zu sehen ist. Darunter das Domain System Volume wenn auf DFSR umgestellt wurde.

FRS (File Replication Service)

image

DFSR (Distributed File System Replication)

image

Voraussetzungen

Damit eine Migration ohne Probleme läuft, sollten ein paar Bedingungen im Vorfeld erfüllt sein.

FRS muss fehlerfrei arbeiten, dass kann man gleich prüfen wenn man einen Blick in das Ereignisprotokoll des FRS wirft

Bei mehreren DC, erstelle ich eine Datei im NETLOGON-Verzeichnis und schaue ob diese auf den anderen DCs zeitnah auftaucht.

C:\Temp> echo "Test" > \Windows\SYSVOL\domain\scripts\test.txt

Zusätzlich muss die Domain im Domain-Mode mindestens auf Windows Server 2008 laufen.

image

Das kann mit PowerShell und Get-ADDomain geprüft werden.

# Den Befehl als Administraor in einer PowerShell-Sitzung ausführen
(Get-ADDomain).DomainMode
Windows2012R2Domain

Nun können wir die Migration starten.

Migration von FRS auf DFSR

Bevor die Migration gestartet wird mache ich, wenn nur ein einziger DC vorhanden und dieser virtualisiert ist, einen SnapShot. Darüber hinaus ist ein aktuelles Backup obligatorisch.

image

Bei einem Snapshot (oder Checkpoint) ist es wichtig, dass falls dieser in Anspruch genommen wird, alle Daten die seit dem Checkpoint erstellt wurden verloren gehen. Darum ist eine Migration des SYSVOL etwas fürs Wochenende.

Die Migration selbst erfolgt mit dem Tool dfsrmig.exe das in einer, als Administrator gestarteten CMD- oder PowerShell-Sitzung auf dem DC ausgeführt wird, der die PDC-Emulator Rolle besitzt. Bei nur einem Server / DC ist die Rollenverteilung klar, ansonsten kann diese wie folgt mit PowerShell geprüft werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
(Get-ADDomain).PDCEmulator
mt-sbs-1.DOMAIN.local

Wird nur Get-ADDomain verwendet, findet man den PDC-Emulator hier.

image

Die Migration selbst verläuft in vier Stufen mit dem folgenden Status von 0 … 3, die Informatik beginnt halt gerne bei 0 Smile

Status Start 0

Mit dfsrmig /setGlobalState 0 werden die Domain Controller auf Start gesetzt und die Migration kann beginnen.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 0

Die Meldung Invalid state change requested, rührt daher das auf diesem DC der Befehl schon im Vorfeld abgesetzt wurde und dieser sich schon im Status Start befindet.

image

Kontrollieren, ob alle DC sich final im Status Start befinden kann und sollte man mit dfsrmig /GetMigrationState.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /GetMigrationState

image

Bei mehreren DCs kann das schon seine Zeit dauern, letzte Woche habe ich bei zwei Servern ca. 10min gewartet bis dieser Status erreicht war. Hier ist ein wenig Geduld angebracht.

Status Prepared (Vorbereitet) 1

Mit dfsrmig /setGlobalState 1 wird nun im nächsten Schritt der DC in den Status Prepared versetzt und mit dfsrmig /GetMigrationState kann der Status wiederholt abgefragt werden.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 1

Wie im folgenden Bild zu sehen ist, benötigt auch ein einzelner DC seine Zeit. Dazu einfach einen Kaffee holen und mit dfsrmig /GetMigrationState den Status abfragen.

image

Status Redirected (Umgeleitet) 2

Mit dfsrmig /setGlobalState 2 wird nun die Phase 2 eingeleitet und alle DC in den Status Redirected gesetzt, was ebenfalls seine Zeit dauern kann.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 2

Natürlich liefert dfsrmig /GetMigrationState den aktuellen Zustand.

image

Damit ist die Phase 2 beendet und wir können uns der Phase 3 zuwenden und die Migration damit abschließen.

Status Eliminated (Entfernt) 3

Mit dfsrmig /setGlobalState 3 wird nun die Phase 3 und damit der Abschluss der Migration eingeleitet und alle DCs in den Status Eliminated gesetzt.

# Den Befehl als Administrator in einer PowerShell-Sitzung ausführen
dfsrmig /setGlobalState 3

Wie schon vorher liefert dfsrmig /GetMigrationState den Zustand und Status der Migration, im folgenden Bild waren wir nach gut 2min fertig.

image

So nun sind wir fertig, alle vier Schritte / Phasen sind durch.

Wie kontrollieren wir nun, ob alles sauber läuft?

Vertrauen ist gut, Kontrolle ist besser

Im DFS Management wird nun das Domain System Volume angezeigt und man kann es auch als Replikationsgruppe hinzufügen.

image

Dort sehen wir auch den migrierten SYSVOL-Ordner.

image

Zusätzlich verabschiedet sich der FRS mit einem “letzten” Eintrag im Ereignisprotokoll.

image

Im DFS Replication Ereignisprotokoll finden wir ebenfalls einen Eintrag, dass nun mit DFSR repliziert wird.

image

Bei mehr als einem Domain Controller, erstelle ich immer eine Datei im NETLOGON-Verzeichnis und schaue ob diese repliziert wird. Das Verzeichnis heißt ja nun auch nicht mehr SYSVOL, sondern SYSVOL_DFSR.

image

Wird nun ein weiterer DC hinzugefügt, dann verwendet dieser wie vor das Verzeichnis SYSVOL.

image

Die beiden ersten Server wurden „migriert” und der letzte in der Liste (blau umrandet) wurde nach der Migration hinzugefügt.

Enjoy it, b!

Aktive Computer im Active Directory

Für die Verlängerung von Lizenzen musste ich die Anzahl von Computern, die noch aktiv sind, ermitteln. Leider wurden zwar neue PCs stetig im Active Directory (AD) hinzugefügt, alte Computer-Konten aber einfach dort belassen.

Es bestand also die Notwendigkeit alle Computer zu finden die Ihr Passwort in den letzten 30 Tagen gewechselt hatten. Der Wechsel nach 30 Tagen ist der von Microsoft festgelegte Standard und kann über eine GPO geändert werden.

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age

Zur Auswertung macht es darum Sinn, hier nochmals einen Blick auf die Richtlinie zu werfen.

Geholfen hat mir dieser Einzeiler in PowerShell:

# Ermitteln der vorhandenen Computer im AD
Get-ADComputer -Filter {enabled -eq $true} -Properties * | select Name, DNSHostName, OperatingSystem, LastLogonDate, LastLogonTimestamp | FT Name, @{n='LastLogonTimeStamp';e={[DateTime]::FromFileTime($_.LastLogonTimeStamp)}} -A | Out-File c:\temp\pc.txt

Damit wird im Verzeichnis c:\temp eine Datei mit dem Namen pc.txt erstellt. Deren Inhalt entsprechend analysiert werden kann.

image

In diesem Fall, war der XX_WKS-5 seit März nicht mehr im Betrieb!

Enjoy it, b!

Windows Server 2016 SBE und DFSR 4012

Zum Problem

Eine vor gut 2 Monaten stattgefundene Migration von SBE 2011 auf Windows Server 2016 SBE hat wohl zu Problemen bei der Replikation geführt. Zumindest meldete rund 71 Tage danach der Zielserver das er ein Problem mit der Replikation hätte.

image

Analog dazu sieht die Meldung im Eventlog wie folgt aus.

image

Nachdem nun bekannt ist, dass ein Problem existiert, sollten wir das auch lösen können, irgendwie halt 🙂

Ein paar Hintergrund Informationen

Typischer Weise hat eine Domain im Small Business Umfeld nur einen Domain Controller, so auch diese Domain. Darüber hinaus wird die Art der Sysvol-Replikation (FRS oder DFSR) durch die Migration bestimmt. FRS ist für Windows server 2016 als deprecated gekennzeichnet, wird also nicht mehr wirklich unterstützt und damit sollte spätestens nach einer Migration (besser davor) die Replikation auf DFSR umgestellt werden.

https://blog.friedlandreas.net/2014/12/sysvol-migration-von-frs-auf-dfsr/

Die Lösung

Die Lösung des Problems liegt darin, dass man einen “D4” auf dem Domain Controller machen muss.

https://blogs.technet.microsoft.com/janelewis/2006/09/18/d2-and-d4-what-is-it-for/

Ich habe dazu die folgenden Schritte durch geführt um das Problem zu lösen.

Aus der Expertem GUI (cmd.exe als Admin gestartet) starten wir die adsiedit.msc und arbeiten uns dort durch den folgenden Pfad zum CN=SYSVOL Subscription.

image

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>

Dort öffnen wir den CN=SYSVOL Subscription mit einem Doppelklick (Grüner Kasten im Screenshot oben).

Hier finden wir die beiden Einträge msDFSR-Enabled und msDFSR-Options, welche wir von …

image

auf …

msDFSR-Enabled=FALSE
msDFSR-options=1

… ändern und hier bei der Änderung mit Apply und OK bestätigen. Da wir hier nur einen Domain Controller haben, brauchen wir hier keine weiteren Änderungen mehr in ADSIEDIT machen (es gibt ja keine weiteren DCs)!

Nur zur Vollständigkeit, läuft in der Domain (was auch beim Small Business Essentials möglich wäre) ein weiterer DC, dann müssen auf diesem die folgenden Einstellungen über ADSIEDIT gesetzt werden.

msDFSR-Enabled=FALSE

Danach starten wir die Active Directory Replikation, wieder aus unserem Experten GUI:

repadmin /syncall /AdeP

Im Eventlog finden wir danach die ID 4114, optional kann auf dem DC einfach den Service File Replication (FRS) bzw. DFS Replication (DFSR) neu gestartet werden.

image

Nochmals der Hinweis an dieser Stelle, FRS wird in Windows Server 2016 nicht mehr unterstützt und die Replikation sollte daher dringend auf DFSR umgestellt werden.

http://patrickvandenborn.blogspot.de/2017/06/windows-server-2016-frs-deprecated-how.html

Damit haben wir die Grundlage die Replikation wieder neu auf zu bauen. Dazu setzen wir wieder auf unseren (einzigen, und daher ersten DC) msDFSR-Enable auf True.

msDFSR-Enabled=TRUE

und erzwingen erneut eine AD-Replikation

repadmin /syncall /AdeP

Funktioniert dieser Call, dann meldet repadmin insgesamt 5x die Meldung SyncAll terminated with no errors.

image

Danach führe wir noch den Befehl DFSRDIAG mit der Option POLLAD aus.

DFSRDIAG POLLAD

Wenn alles gut geht, bekommen wir die Meldung Operation Successful zurück und dazu noch das Event 4602 im Eventlog.

image

So, jetzt haben wir unseren “D4” durch und alles ist wieder gut.

Enjoy it, b!

Integration von Windows 10 und SBE

Um Windows 10 mit einer Small Business Essentials Umgebung (SBE) sind zwei Dinge notwendig.

  1. Installation des SBE Client Connectors auf dem Windows 10 Client
  2. Anpassung der GPO auf dem SBE

Ausgehend vom aktuellsten SBE, dem Windows Server 2012 R2 Small Business Essentials (egal ob Role oder SKU) sind dazu folgende Schritte notwendig.

Installation des Client Connectors

Ein Download des Connectors von http://sbe/connect endet in folgender Fehlermeldung.

image

An unexpected error has occurred. To solve this issue, contact the person responsible for your network

Um das Problem zu lösen muss der Client Connector in einer aktuallisierten Version installiert werden, dazu gibt es mehrere Möglichkeiten.

  1. Download und Installation auf Windows 10, sowie anschließender Verbindung mit dem SBE
  2. Update des SBE damit gleich der richtige Client Connector zur Verfügung gestellt wird

Blogs dazu gibt es viele – ein Blick zu Microsoft ist hier sicherlich der erste Weg.

https://blogs.technet.microsoft.com/sbs/2015/11/17/client-connector-availability-with-windows-home-server-small-business-server-and-windows-server-essentials-for-supported-client-os/

und natürlich Winking smile

https://sbsland.wordpress.com/2015/11/ 

Der Download für Windows 10 ist hier (KB2790621) erhältlich und das Update für den Server hier (KB310585). Wenn wir davon ausgehen, dass wir bestimmt mehrere Windows 10 Client zu versorgen haben, macht die Installation von KB310585 auf dem SBE 2012 R2 sicherlich mehr Sinn!

Die Umleitung der Ordner

Nachdem die Windows 10 Clients auch in der SBE Umgebung integriert sind, besteht die Möglichkeit die Ordner den Clients auf den Server um zu leiten. Das klappt für Windows 10 nicht und im Dashboard erscheint die folgende Meldung.

image

Dashboard / Devices / Group Policy / Not Applicable

Der Grund dafür ist ein WMI Filter, der entsprechend angepaßt werden muss. Microsoft beschreibt das in folgenden Blog-Beitrag:

https://blogs.technet.microsoft.com/sbs/2016/01/22/wmi-group-policy-filter-issue-on-windows-10-breaks-folder-redirection-windows-server-2012-r2-essentials-windows-server-2012-essentials-and-windows-small-business-server-2011-essentials/

Im Wesentlichen handelt es sich um folgende Änderung.

# Vorhandener WMI Filter
select * from Win32_OperatingSystem where (Version >= "6.1%") and ProductType= "1" 

# Neuer WMI Filter
select * from Win32_OperatingSystem where Version like "10.%" or Version >="6.1"

Enjoy it, b!

Entfernen von Exchange 2007 im Verlauf einer Migration

Im Verlauf einer Migration von Windows Small Business Server 2008 auf einer der neueren Essentials oder Standard Versionen, muss Exchange aus dem Active Directory sauber entfernt werden. Das passiert an einfachsten durch eine Deinstallation von Exchange auf dem alten Small Business Server.

Allerdings musste ich im Verlauf von einigen Migrationen feststellen, dass das nicht immer so problemlos klappt. Letztendlich ist mir aber die Deinstallation von Exchange 2007 immer gelungen, dabei musste ich noch folgende zusätzliche Schritte tun.

Start der Exchange 2007 Deinstallation.image

Im folgenden Dialog alle aktiven Elemente deaktivieren.image

Danach startet die Deinstallation in Form eines Readiness Checks und läuft auf die folgenden drei Fehler / Probleme.

image

Fehler 1: Uninstall cannot continue. Database ‘Mailbox Database’: This mailbox database contains one or more mailboxes ..

Fehler 2: Uninstall cannot continue. Database ‘Public Folder Database’: The public folder database …contains the following offline address books(s).
.\Standard-Offlineadressliste

image

Fehler 3: This computer is configured as a source transport server for 1 connector(s) in the organization …

Lösung von Fehler 1

Exchange Management Console / Recipient Configuration / Mailbox – löschen aller vorhandenen Mailboxen. Falls der Administrator eine Mailbox hat, kann diese nicht gelöscht werden – hier ist es notwendig diese zu deaktivieren.

Danach wird über die Exchange Management PowerShell Console die Mailbox Database gelöscht.

Get-MailboxDatabase
Remove-MailboxDatabase -Identity "Mailbox Database"

Lösung von Fehler 2

Die Public Folder Database läßt sich über ADSIEdit löschen:

http://blog.dargel.at/2012/01/19/remove-public-folder-using-adsiedit/

Dazu starten wir ADSIedit mit erweiteren Rechten als Domain Admin und verbinden uns (mit Connect to) zum Configuration Naming Context.

image

von dem wir uns wie im Blog beschrieben zu CN=Public Folder Database durcharbeiten, um diese im Anschluss zu löschen.

image

Lösung von Fehler 3

Exchange Management Console / Organization Configuration / Hub Transport / Send Connectors – löschen aller vorhandenen Connectoren.

Exchange Management Console / Server Configuration / Hub Transport / Receive Connectors – löschen aller vorhandenen Connectoren.

Danach mit Retry den Readyness Check laufen lassen. Danach kann die Deinstallation von Exchange 2007 fortgesetzt werden.

Enjoy it, b!

Wiederbelebung eines Windows Server 2012 R2 SBE, Event 2228 …

… war heute Nacht bei einem Kunden agesagt! Hyper-V Replika und VMs sind eine feine Sache, allerding muss man auch wissen was man damit anstellen kann.

Ausgangssituation (was der Admin meines Kunden wollte)

Da die Installation einer LOB Anwendung am recht neuen SBE stattfinden sollte und der Hersteller der Anwendung sich 100% sicher war, dass dies “kein Problem ist” hatte sich der Admin (nein nicht ich) dazu entschlossen, den bestehenden SBE zu exportieren und modifiziert (andere IP-Adresse in einem anderen Subnetz) als Testsystem zu verwenden.

Dazu hat er folgende Schritte ausgeführt:

# - Hyper-V Host 1
Export-VM –Name sbs.sbsland.local –Path \\mx-whv-2\Temp
# - Hyper-V Host 2
Import-VM –Path 'D:\Temp\sbs.sbsland.local\VirtualMachines\5AE40946-3A98-428E-8C83-081A3C6BD18C.XML'

Danach wurde der SBE auch gestartet, eine Anmeldung war leider nicht möglich – da laut dem Server die Anmeldung nicht authentifiziert werden konnte. Eine lokale Anmeldung mit dem Administrator war jedoch möglich. Ein Blick in das Eventlog und in die Services.msc offenbarte, das ein Start des Active Directories fehlgeschlagen war.

Directory Service, ActiveDirectory_DomainService, 2228

An dieser Stelle klingelte mein Telefon… Confused smile die Testumgebung musst ja fertig werden …

Was war passiert?

Beim Start des ““importieten” SBE wurde vergessen das Netzwerk zu ändern und so waren auf einmal 2 Domain Controller im Netzwerk, von denen der zweite (importierte) den Dienst verweigerte, Ein Blick in sein Eventlog offenbarte das Problem.

image

Mit dem Zeitdruck doch noch das Testsystem fertig zu bekommen, entschlossen wir uns das AD über den DSRM (Directory Services Resource Mode) zu “reparieren”.

Authoritative Restore des AD

Dazu waren folgende Schritte notwendig:

  1. Anmeldung als lokaler Administrator und Konfiguration des Systems für den DSRM
    bcdedit /set safeboot dsrepair

    Neustart des Servers und erneute Anmeldung als lokaler Administrator.

    http://blogs.technet.com/b/activedirectoryua/archive/2008/11/20/how-to-start-in-directory-service-restore-mode-dsrm-in-windows-server-2008-and-windows-server-2008-r2.aspx

  2. Start von ntdsutil und Ausführung der folgenden Schritte
    ntdsutil
    ntdsutil: activate instance ntds
    
    # Active instance set to "ntds". 
    
    ntdsutil: authoritative restore
    
    # die Domain heisst sbsland.local
    
    authoritative restore: restore subtree "CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=sbsland,DC=local"
    
    # Authorative Restore completed successfully.
    
    
    

  3. Danach wurde der DSRM wieder deaktiviert
    bcdedit /deletevalue safeboot
  4. Konfiguration einer neuen IP-Adresse 192.168.32.11
  5. Disable des DHCP-Servers
  6. Neustart des SBE

So, der SBE als Testsystem läuft, hätte der Admin den importierten SBE mit einem isolierten virtuellem Netzwerk (Private Virtual Switch) gestartet, wäre uns das ganze Theater erspart geblieben.

Enjoy it, b!