Ein Hilferuf ereilte mich in den Nachtstunden des letzten Wochenendes bei einem befreundeten Kollegen. Er musste sich eigentlich um eine Datenbank kümmern, dessen zugehörige Applikation nicht mehr wollte, hatte jedoch wesentlich mehr zu tun. Es handelte sich um ein B2B Anwendung im Transportgewerbe, über jene Disponenten Lenk- und Ruhezeiten, sowie Standorte von Fahrern auf großen Bildschirmen in einem Logistikcenter einsehen konnten. Diese Applikation war für den Kunden bitter notwendig, da jener ohne diese Applikation quasi blind ist oder zumindest auf ältere Prozesse, die längst nicht mehr eingespielt waren, zurückgreifen musste.
Er hatte es mit einem Unternehmen zu tun, dessen IT an ein externes Unternehmen ausgelagert war. Die Herrschaften gingen mit den Zugangsberechtigungen äußerst sparsam um, so dass er nicht sofort in die Details schauen konnte. Kurz: Ihm fehlten die Rechte, er hatte jedoch durchaus fragwürdige Symptome.
Zeitweise konnte er sich gar nicht mehr am SQL-Server anmelden. Ein wenig später schon. Er führte Änderungen an der Applikation aus, diese kurzfristig zum Erfolg führten, ein wenig später jedoch wieder abstürzten. In seinen Protokollen sah er lediglich fehlgeschlagene Anmeldeversuche an einem SQL-Datenbankserver. Später versuchte er, mit dem externen Unternehmen eine direkte SQL-Anmeldung außerhalb des Active-Directory zu vereinbaren, die stellten sich jedoch quer – da könne ja jeder kommen. Ich bat ihn, mal die Anwender zu fragen, ob sie zeitweise „Anmeldeprobleme“ beobachteten. Die Antwort von zumindest einer Anwenderin, jene gemeinsam mit ihm die Nachtschicht verbrachte, ist da wohl mehr als eindeutig gewesen. Als er sich zum Schluss an den Geschäftsführer wandte, bekam er die dringend benötigten Zugangsinformationen zum HyperV Host und zur Domäne, um im Active Directory gemeinsam mit mir nachzuschauen, denn ich hatte ja einen Verdacht geäußert.
Ich musste nicht lange suchen, denn ich filterte die Ereignisse und fand die entsprechenden Probleme. Notiert wurden folgende Probleme:
NTDS, 1113, Eingehende Replikation deaktiviert NTDS, 1115, Ausgehende Replikation deaktiviert NTDS, 2103, Nicht unterstützte AD-Wiederherstellung
Würde man 1115 und 1113 losgelöst von 2103 betrachten, sprich 2103 ignorieren, so müsste man auf den Gedanken kommen, dass man die inbound und outbound Replication einfach wieder aktivieren kann und dann ist alles gegessen – der (unwirksame) Befehl aus der Hilfe wäre also:
repadmin /options -DISABLE_INBOUND_REPL
Wenig später würde einem die Anfrage
repadmin /showreps
wieder mitteilen, dass nichts geht.
Doch besonders NTDS 2103 ist hier ziemlich aufschlussreich:
The Active Directory database has been restored using an unsupported restoration procedure. Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused. User Action See previous event logs for details. For more information, see Help and Support Center at http://support.microsoft.com.
Genauer anzeigen lässt sich das mit
repadmin /showutdvec namedeserstendc dc=domain,dc=tld
und
repadmin /showutdvec namedeszweitendc dc=domain,dc=tld
wenn man dann die USN’s vergleicht. Je größer die Lücke, desto eklatanter das Problem.
Dieses Verhalten ist absolut typisch für einen USN Rollback, für viele jedoch sehr schwer zu identifizieren. Da ich fortwährend davon spreche, jedoch immer wieder dazu gefragt werde, muss ich das wohl mal erläutern. Was also ist ein USN-Rollback?
Erklärung: Active-Directory ist eine ziemlich große Datenbank. Jedes Objekt in dieser Datenbank bekommt quasi eine Seriennummer. Die Objekte (Computerkonten und Benutzerkonten) werden unter den Domänencontrollern repliziert, in diesem Fall erhöht sich die Seriennummer der Transaktion. Passt die Seriennummer (USN) zur Replikation nicht mehr, so kann nicht mehr repliziert werden. Die Domänencontroller werden irgendwann feststellen, dass sie ein Problem haben. Die ein- und ausgehende Replikation wird folglich deaktiviert. Das ist also das typische Problem eines USN-Rollbacks. In älteren Generationen von Active Directory ist zeitweises Anmelden an einem oder dem anderen Domänencontroller (wie in diesem Fall) zwar noch möglich, immer jedoch wenn die Ressource an einem anderen Logonserver hängt, hat man verloren. Das passte auch zu der Symptomatik von meinem Kollegen. Zudem wurde auch der beim Kunden eingesetzte Windows Server 2003 von Microsoft längst nicht mehr unterstützt.
Es ist relativ umfangreich, eine solche Problematik aufzulösen. Das hatte ich bereits mehrfach geschrieben, und in diesem Fall sprach ich in einem Tweet sogar äußerst sauer von einem Wald- und Wiesenadministrator, diesen Tweet hatte ich zwischenzeitlich wieder gelöscht, weil er mir als zu harsch erschien. Zur Lösung gibt es eine Holzhammermethode von John Lose (Neue Invocation-ID) die ich bevorzuge, um ein Unternehmen schnell wieder online zu bekommen, und die von Microsoft vorgeschlagenen Empfehlungen, alle zu finden in KB875495, je nachdem, welche FSMO-Rollen die betreffenden Controller ausführen. Am Ende läuft es im Regelfall jedoch immer darauf zurück, den kaputten DC zwangsweise zu entfernen und dann den Müll aufzuräumen – Link, und Master-Rollen möglicherweise gezwungenermaßen auf einen anderen zu übernehmen.
Nach der zeitintensiven Lösung musste ich meinem Freund und seinem Kunden in den Abendstunden am Telefon oben genanntes erklären, um das Problem zu verdeutlichen. Und dann gab‘ ich ihnen noch einen Tipp mit auf den Weg:
Virtualisierung ist ja wirklich schön. Aber: Es ist immer noch absolut verboten, dass
- Ein Domänencontroller per P2V virtualisiert wird. P2V ist die möglichkeit, einen physikalisch vorhandenen Server während des Betriebs, online in eine virtuelle Maschine zu migrieren
- Ein Domänencontroller von einem Snapshot zurückgespielt wird (oder überhaupt jemals ein Snapshot von einem Domänencontroller gemacht wird)
- Ein Systemabbild von einem Domänencontroller zurückgespielt wird – Die klassische WBAdmin-Sicherung ist notwendig und wird in jedem Best Practices Analyzer auch – sofern nicht umgesetzt – bemängelt
- Ein Domänencontroller „gespeichert“ wird, das passiert üblicherweise auch während VSS-Sicherungen auf HyperV Hosts – Siehe auch folgender Beitrag
Nachdem wir uns den HyperV Host angesehen hatten, entdeckten wir in der Protokollierung die Rückspielung des Snapshots eines Domänencontrollers. Es war zudem beschämend, dass von relativ vielen Servern auf diesem Host Snapshots angelegt wurden, der (zwar bemängelte) Performanceeinbruch, der daraus folgte, wurde jedoch nicht als hausgemachtes Problem wahrgenommen.
Zum anderen gilt – und das sage ich jedem Kunden – eine Inhouse-IT, die gelerntes richtig umsetzt, ist immer vorzuziehen. TheCampus und COM bieten wunderbare Kurse für die notwendigen Prüfungen. Danach kann jeder ein AD und eine Infrastruktur bedienen. Das schont den Geldbeutel und schont die Nerven.
Vielen Dank für die Beachtung!