cartman14

Hallo Hennig,

 

kannst du dich noch erinnern ob bzw. wie das Problem damals gelöscht wurde?

 

Ich habe das selbe Problem bei einem Windows Server 2019 Std. Und würde mich über einen Tipp sehr freuen.

 

Vielen Dank

Martin

 

 

Ja sorry, ganz vergessen hier zu berichten. Ich war bei der Aktion im Urlaub und ein Kollege hat das ganze begleitet.
Mit externer Hilfe wurde grob folgendes gemacht:
-    Der Versuch einen neuen DC in die Domäne aufzunehmen ist gescheitert, egal gegen welchen DC
-    Virtuellen DC inkl. FSMO-Rollen heruntergefahren und auf nicht starten gestellt (später gelöscht)
-    Übernahme (seize) der FSMO-Rollen auf verbliebenem Hardware DC
-    Reset des Computerpassworts – danach ließ sich DNS und AD-Verwaltung wieder starten (vorher war dies auf diesem DC nicht möglich)
-    Metadata-Cleanup von virtuellem DC, virtuellen DC aus AD-Standorte und DNS entfernt
-    Der VM aus dem ersten Punkt wurde der Name des alten virtuellen DCs gegeben und anschließend zum DC promotet mit alter IP um Probleme bei fest vergebenen DNS Namen / IPs zu vermeiden
-    DHCP und AAD-Connect (vorher gesichert) wurden wieder auf dem neuen virtuellen DC eingerichtet
Seit dieser Aktion Ende Dezember gab es keine Probleme oder Auffälligkeiten mehr.

Vielen Dank an alle Beteiligten!

 

Leider gestaltet sich die Suche nach externer Hilfe eher schlecht. Liest hier noch jemand mit der auch professionell und kurzfristig seine Dienste anbietet? Dann würde ich mich über eine Nachricht sehr freuen.

 

vielen Dank

 

 

 

Jetzt muss ich mal b***d Fragen:

 

MS schreibt ja hier von drei Ansätzen zum Wiederherstellen von einem USN-Rollback: https://learn.microsoft.com/de-de/troubleshoot/windows-server/identity/detect-and-recover-from-usn-rollback

 

1. Depromoten, FSMO ziehen, ggf. wieder promoten

2. Stellen Sie den Systemzustand einer guten Sicherung wieder her.

• Bewerten Sie, ob gültige Systemstatussicherungen für diesen Domänencontroller vorhanden sind. Wenn vor der fehlerhaften Wiederherstellung des zurückgesetzten Domänencontrollers eine gültige Systemstatussicherung vorgenommen wurde und die Sicherung zuletzt am Domänencontroller vorgenommene Änderungen enthält, stellen Sie den Systemstatus aus der letzten Sicherung wieder her.

Könnte also eine erneute Rücksicherung vor dem 13.11.2022 in meinem Fall auch das Problem lösen? Oder verstehe ich die 2. Option gerade falsch?

 

PS:

Ich weiss, ihr ratet mir - zu recht - zu externer Hilfe, die bekomme ich nur aktuell leider nicht. Daher muss ich zumindest gedanklich gerade alle Optionen durchgehen.

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.

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

 

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.

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.

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.

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.