AD SPNs komplett verwirrt / GPO Sync defekt

[FT-Felix 0]

Hallo,

 

nachdem ein Domain Controller kaputt gegangen ist übernam der zweite Domain Controller mit extremen Problemen.

GPOs werden von den Clients scheinbar ohne Fehler geladen, aber keiner der Clients hat irgendwelche GPOs angewendet.

Sämtliche Maßnahmen des DSRM haben nur angezeigt es sei alles in Ordnung.

Daraufhin habe ich einen neuen DC hinzugefügt und den alten zweiten entfernt. Keine Besserung.

Nach jedem Reboot eines DC wird im Ereignislog die Meldung 10154 (The WinRM service failed to create the following SPNs: WSMAN/dc3.domain.tld; WSMAN/dc3.) gezeigt. Diese Meldung ist jedoch eine komplette Lüge, da "setspn -l dc3" beide SPNs als vorhanden anzeigt.

Zusätzlich werden auch die Events 304, 307, 359, 1202, 1, 4, 12, 4013, 10149 angezeigt.

Sämtliche andere AD Dinge (DNS, Benuterverwaltung, Gruppen, ...) funktionieren einwandfrei. Die SYSVOL Freigabe ist vorhanden, zugreifbar und sämtliche Dateien sind vorhanden.

Der DC weigert sich lediglich GPOs auszuliefern.

 

Ich habe diverse Lösungsvorschläge wie diesen gefunden: https://igorpuhalo.wordpress.com/2019/02/14/event-10154-the-winrm-service-failed-to-create-the-following-spns-wsman-dcname-domain-tld-wsman-dcname/

Das scheint jedoch veraltet oder unsinnig zu sein, denn der Netzwerkdienst scheint dort garnicht auf und wenn ich ihn manuell hinzufüge hat es keinerlei Auswirkungen.

Ich verwende nur Windows Server 2019 und nur Windows 10 Clients.

 

LG Felix

[NilsK 2.918]

Moin,

 

willkommen an Board!

 

Auch wenn dein Problem dich stresst (was ich verstehe), solltest du dich um genaue Beschreibungen bemühen. Es wird sonst unnötig umständlich.

 

vor einer Stunde schrieb FT-Felix:

mit extremen Problemen.

Welches sind diese "extremen Probleme"? Weiter unten gibst du an, dass eigentlich alles geht, bis auf die GPOs. Ist da nun noch mehr im Busch oder nicht?

 

vor einer Stunde schrieb FT-Felix:

Sämtliche Maßnahmen des DSRM

Der DSRM ist im Wesentlichen dafür da, das AD aus einem Backup wiederherzustellen. Da du das offenbar nicht getan hast, was hast du denn dort genau gemacht?

 

vor einer Stunde schrieb FT-Felix:

Daraufhin habe ich einen neuen DC hinzugefügt und den alten zweiten entfernt. Keine Besserung.

Von solchen Schnellschüssen solltest du künftig Abstand nehmen. Einen neuen DC hinzuzufügen, ist erst mal OK, aber den alten zu entfernen, solange noch Probleme bestehen, war u.U. voreilig.

 

vor einer Stunde schrieb FT-Felix:

Diese Meldung ist jedoch eine komplette Lüge

Eine Lüge wäre ja eine absichtliche Fehlinformation. Ich glaube nicht, dass Windows dich anlügen will, sondern denke eher, dass es aus seiner Sicht Recht hat. Die Frage wäre also eher, warum Windows versucht, den SPN zu registrieren, wenn er doch anscheinend da ist - und warum das fehlschlägt. Da der SPN ja aber anscheinend da ist, kann man dieses Problem vermutlich zunächst ignorieren.

 

Zu den anderen Events müsstest du bitte mal angeben, was dort steht. Hier wird niemand die IDs im Kopf haben.

 

vor einer Stunde schrieb FT-Felix:

Der DC weigert sich lediglich GPOs auszuliefern.

Was führt dich zu dieser Aussage? Was versuchst du genau, und was passiert dann? Weiter oben schreibst du, dass die Clients die GPOs sehr wohl erhalten, aber nicht anwenden. Hier müssten wir jetzt also erst mal klären, was denn genau das Problem ist.

 

vor einer Stunde schrieb FT-Felix:

