USN Rollback ausgehebelt?
Server Image erfolgreich zurückholen.

zurück zum Index

 

Es ist ein Dilemma! Lang hat man als Supporter gearbeitet um eine kleine Domain auf sichere Beine zu stellen.
Die Predigt lautete: nie nur einen DC (Domainserver) und regelmäßig sichern.

Nach unerquicklichen Erfahrungen haben sich viele, wenn auch zähneknirschend daran gehalten.
Ein betagtes Schätzchen wurde als DC wiederbelebt und damit war man glücklicher, umständliche 
Sicherungen (Systemstate) wurden immer ordentlich durchgeführt.

Dann wurden sogenannte Images der große Hit und durch diverse Anbieter eine wesentlich schnellere Lösung
geboren, mal eben den DC zu sichern und das sogar Online im laufenden Betrieb. Fatal: das funktionierte offensichtlich prächtig solange man nur einen einzigen DC in seiner Domain stehen hatte.
Aber nur augenscheinlich - weil auch hier natürlich Änderungen am AD verloren gehen, dies aber niemand moniert. Bis dann plötzlich ein Client spinnt, oder sonstige Dinge passieren - völlig unerklärlich?
Diejenigen, die sich der nachvollziehbaren Ausfallsicherheit zu einem BackupDC durchgerungen hatten, standen urplötzlich wieder vor einem Problem und der Supporter bekam mächtig Mecker.

Microsoft hat Images nie unterstützt, nicht im Bereich DC und Active Directory, den Grund hat manch einer leidvoll erfahren müssen, trotz Image das anschließend  enorm Verdruss bereitete.
Die Newsgroups sind voller Klagen, MVP's im Bereich Server und AD raten davon ab Images zu benutzen, auch mit eigenen (Nils Kaczenski) folgerichtigen Beiträgen, sogar einem Webcast - dass auch eigentlich völlig zurecht wie die Praxis zeigt.

Einem USN-Rollback folgen wenige Fehlermeldungen im AD Eventlog Directory Services, wenig Aufschlussreich 
für den Supporter der einfach oft den "Riecher" dafür haben muss, was wohl passiert sein mag.
W2K3 mit dem passenden Hotfix beglückt benennt das Übel im Klartext, ebenso für W2K.

Was anschließend nicht mehr geht ist völlig klar, der aus dem Image geborene DC macht "Unsinn", ist wertlos
geworden und stellt die Replikation in Frage; bzw. der oder die Partner im Netz reagieren ob der 
Alzheimer mal mit NACK.

Leider ist es auch so, dass sich Microsoft in manchen Beschreibungen in der Technischen Datenbank
zwar mit umständlichen Erklärungen  äußert, aber den Kern der Sache wegen Proprietarität oder mutwilliger
Vergesslichkeit unter den Tisch fallen lässt. Lediglich ein lapidarer Hinweis: AD-Aware  in Verbindung
mit InvocationID lässt manches Ohr aufhorchen; und die Suche geht los nach dem Mechanismus der 
dem AD den Hinweis gibt - es fand eine Rücksicherung statt.

Wird es mit der von Microsoft propagierten Rücksicherung des Systemstates erledigt die eben kein 
Authoratives Restore ist, klappt die Verständigung der beteiligten DC's auch wieder. Die zwischenzeitlich
verpassten USN's des aus der Sicherung restortem DC's werden vom Partner akzeptiert und "zurückrepliziert".
Im Technet steht dafür der Begriff "High Watermark" auf, der das Verhalten mitsteuert.

Dem wiederspricht aber die prickelnde Idee, die virtuelle Umgebung - gerade auf konsolidierten Umgebungen 
die virtuelle Festplatte zu clonen und bei Bedarf wieder zu aktivieren. Mit dem veraltetem Stand eines DC's natürlich.
Ein Image oder die virtuelle Festplatte entspricht ebenfalls einer Sicherung, nur weiß das AD des DC's nichts von der
Rücksicherung und fühlt sich völlig im Recht, zu Recht.

Das AD anschubsen, manuell

Manipuliert man die Registry des auf diese Weise hergestellten DC's vor dem normalen Start mit voller 
AD-Funktionalität wie es der Systemstate auch erledigt, ergibt sich der erhoffte Effekt:

