USN-Rollback 2 DCs, beide laufen, einer wurde (leider & unnötig) restored, wie vorgehen

[cartman14 1]

Hallo zusammen,

 

ich hoffe hier noch etwas Erfahrungen zu bekommen. Ich schildere mal mein Problem:

1. DC 2019 virtuell auf Hyper-V Host inkl. FSMO-Rollen und DHCP

2. DC 2019 physikalisch

 

Vor ca. einem Monat bootete der Hyper-V Host nach der Installation der MS-Patches nicht mehr. Ich konnte machen, was ich wollte, auch rückgängig machen konnte ich nicht, hat nicht geklappt. Da es an einem Sonntagabend war habe ich nach ein paar Stunden probieren, die Windows-Server-Sicherung bemüht und die C:\ Partition des Hyper-V Host zurückgesichert. Dann lief er wieder und ich habe die Patches auf ihm erst mal weggelassen. Obwohl ich die D:\ Partition extra ausgeschlossen hatte, fing er an diese auch zurück zu sichern. Dort hatte ich mir nämlich extra die VHD des 1. DC noch hin kopiert bevor ich den Restor startete. Ergebnis: D: Partition mit meinem manuell VHD Backup wurde überschrieben. Ich habe also die C:\ des Hyper-V Host inkl. des virtuellen DC. (dieser liegt leider auch auf D:\) vom Vortag zurückgespielt. Das also die Ursache des aktuellen Problems.

 

Ich wusste dass USN ein Thema bei solchen Aktionen ist. Daher testete ich nach dem Restore die Anlage von Benutzern und Coputern im AD. Hat sich sofort gesynct. Da dachte ich: Glück gehabt, funktioniert ja... Seitdem auch keine Probleme. Die fingen jetzt vor ein paar Tage an und werden mehr.

 

Die GPOs werden nicht mehr angewendet, die Netzlaufwerke sind unvollständig. Es scheint jetzt (nach ca. einem Monat) Kerberos Probleme zu geben. Die Netzwerkerkennung auf dem 2. DC zeigt nur noch ein öffentlichens Netz an. (auch nach Neustart vom NLA-Dienst.) Die Replizierung läuft nicht. (Trotzem werden die User & Computer Objekte gesynct?!) Die SYSVOL Replizierung läuft aber nicht. Ich habe auch den "Dsa Not Writable" 0x4 Eintrag auf dem virtuellen DC. Clients zeigen teilweise schon im Netzwerkstatus (Nicht authentifiziert hinter dem Netzwerknamen an.)

 

Änderungen gibt es bei dem Kunden nicht viel im AD. Es wäre mir völlig egal welcher Stand bleibt. Aber wie gehe ich jetzt am besten vor? Ich habe extra noch nichts weiter gemacht. Den MS-Support habe ich aktiviert, bisher aber noch keine Rückmeldung. Daher Frage ich hier parallel noch mal in die Runde: Hatte jemand eine ähnliche Situation und wie seid ihr vorgegangen bzw. was für ein Ergebnis kam dabei raus?

 

Es handelt sich um eine - für mich - relativ große Umgebung mit ca. 80 Usern. Wie halte ich die Auswirkungen auf die User möglichst klein? Natürlich habe ich schon viel gelesen, den DC aus der Domänen nehmen und nach bereinigung wieder Aufzunehmen scheint der Weg?! Aber ich bin gerade einfach unsicher ob ich das Versuchen soll. Ich möchte keine Weitere negativen Folgen produzieren.

 

Sorry für die Form, ich habe das jetz etwas im Stress runtergeschrieben.

 

Ach so, ein Zeitproblem gibt es nicht, die Uhrzeit ist auf allen - auch auf der VM - korrekt.

 

 

[NorbertFe 2.045]

vor 15 Minuten schrieb cartman14:

Ich wusste dass USN ein Thema bei solchen Aktionen ist. Daher testete ich nach dem Restore die Anlage von Benutzern und Coputern im AD. Hat sich sofort gesynct. Da dachte ich: Glück gehabt, funktioniert ja... Seitdem auch keine Probleme. Die fingen jetzt vor ein paar Tage an und werden mehr.

Und wieso schmeißt du das Restore so eines Prozesses dann nicht einfach weg und richtest einen neuen DC ein? Am Sonntag ist sowas ja dann doch schnell erledigt. ;)

 

Sicher, dass das nicht Probleme des Patches sind? bei einem USN Rollback findet man üblicherweise auch Hinweise im Eventlog. Davon lese ich aber irgendwie sehr wenig bei dir.

 

[NilsK 2.939]

Moin,

 

was du da beschreibst, ist längst nicht alles auf ein USN Rollback zurückzuführen. Da funktioniert offenbar noch mehr nicht.

 