Das scheint jedoch veraltet oder unsinnig zu sein, denn der Netzwerkdienst scheint dort gar nicht auf

Auch diese Schlussfolgerung scheint mir etwas voreilig zu sein. Wenn der Dienst dort nicht auftaucht, dann hat er keine Berechtigungen. Und damit könnte das Problem durchaus das sein, das in dem Artikel beschrieben wird. Wenn es auch weiterhin nicht geht, müsste man noch mal prüfen, was du dort denn genau gemacht hast; an der Stelle kann man durchaus auch unabsichtlich falsch vorgehen.

 

Also schau doch mal, ob du die fehlenden Informationen nachliefern kannst.

 

Gruß, Nils

 

bearbeitet 22. November 2021 von NilsK

[FT-Felix 0]

Hallo Nils,

 

danke für die Auflistung der weiterene benötigten Infos.

 

Das GPOs nicht funktionieren zieht eine ganze Menge an Problemen mit sich, da Einstellungen auf die Clients ausgespielt werden die für den Betrieb dieser unerlässlich sind. Die Quelle allen Übels ist jedoch das GPOs nicht mehr funktionieren. Alles hat vor dem Defekt des ersten DC funktioniert, aber mit dessen Defekt wurden dann auch alle bereits angewendeten GPOs von den Clients gelöscht. Ein Backup davon gibt es nicht und der zweite DC scheint nie ganz korrekt funktioniert zu haben, denn sonst wäre das ganze Problem ja wohl garnicht erst entstanden.

 

Im DSRM habe ich den Versuch einer DB-Reparatur unternommen wie in dieser Anleitung gezeigt: https://www.dell.com/support/kbdoc/de-ch/000138794/windows-server-active-directory-datenbankreparatur-nach-domain-controller-fehler

 

Der Gedankengang hinter dem DC-Tausch war grundsätzlich der, dass ich einen Schaden im DC vermutet habe der sich nicht auf einen neuen DC weiter replizieren würde (User, Gruppen, GPOs, DNS, ... hat sich alles fehlerfrei auf den neuen DC repliziert). Vom alten (entfernten) DC gibt es ein Backup das den Stand sichert bevor ich mit irgendwelchen Reparaturversuchen begonnen habe. Dieses kann bei Bedarf schnell wiederhergestellt werden.

 

Wenn ich an einem Client gpupdate ausführe, dann sieht es so aus als würde es funktionieren. Es gibt keine Fehlermeldung das ein DC nicht erreichbar wäre oder dergleichen. Weiters zeigt gpresult dann den korrekten DC unter "Gruppenrichtlinieanwendung von" an. Unter "Der Benutzer ist Mitglied der folgenden Sicherheitsgruppen" werden auch alle Gruppen korrekt gezeigt. Der Punkt "Angewendete Gruppenrichtlinienobjekte" ist leer und zeigt nur "Nicht zutreffend" an. Ob während gpupdate tatsächlich irgendetwas übertragen wird kann ich nicht feststellen. Ich sehe nur das Resultat und das ist, dass nichts angewendet wurde.

 

Die zusätzlichen Events sind:

 

304, 307, 359 - User Device Registration - "Automatic registration failed (at join phase)"

1, 4, 12 - Time Service - vmwTimeProvider Gerät wird nicht gefunden und NtpClient funktioniert nicht (Zeit auf dem DC ist jedoch korrekt)

1202 - DFS Replikation kann sich nicht mit dem DC "" (leere Anführungszeichen) verbinden (Replikation ist nicht konfiguriert, da nur 1 DC vorhanden)

1202 - ActiveDirectory-Webdienste kann nicht bedient werden (ADFS oder ähnliches ist nicht einmal installiert)

4013 - DNS-Server startet erst nach Replikation (die aber garnicht existiert und daher startet der DC ohne DNS und kann diesen auch in den ersten Minuten nicht erreichen, was zu mehreren Warnungen führt)

10149 - "Der WinRM-Dienst hört keine WS-Verwaltungsanforderungen ab" (stimmt auch nicht, Listener ist vorhanden und läuft auch und funktioniert auch)

 

LG Felix

[NilsK 2.918]

Moin,

 

vor einer Stunde schrieb FT-Felix:

Das GPOs nicht funktionieren zieht eine ganze Menge an Problemen mit sich