Ereignistyp: Informationen
Ereignisquelle: NTDS Replication
Ereigniskategorie: (5)
Ereigniskennung: 1109
Datum: 07.09.2006
Zeit: 21:11:33
Benutzer: Nicht zutreffend
Computer: DC1
Beschreibung:
Dieses Verzeichnis wurde durch eine Sicherung wiederhergestellt. Die DSA-Signatur für die Replikation (Invokationskennung) wurde von 1fdfdbad-45d4-477d-876e-955a936fccf9 auf 2dc63287-8782-4560-b1dc-dc54db8ae6ad geändert. Die höchste USN zur Zeit der Sicherung war 2223. 
-------------
Ereignistyp: Informationen
Ereignisquelle: NTDS Replication
Ereigniskategorie: (5)
Ereigniskennung: 1587
Datum: 07.09.2006
Zeit: 21:14:46
Benutzer: TESTDOM\DC2$
Computer: DC1
Beschreibung:
Der DSA (Directory Service Agent), der mit dem objectGuid 85302bd3-6ff8-485d-87e3-10e63b73dcfd übereinstimmt, hat Änderungen angefordert, die bei einer Textmarke vor der letzten Wiederherstellung des lokalen DSA von der Sicherungskopie beim USN 2223 beginnen sollen. Die Textmarke wurde folgendermaßen angepasst: 

Vorheirge Invokationskennung: 1fdfdbad-45d4-477d-876e-955a936fccf9 
Vorheriges Objektaktualisierungs-USN: 3220 
Vorheriges Eigenschaftenaktualisierungs-USN: 3220 

Neue Invokationskennung: 2dc63287-8782-4560-b1dc-dc54db8ae6ad 
Neues Objektaktualisierungs-USN: 2223 
Neues Eigenschaftenaktualisierungs-USN: 2223
-----------------------

Schön zu sehen, der originale DC wurde deletet, aber erfreut sich dennoch bester Replikation.

Aus alt macht neu, der PDC-Emulator aus dem Image erweckt verhält sich wohlwollend. Die InvocationID die vorher
noch mit der ObjectGuid übereinstimmte, hat sich geändert. Dabei gilt es zu beachten, diese beiden ID's
müssen nicht übereinstimmen, auch nicht bei einem neu aufgesetztem DC, hier können diese schon unterschiedlich sein.

Das war es dann auch, die beteiligten Maschinen verstehen sich wieder und die Lücke der USN wird vom DC2
an DC1 zurückgegeben, ein Briefing in die andere Richtung ist erfolgt und beide haben wieder den aktuellen Stand.
In diesem Zusammenhang fällt auch die neue InvocationsID auf, mit der der neue aber alte DC bestückt wird, wobei
die originäre GUID beibehalten wird. Man darf spekulieren, ob das der Grund ist warum ein entfernter DC wegen 
Crashs neu aufgebaut nicht unter dem gleichen Namen in das AD gehoben werden soll und kann. Inwieweit hier 
auch Eingriffe  möglich sind, ist noch nicht erforscht.

Überredungskunst ist alles?

Irgendwo muss es vermerkt werden, dass etwas mit dem AD geschehen soll. Der dafür geeignete Ort kann
nur die Registry sein, so die Spekulation. Damit war etwas Arbeit nötig die Aktionen im Hintergrund zu verfolgen,
aber mit Erfolg.

Der gefundene Wert in der Registry der dieses Verhalten bewirkt und die beteiligten Maschinen trotz ImageRestore
die Replikation ordnungsgemäß aufnehmen lässt, lautet wie folgt: { hat Microsoft wohl einfach vergessen zu erwähnen}

HKLM\System\CCS\Services\NTDS\Parameters

"Database restored from backup"

Reg_DWord=1

 

Wann ist der Wert zu setzen?

Das Image ist direkt per F8 in den Modus Verzeichnisdienstwiederherstellung Domänencontroller zu starten
den Wert in der Registry setzen und normal starten. Jeder andere Weg führt in die Replikationsverweigerung.