vor 10 Minuten schrieb cartman14:

Änderungen gibt es bei dem Kunden nicht viel im AD.

Dann brauchst du dir um USN Rollback auch nicht ganz so viele Sorgen zu machen.

 

Ich würde jetzt zunächst koordiniert versuchen, die vorhandenen Probleme und Fehler einzuordnen und schauen, ob sich die jeweils lösen lassen. Vermutlich sind das zusätzliche Folgen des Ausfalls.

 

Nur wenn das nicht weiterhilft, würde ich prüfen, ob einer der DCs weg muss. Falls ja, einen neuen in die Domäne installieren. Wenn der sich ordentlich repliziert und dann funktioniert, den zu entfernenden DC entfernen.

 

Viel näher kann man das jetzt nicht beschreiben, dazu müsste man es sich vor Ort ansehen, das ist dann nichts für ein Forum.

 

Was das mögliche USN Rollback angeht: Wie gesagt, unwahrscheinlich bei dir. Ob es überhaupt aufgetreten ist, kannst du im Eventlog prüfen: Event-ID 2103 zeigt an, wenn das AD einen USN Rollback erkannt hat. Falls ja, muss das auch erst mal kein Problem sein, das ist es nur, wenn tatsächlich auf beiden DCs Änderungen am selben Objekt erfolgt sind. In dem Fall sollte aber der DC, der in der Meldung als Problem genannt wird, herabgestuft werden. Nicht einfach versuchen, die Replikation wieder einzuschalten.

 

Gruß, Nils

 

[cartman14 1]

vor 13 Minuten schrieb NorbertFe:

Und wieso schmeißt du das Restore so eines Prozesses dann nicht einfach weg und richtest einen neuen DC ein? Am Sonntag ist sowas ja dann doch schnell erledigt. ;)

 

Sicher, dass das nicht Probleme des Patches sind? bei einem USN Rollback findet man üblicherweise auch Hinweise im Eventlog. Davon lese ich aber irgendwie sehr wenig bei dir.

 

 

Auf dem DC gab es keine Probleme mit den Patches, die Probleme hatt der Hyper-V Host. Nur der sollte restored werden. Das die VM DC1 mit restored wurde, war nicht vorgesehen.

 

Ich dachte der Registry Eintrag "Dsa Not Writable" 0x4 sei ein eindeutiges Zeichen für den USN-Rollback. Die Ereignis-Protokolle sind voll von Fehlern. Auf DC2 habe ich ganz viele Security-Kerberos ID 4  KRB_AP_ERR_MODIFIED-Fehler von Server DC2....

 

Auf DC1 habe ich diese nicht.

DC2 hat auch DFRS ID 1202 Fehler während DC1 DFRS ID 5002

 

Auf DC2 habe ich DNS-Server-Service ID 4000 "Der DNS-Server konnte Active Directory nicht öffnen. Das finde ich sehr seltsam. Hier könnte auch ein größeres Problem liegen??

 

Mir selbst ist das Problme übrigens am Mittwoch aufgefallen nach dem ich auf DC2 die Dezember Updates installiert hatte. Darauf habe ich diese wieder deinstalliert.

[cartman14 1]

Was der 2. DC, der phisische, welcher nicht restored wurde im Log zeigt ist Event ID 4, die gleiche Meldung bekomme ich auch an einem Test-Client. Dort wo mir das netzwerk als "Nicht authentifiziert angezeigt wird.)

 

Protokollname: System
Quelle:        Microsoft-Windows-Security-Kerberos
Datum:         16.12.2022 16:04:16
Ereignis-ID:   4
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      client.subdoman.domain.de
Beschreibung:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "dc2$" empfangen. Der verwendete Zielname war LDAP/DC2.subdoman.domain.de/subdoman.domain.de@SUBDOMAIN.DOMAIN.DE. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (SUBDOMAIN.DOMAIN.DE) von der Clientdomäne (SUBDOMAIN.DOMAIN.DE) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Kerberos" Guid="{98E6CFCB-EE0A-41E0-A57B-622D4E1B30B1}" EventSourceName="Kerberos" />
    <EventID Qualifiers="16384">4</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2022-12-16T15:04:16.9950565Z" />
    <EventRecordID>57370</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>System</Channel>
    <Computer>client.subdomain.domain.de</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="Server">DC2$</Data>
    <Data Name="TargetRealm">SUBDOMAIN.DOMAIN.DE</Data>
    <Data Name="Targetname">LDAP/DC2.subdoman.domain.de/subdoman.domain.de@SUBDOMAINDOMAIN.DE</Data>
    <Data Name="ClientRealm">SUBDOMAIN.DOMAIN.DE</Data>
    <Binary>
    </Binary>
  </EventData>
</Event>

 

 

