Das Problem
Einem Kunde steht nach einer Fusion der Umzug in ein Rechenzentrum bevor. In diesem Zug möchte er auch Teile seiner Infrastruktur verändern. Natürlich sollte schon alles korrekt funktionieren, bevor man sich daran macht. Das just dies nicht der Fall war zeigte sich, als einer der beiden Domänencontroller seinen schlechten Tag hatte. Plötzlich waren weder eine Anmeldung noch der Zugriff auf die Netzlaufwerke möglich, bis DC1 neu gestartet wurde. Daher musste man dieses Problem vorab untersuchen und lösen.
Erstes Umsehen
Immer noch ist “dcdiag” ein Tool mit dem man sich schnell mal einen Zustand eines Domain Controllers ansehen kann.
Schon während der Ausgabe konnte ich Fehlermeldungen über Fehlermeldungen sehen.
Als erster Eintrag war folgender Fehler zu finden.
"Starting test: NCSecDesc
Fehler: NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION besitzt keine Replicating Directory Changes In Filtered Set
Zugriffsrechte für den Namenskontext: DC=DomainDnsZones,DC=blafasel,DC=local
Fehler: NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION besitzt keine "
Weiter habe ich erstmal nicht gelesen. Da es durchaus sein kann, dass ein Fehler die nachfolgenden auslöst, bin ich zunächst auf Recherche gegangen.
Die Ursache war schnell geklärt und behoben. Bei der letzten Schema-Erweiterung wurde die Anpassung für RODCs (Nicht beschreibbare DCs) vergessen.
DC2 war ohne Befund.
Während ich die nächste Replikation abwartete, schaute ich mir einfach ein paar weitere Grunddaten des Active Directory an. Mit “netdom query” eine Abfrage der Flexible Single Operation Master-Rollen (FSMOs), mit “Get-Forest” und “Get-ADDomain” Basis-Informationen zur Gesamtstruktur (= Forest) und Domäne. Beide Funktionsebenen (= functional level) waren noch noch auf Windows2003. Die DCs waren beide schon auf mindestens Windows 2008 R2. Somit gab es keinen Grund sowohl die Domänenfunktionsebene als auch die Gesamtstrukturebene nicht auf Windows 2008 R2 zu setzen.
Ersteres wird in “Active Directory Benutzer und Computer” geänderte, letzteres in “Active Directory-Domänen und Vertrauenstellungen”.
Gedacht, getan.
Wieder habe ich einen Replikationszyklus abgewartet.
Weil ich schon dabei war, habe ich danach den Active-Directory Papierkorb ebenfalls gleich aktiviert. Die neuen Funktionalitäten, die mit der Erhöhung der Funktionslevel kommen sollte man schon nutzen. Der AD-Papierkorb ist definitiv eine davon.
Das dazugehörige Commandlet (cmdlet) ist
"Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=blafasel,DC=local’ –Scope ForestOrConfigurationSet –Target ‘blafasel.local’".
Weitere Probleme
Mittlerweile lieferte “dcdiag” auf DC1 nur noch den Fehler, dass es in den letzten 24 h mind. einen Fehler gegeben hätte.
Die Überprüfung der AD-Replikation mit “repadmin /showrepl” meldete nur erfolgreiche Replikationen.
Aber ich grübelte die ganze Zeit schon nach einem neueren Tool zum Replikationsmonitoring, dass ich vor längerem mal an anderer Stelle verwendet habe. Just wollte es mir nicht einfallen.
Als kleinen Test erstellte ich im Netlogon-Ordner von DC1 eine Datei, um die Replikation zu prüfen. Per UNC-Pfad wollte ich auf DC2, aber ich erhielt nur eine Fehlermeldung, dass der Pfad nicht existiert. Eine Kontrolle direkt am DC2 bestätigte das. Schlimmer noch. Der komplette Sysvol-Baum fehlte.
“Suchen und Finden” war schnell erledigt. Das Problem tritt anscheinend häufiger auf. Dieser Knowledgebase-Artikel hilft einem auf die Beine. .
Da ich mittlerweile dazu übergehe in jedem Active Directory eine “Warten aufs Netzwerk”-Richtlinie zu erstellen und es hier auch noch keine gab, öffnete ich die Gruppenrichtlinien-Verwaltung.
Yipieh! Eine Fehlermeldung!
“Das Gruppenrichtlinineobjekt konnte nicht geöffnet werden. Möglicherweise verfügen Sie nicht über die erforderlichen Rechte. Das System kann den angegebenen Pfad nicht finden.”
Das will man als Administrator sehen.
Des Rätsels Lösung: der Rebuild des Sysvol-Baums hat zwei Ordner “Policies_NTFRS_0157eeb1” und “scripts_NTFRS_0157ee63” angelegt.
Da ich auf die Schnelle nichts gefunden habe, wie man die Verwaltung zu dem neuen Verzeichnis umleitet, habe ich zwei neue Ordner “Policies” und “scripts” erstellt und die Inhalte der anderen Ordner jeweils rein verschoben.
Prompt ging die Gruppenrichtlinien-Verwaltung wieder fehlerfrei auf.
Aufräumen
Die NTFRS-Replikation verlief endlich fehlerfrei.
Da Microsoft empfiehlt die FSMO-Rollen auf dem DC mit dem aktuellsten Betriebssystem in der Domäne zu betreiben, stand noch deren Umzug an.
Etwas PowerShell-Mojo hat auch das erledigt.
Move-ADDirectoryServerOperationMasterRole -Identity "DC2" -OperationMasterRole SchemaMaster,RIDMaster,InfrastructureMaster,DomainNamingMaster,PDCEmulator
Mittlerweile war ich schon einen halben Tag über diesem Problem.
So einfach wollte ich dieses AD nicht verlassen ohne nicht noch alles zu Ende geprüft zu haben.
Zwischenzeitlich fiel mir wieder auch ein, wie das Replication Monitoring Tool hiess: Active Directory Replication Status Tool.
Während der Download lief, rein in “Active Directory-Standorte und -Dienste”.
Natürlich hatte der ursprüngliche Dienstleister das AD einfach so angelegt ohne wirklich alles sauber zu konfigurieren.
Es fehlte ein sauberes Subnetz und der Standortname war immer noch “Standardname-des-ersten-Standorts”.
Ohne Frage funktioniert alles auch ohne diese Einstellungen, aber schön und ordentlich ist meines Erachtens etwas anderes.
Damit war als nächste Aufgabe ein “Subnetz anlegen” und den “Standortname zu ändern” zu erledigen.
Ausserdem tauchte ein dritter DC in der Serverliste auf.
Das sah doch verdächtig nach einem in der Vergangenheit unsauber entfernten DC aus?
Der Server war nicht mehr im Active Directory.
Damit stand mir potentiell ein “metadata cleanup” bevor.
Während ich mich im “Ntdsutil” durch die Verzeichnisse hangelte und schließlich bei der Liste der Domänen Controllern angelangt war, war schnell klar, dass die Entfernung schon korrekt durchgeführt worden war. Allerdings hat man früher vergessen den Eintrag aus “Active Directory-Standorte und -Dienste” zu entfernen. Das ist stets manuell zu tun.
Fast am Ende
Mittlerweile war der Download beendet, das Active Directory Replication Status Tool installiert und gestartet. Wie erwartet, lief die AD-Replikation immer noch fehlerfrei. Das Tool liefert aber noch weitere Informationen, wie z.B. die “Tombstone Life Time”. Das ist der Zeitraum, den das AD gelöschte Daten aufhebt, bevor sie wirklich gelöscht werden. Der war hier noch 60 Tage und somit ein Relikt aus der Zeit vor Windows 2003 SP1. (Standard ist inzwischen 180 Tage. Bei einem neueren DC wird die “Tombstone Life Time” nicht automatisch migriert.)
Mit etwas PowerShell war das schnell angepasst.
"Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=blafasel,DC=local" -Partition "CN=Configuration,DC=blafasel,DC=local" -Replace @{tombstoneLifetime='180'}"
Geschafft
Nach mehr als einen halben Tag war das Kunden-AD wieder in einem ordentlichen Zustand.
Den Änderungen an der Infrastruktur steht nun nichts mehr im Weg.