Übrigens kann man auch in der Reg an genannter Stelle ablesen, wie oft schon ein Restore des ADS erfolgt ist,
DSA Previous Restore Count - DWord zählt diese Ereignisse mit und der Wert sollte nach dieser Aktion
vorhanden sein und der Counter sich um den Wert 1 erhöht haben. Ist nie ein Restore erfolgt, fehlt der Eintrag.
Auch der per Hand gesetzte Wert Database restored... wird nach erfolgreicher Aktion vom System entfernt,
also nicht wundern. Andere Werte werden ebenfalls modifiziert, man schaue sich danach mal die RID Values an.

Das gleiche Verfahren funktioniert auch unter W2K3 mit SP1.

Verantwortungsvolle Administratoren?

Genau diese gehen mit der hier angebotenen Information sensibel um, nicht blindlings nutzen.
Es spricht aber nichts dagegen, dieses Verfahren in einer Testumgebung zu nutzen und auch mit der
nötigen Achtsamkeit in der Live-Umgebung des zu betreuenden Kunden.
Tatsache aber ist, dieser Weg richtig durchgeführt mündet im Erfolg.

Manchmal steckt in den Artikeln des Technet eben doch mehr drin, was nur umständlich herauszufischen ist.

[Update 23 November 2006]

Die Entgegnungen von Nils Kaczenski zu diesem Artikel gehen meiner Meinung etwas am Thema vorbei.

  1. Ich behaupte nicht, sondern im Titel steht es zuerst mal als Frage.
  2. Die Methode stellt keinen Angriff auf Nils Artikel oder Webcast dar, diesem ist auch im Text uneingeschränkt zugestimmt worden. Auch sind dadurch nicht die Argumentationen und das ordentliche Verfahren ad absurdum geführt worden.
  3. Es wurde lediglich aufgezeigt, was ein non authorativer Restore ordentlich durchgeführt, im Hintergrund erledigt.
  4. Auch bei einem Restore des Systemstates muss der DC gestartet werden, das Argument der nicht erfolgten Zeitersparnis zieht also eher nicht, ist auch nicht Gegenstand dieser Erforschung gewesen.
  5. Der DC ist online per Image gesichert, warum auch nicht? Ob es sich nun um einen Clone (VMware etc) handelt, ist ebenfalls unerheblich, das Gegenargument ist also ebenfalls fehl am Platz
  6. Die Entgegnung  "Problem Computerkennwörter lassen sich so nicht lösen" habe ich auch nie behauptet, steht nirgends. Aber das Argument ist sowieso an den Haaren herbeigezogen: auch nach einem Systemstate kann das Kennwort geändert worden sein und die gleiche Situation entstünde hier. Es sei denn per GPO wurde das vorher eingestellt (Ändern Computerkennworter nicht erlauben) und die Replikation abgewartet, aber wer macht denn so was?
  7. Schadensfälle sind ebenfalls nirgends angesprochen worden, noch ist das der Zweck gewesen. Dennoch kann ein Plattenausfall ebenfalls die Ursache sein und es ist somit ein Weg aufgezeigt worden, wie ein Image zur Mitarbeit bewegt werden kann, wenn keine ordentliche Sicherung vorhanden ist.
  8. Welches Verfahren schneller ist, unter welchen Bedingungen ist nicht die Frage gewesen. Nicht jede Umgebung ist derart gut gepflegt und Dokumentiert. Gegen Fehlkonfigurationen oder gelöschte Objekte im AD hilft das natürlich nicht, das sollte jeder der sich mit dem AD beschäftigt schnell aus der Beschreibung herausgelesen haben.

Damit keine weiteren Ungereimtheiten bestehen bleiben:
Exchange oder SQL in dem Image, darüber sollte sich jeder selbst Gedanken machen denn dafür ist das Verfahren nicht gedacht noch geeignet oder Ziel der Untersuchung gewesen. 

Es gilt also wie schon gesagt, der verantwortungsvolle Administrator ist gefragt. Bei der Beschreibung dessen was dabei passiert  handelt es sich um den erforschten Mechanismus "non authorativen Restore", einzelne Objekte des AD lassen sich so natürlich nicht wiederherstellen, aber das hat jeder Leser hoffentlich sogleich erfasst unabhängig davon dass es im Text nicht explizit steht.

Michael Bormann

Top