Es scheint also zumindest auch ein Kerberos Problem zu geben. Nur kann ich gerade nicht einschätzen ob das eher Ursache oder eher Folge ist.

 

Repadmin /replsummary auf dem 2. DC2 zeigt mir:

------------------------------------------------------------------------------------

C:\Users\administrator.DOMAIN>Repadmin /replsummary
Startzeit der Replikationszusammenfassung: 2022-12-16 16:21:00

Datensammlung für Replikationszusammenfassung wird gestartet.
Dieser Vorgang kann einige Zeit dauern.
  .....

Quell-DSA          Größtes Delta    Fehler/gesamt %%  Fehler
 DC1           33d.03h:33m:39s    5 /   5  100  (2148074274) Der Zielprinzipalname ist falsch.

Ziel-DSA           Größtes Delta    Fehler/gesamt %%  Fehler
 DC2          33d.03h:33m:39s    5 /   5  100  (2148074274) Der Zielprinzipalname ist falsch.

Bei dem Versuch Replikationsinformationen abzurufen, sind folgende
Ausführungsfehler aufgetreten:
        8341 - DC1.subdomain.domain.de

-----------------------------------------------------------------------------------------------

Repadmin /replsummary auf dem 1. DC1 zeigt mir: (VM mit FSMO-Rollen, hier wurde der Restor durchgeführt)

-----------------------------------------------------------------------------------------------

C:\Users\administrator.DOMAIN>Repadmin /replsummary
Startzeit der Replikationszusammenfassung: 2022-12-16 16:20:38

Datensammlung für Replikationszusammenfassung wird gestartet.
Dieser Vorgang kann einige Zeit dauern.
  .....

Quell-DSA          Größtes Delta    Fehler/gesamt %%  Fehler
 DC2                  26m:42s    0 /   5    0
 DC1          33d.03h:33m:17s    5 /   5  100  (2148074274) Der Zielprinzipalname ist falsch.

Ziel-DSA           Größtes Delta    Fehler/gesamt %%  Fehler
 DC2          33d.03h:33m:17s    5 /   5  100  (2148074274) Der Zielprinzipalname ist falsch.
 DC1                  26m:42s    0 /   5    0

--------------------------------------------------------------------------------------------------

 

Mich wundert es, dass die Ergebniss unterschiedlich ist.

 

Wenn noch jemand Vorschläge oder Ideen hat, gerne schreiben.

 

Vielen Dank

 

PS:

Alles Windows Server 2019 mit Patchstand November 2022. Auf DC2 hatte ich die Dezember Patches zwar installiert war dann aber unsicher ob die evtl. die Probleme ausgelöst haben. Daher habe ichsie dort auch wieder deinstalliert.

 

Noch eine weitere Info bzw Erkenntnis:

 

Versuche ich von einem Client aus via DNS (also \\DC1 oder \\DC2) auf einen der beiden DCs zuzugreifen, bekomme ich:  "Der Zielkontoname ist ungültig."

 

Wenn ich es per "\\IP-Adresse" verusche, klappt es. Bei beiden DCs.

Zumindest werden mir dann die Freigaben netlogon und sysvol angezeigt. Beim Zugriff darauf werde ich nach Netzwerkanmeldeinfos gefragt, die nimmt er dann allerdings nicht.

 

Zugriff auf den Fileserver funktioineren dagegen noch. Die Netzlaufwerke werden nur nicht automatisch verbunden da die GPOs nicht abgearbeitet werden. Manuell kann ich die Netzlaufwerke aber verbinden.

bearbeitet 16. Dezember 2022 von cartman14

[daabm 1.356]

Per IP geht, weil NTLM. Dein krbtgt-Kennwort ist "out of sync". Löst man normalerweise, indem man auf allen bis auf einem DC (meist PDC) den Dienst kdc deaktivert und stoppt, und danach alle diese DCs neu bootet. Wenn das nicht hilft, muß der Secure Channel zurückgesetzt werden (nltest /sc_reset).

 

Und bevor noch mehr kaputt geht: Hol jemand, der's kann Keine Kritik, nur ein wohlmeinender Hinweis.

 

PS: USN-Rollback findest Du prominent im Directory Service Eventlog - das solltest Du eh mal anschauen auf beiden. Und im Zweifel ist es am einfachsten, den (noch zu identifizierenden) aktuellen "Chef im Ring" (auch meist der PDC) zu behalten und den Rest platt und neu zu machen. Aber siehe oben - hol Dir jemand.

[cartman14 1]

Ich trage hier mal noch weitere Infos zusammen:

 

Event-ID 2095 auf dem 1.DC mit FSMO-Rollen am 13.11.2022 (Tag der Wiederherstellung)

 