das ist mir schon klar. Die Frage ist aber: gibt es außer den GPO-Sachen noch weitere Fehler oder Probleme auf dem DC? Wenn ja, welche genau?

 

vor einer Stunde schrieb FT-Felix:

vor dem Defekt des ersten DC

Was ist denn mit dem DC passiert?

 

vor einer Stunde schrieb FT-Felix:

mit dessen Defekt wurden dann auch alle bereits angewendeten GPOs von den Clients gelöscht

Ist das so? Wäre eher untypisch.

 

vor einer Stunde schrieb FT-Felix:

wie in dieser Anleitung gezeigt

Hattest du denn auch die Fehlermeldung, die in dem Artikel genannt wird?

 

vor einer Stunde schrieb FT-Felix:

dass ich einen Schaden im DC vermutet habe der sich nicht auf einen neuen DC weiter replizieren würde

Dahinter liegt eine eher mystische Vorstellung von der Replikation, die oft anzutreffen ist. "Schäden auf einem DC" replizieren sich aber nicht. Das AD repliziert Daten, sehr vorhersagbar. Künftig sei also empfohlen, dass du dir früher Unterstützung suchst, statt einfach was auszuprobieren.

 

vor einer Stunde schrieb FT-Felix:

Der Punkt "Angewendete Gruppenrichtlinienobjekte" ist leer und zeigt nur "Nicht zutreffend" an.

So, jetzt nähern wir uns mal dem Problem. Sind denn die Gruppenrichtlinienobjekte im AD und auf dem DC vorhanden? Das prüfst du einerseits in der GPMC (gpmc.msc aufrufen) und zum anderen im Dateisystem im SYSVOL (%logonserver%\sysvol\%userdnsdomain%\Policies aufrufen). Sind die erwarteten Objekte da?

 

Die weiteren Eventlog-Meldungen kannst du erst mal ignorieren. An den Time Service und die DFS-Replikation solltest du später mal ran, aber erst mal schauen wir, was mit den GPOs los ist.

 

Gruß, Nils

 

[FT-Felix 0]

Hallo,

 

auf dem DC selbst sind die GPOs das einzige Problem (das mir bisher aufgefallen ist).

Der erste DC hatte einen Festplattenschaden. Das AD hat bis zuletzt sauber funktioniert.

Ich habe auf allen Clients nachgesehen und alle GPOs sind ausnahmelos verschwunden.

Im DSRM habe ich keine Fehlermeldungen gesehen. Überall wurde angezeigt, dass alles in Ordnung ist bzw. die DB konsistent ist.

 

In der Gruppenrichtlinienverwaltung sind alle GPOs da und auch den entsprechenden OUs zugewiesen. Im SYSVOL sind die entsprechenden Objekt-Dateien vollständig vorhanden. Der Zugriff von den Clients aus ist auch vorhanden (mittels Explorer auf die Freigabe gehen).

 

LG Felix

[NilsK 2.918]

Moin,

 

vor 5 Minuten schrieb FT-Felix:

Ich habe auf allen Clients nachgesehen und alle GPOs sind ausnahmelos verschwunden.

nur damit wir uns richtig verstehen: Was genau hast du da nachgesehen?

 

Um wie viele Clients handelt es sich denn? Und um wie viele GPOs?

 

Für weitergehenden Support fehlt mir im Moment die Zeit. Meine Einschätzung ist aber: Du hast gar kein großes Problem, nur ein lästiges.

Ein Backup deines AD hast du jetzt doch hoffentlich eingerichtet, oder?

 

Gruß, Nils

 

[FT-Felix 0]

Hallo,

 

ich habe auf allen Clients gpresult ausgeführt und überall ist identisch nichts mehr da (= "Nicht zutreffend").

Es handelt sich um 9 Clients und 2 Server (ohne DC) die dran hängen. Es gibt ca. 6 GPO-Objekte.

Der DC läuft jetzt als VM und wird täglich gesichert.

 

LG Felix

[NilsK 2.918]

Moin,

 

Bitte gewöhne dir an, mit Schlussfolgerungen zurückhaltender zu sein. 

 

Wie sicherst du deine DC-VM? Sinnvoller wäre, du würdest das AD per System State sichern, das hilft dir dann auch, wenn es gar nicht darum geht, den DC wiederherzustellen. In diesem Moment etwa würde dir eine separate AD-Sicherung wahrscheinlich mehr helfen als ein ganzer DC. Ist momentan aber Essig, es gibt ja kein Backup.

 