Das die Probleme (keine GPOs mehr, Netzwerk "Nicht authentifiziert") jetzt erst aufgefallen sind, liegt doch vermutlich Kerberos-Problemen?! Würde kdc deaktivieren und ggf. nltest /sc_reset im aktuellen Zustand trotzdem funktionieren? Nicht als dauerhafte Lösung natürlich, aber um evtl. erst mal den Zustand vom Zeitraum nach dem 13.11. bis ca. 13.12. wieder zu bekommen. Dann das USN-Rollback Problem danach beheben.

 

Was mich wundert ist, dass der 2. DC scheinbar mehr Probleme hat als der erste mit Event-ID 2095, daher bin ich unsicher, ob ein depromoten des 1. DCs aktuell so eine gute Idee ist. Oder ist es aktuell "normal"?

 

PS:

Ich bemühe mich schon um Hilfe, hatte auch schon welche, vielen Dank dafür! Aber jemanden zu finden der sich mit dieser Problematik "gut" auskennt ist natürlich auch nicht gerade einfach.

[Nobbyaushb 1.472]

vor 10 Minuten schrieb cartman14:

Ich bemühe mich schon um Hilfe, hatte auch schon welche, vielen Dank dafür! Aber jemanden zu finden der sich mit dieser Problematik "gut" auskennt ist natürlich auch nicht gerade einfach.

Eiinfach hier fragen - viele sind auch Dienstleister und machen sowas gegen Einwurf kleiner Münzen also nach Aufwand

 

Um deine Frage zu beantworten:

Ich habe das so rausgelesen, das ein DC (VM) aus einem Backup wiederhergestellt wurde.

Den wirfst du raus, erstellst einen neuen DC als VM, promoten, fertig - so meine Erfahrung

[NorbertFe 2.045]

vor 13 Minuten schrieb cartman14:

ob ein depromoten des 1. DCs aktuell so eine gute Idee ist

Wer sprach vom demote des 1.DCs?

[cartman14 1]

vor 16 Minuten schrieb NorbertFe:

Wer sprach vom demote des 1.DCs?

Ich nenne ihn den ersten weil er zum einen länger in Betrieb ist, und zum anderen die FSMO-Rollen hat. Dieser wurde ja auch wiederhergestellt und zeigt Event ID 2095. Ich verstehe die MS Best Practise so, dass dieser dann depromotet werden sollte. Falsch verstanden?

 

Wohler wäre mir den 2. DC, welcher aktuell auch mehr Fehler z.B. DNS zeigt, zu depromoten. Aber: bekommt DC1 das dann noch mit und setzt das AD wieder in einen normalen Zustand?

 

Zum Verständnis wenn ich von 1. DC und 2. DC spreche:
1. DC = VM + FSMO wurde am 13.11.2022 wiederhergestellt
2. DC = physikalisch hier wurde nichts mit gemacht, zeigt aber aktuell mehr Fehler als 1.DC
 Der 1.DC ist auch DHCP und verteilt sich selbst als primären DNS, aktuell laufen die Clients also mit diesem DNS

 

bearbeitet 19. Dezember 2022 von cartman14

[Nobbyaushb 1.472]

Hole dir externe Hilfe, sonst besteht die Gefahr das dein AD im Eimer ist.

 

Ehrlich

[cartman14 1]

vor 4 Minuten schrieb Nobbyaushb:

Hole dir externe Hilfe, sonst besteht die Gefahr das dein AD im Eimer ist.

 

Ehrlich

Ich habe bereits am Donnerstag an verschiedenen Stellen angefragt und warte aktuell auf Rückmeldung. Also seit ich einen USN-Rollback erkannt habe. Mir ist klar, dass hier ein falsches Vorgehen das AD zerstören kann.

 

Solange das Ding aber nicht repariert ist, trage ich hier Infos zusammen und freue mich über Rückmeldungen / Meinungen / Erfahrungen.

[Nobbyaushb 1.472]

Alles klar soweit - nur nicht einfach was machen

 

Kannst gerne deine Kenntnisse weiter posten

 

[NilsK 2.939]

Moin,

 

was Norbert meint, ist vor allem: An dieser Stelle ist ein Forum nicht mehr der geeignete Ort. Das muss man sich in Ruhe und im Zusammenhang ansehen. Zum Beispiel kann es durchaus sein, dass DC2 mehr Fehler meldet, weil er nicht die erwarteten Reaktionen von DC1 bekommt. Um das zu identifizieren, braucht man aber Zeit. Die muss ein externer Dienstleister natürlich auch erst mal organisiert kriegen.

 

Gruß, Nils

 

[daabm 1.356]

Ich kann mich dem nur anschließen. Ein AD kaputt zu machen, ist ziemlich schwierig - aber möglich. USN-Rollback mit ungeeigneten Reparaturmaßnahmen ist eine der besten Möglichkeiten dafür.