Wir gesagt, ich kann das jetzt nicht mehr in der Tiefe supporten. Was ich jetzt prüfen würde:

- sind wirklich die GPO-Dateien noch da oder nur die Ordner?

-kannst du die GPOs zum Bearbeiten öffnen?

- wenn du ein neues GPO anlegst, funktioniert dies dann auf dem Client?

- wenn du von einem bestehenden GPO den Link entfernst und es dann neu verknüpfst, geht es dann?

- wenn du einen Client aus der Domäne nimmst und neu hinzufügst, geht es dann? (Alternativ einen ganz neuen Client, etwa eine neue VM.)

 

Gruß, Nils

 

[NorbertFe 2.013]

vor 4 Minuten schrieb NilsK:

-kannst du die GPOs zum Bearbeiten öffnen?

 

Das wäre wirklich hilfreich zu wissen, genau wie der nächste Punkt, ein neues GPO anzulegen.

 

Bye

Norbert

[FT-Felix 0]

Hallo,

 

die Sicherung der VM wird mit Veeam gemacht.

Ich wüsste nicht was an der Ausgabe von gpresult eine Schlussfolgerung sein soll. Es wird schließlich ausgegeben, dass die bestehenden GPOs nicht auf dem Client vorhanden sind.

 

Im SYSVOL sind alle Ordner und INI, XML, ... Dateien vorhanden und haben auch den erwarteten Inhalt. Sämtliche GPT.INI Dateien sind ebenfalls da.

Öffnen der Dateien direkt und in der Gruppenrichtlinienverwaltung funktioniert. Auch Änderungen daran durchführen funktioniert und findet sich in der entsprechenden Datei wieder.

Anlegen eines neuen GPO und darauf folgendes gpupdate wendet das neue GPO auch tatsächlich auf den jeweiligen Client an.

In der Gruppenrichtlinienverwaltung sämtliche Links in den OUs neu machen hatte keine Wirkung.

Hinzufügen eines neuen Clients zum AD holt die bestehenden GPOs nicht. Das neu angelegte Test-Objekt jedoch schon.

 

LG Felix

[daabm 1.334]

GPOs haben ein eigenes Eventlog, da steht ziemlich viel drin. Und dann gibt's noch das gpsvc debug logging. Beides könnte hilfreich sein. Und eine Analyse von AD- und Sysvolreplikation auch. Ich glaube nicht, daß DU ein "Riesen Problem" hast, ich glaube Du gehst momentan zu unstrukturiert an die Diagnose.

[NorbertFe 2.013]

vor 11 Minuten schrieb FT-Felix:

Hinzufügen eines neuen Clients zum AD holt die bestehenden GPOs nicht. Das neu angelegte Test-Objekt jedoch schon.

 

Na dann siehst du ja schonmal, dass du kein grundsätzliches Problem hast, sondern vermutlich wird irgendwo in den alten GPOs noch der "Wurm" stecken. WEnn du qick and dirty willst, dann kopier mal eine mittels GPMC und übernimm die Standardberechtigungen. WEnns dann geht, kannst du überlegen, was du machst.

[NilsK 2.918]

Moin,

 

Wenn neue GPOs funktionieren, würde ich bei nur sechs Objekten insgesamt nicht mehr lange fackeln ...

 

Gruß, Nils

[FT-Felix 0]

Das Eventlog der GPOs auf dem DC und den Clients enthält keine Warnungen oder Fehler. Nur Meldungen, dass das Abrufen der GPOs erfolgreich war.

Kopieren und mit Standardberechtigungen einfügen und neu verlinken war erfolglos. Auch sichern, GPO löschen und wiederherstellen hat nichts gebracht.

Die 3 kleineren GPOs habe ich mittlerweile gelöscht und neu erstellt. Diese werden jetzt korrekt angewendet. Das große GPO und vor allem die Default Domain Policy und Default Domain Controller Policy würde ich aber ungerne per Hand neu erstellen.

bearbeitet 22. November 2021 von FT-Felix

[tesso 373]

Für sftp und davon gibt es dcgpofix. Das stellt die Standard GPO wieder her. 
 

Mistiges T9. Das sollte DDP und DDCP heißen.