FT-Felix

Hallo Nils, vielen Dank für Deine Hilfe. Dank auch an alle anderen an der Lösung beteiligten Leute. Liebe Grüße Felix

Hallo, alle DNS Anfragen aus dem gesamten Netzwerk, allen Servern und Clients landen bei diesem DC. Der DC hat sich selbst als DNS eingetragen. Der DNS Server hat als Upstream dann einen DNS außerhalb des eigenen Netzwerks. Die beiden DNS Fehler erscheinen nur beim Neustart des DC im Ereignislog. In DCDIAG sind diese Fehler mittlerweile verschwunden. Der DC wurde schon länger nicht neu gestartet. Die beiden "Automatic registration failed" Events erscheinen stündlich. Laut meiner Recherche sollen diese Meldungen aber normal sein, wenn keine Verbindung zu einem Azure-AD besteht. Scheint also als wären sämtliche relevanten Probleme behoben und es läuft wieder. Das eine BitLocker Problem würde ich einfach ignorieren. LG Felix

Ja, der AD integrierte DNS der auf dem DC läuft. Beide DNS-Einträge gibt es, sind SRV Einträge, Hostname und IP sind der DC. Beide Prio 0, Weight 100, LDAP Port 389 und Kerberos Port 88.

Irgendetwas hat diese GPO dazu gebracht wieder normal zu funktionieren. Ja, tut er. Und die Richtlinien funktionieren auch alle. BL-Backup auch. Es scheint als wäre es ein Problem bei diesem einen Client. Das kann ich auch einfach ignorieren, da sämtliche BitLocker Keys ohnehin auch anderwertig außerhalb der Infrastruktur gesichert sind. Eigentlich bleiben nur noch die 3 Fehlermeldungen aus DCDIAG übrig. Funktionseinschränkungen sind mir derzeit keine mehr bekannt.

Ja sind sie.

CDIAG zeigt folgende relevante Meldungen: - Zeitüberschreitung bei der Namensauflösung für den Namen _ldap._tcp.dc._msdcs.domain.tld., nachdem keiner der konfigurierten DNS-Server geantwortet hat. - Die folgenden SPNs konnten vom WinRM-Dienst nicht erstellt werden: WSMAN/CONTROLLER3.domain.tld; WSMAN/CONTROLLER3. - Zeitüberschreitung bei der Namensauflösung für den Namen _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.domain.tld., nachdem keiner der konfigurierten DNS-Server geantwortet hat. Beide dieser DNS Einträge sind aber vorhanden - SRV Einträge die auch auf den korrekten DC verweisen. Beide SPNs sind ebenfalls vorhanden. Der Client der die BitLocker Sicherung verweigert ist im DNS in der Forward- und Reverse-Lookup-Zone vorhanden und IP stimmt. Ein anderer Client macht die BL-Sicherung ja auch korrrekt. Die beiden nicht mehr existierenden DCs sind aus dem DNS auch komplett entfernt.

Ja, es ist alles dafür vorhanden. Es hat ja früher auch alles funktioniert. Sämtliche nötigen Features und Verwaltungstools sind vorhanden.

Das große GPO neu zusammenbauen würde gut eine Stunde dauern. Mit DCGPOFIX habe ich die beiden Default Richtlinien zurückgesetzt. Diese werden jetzt auch wieder korrekt übernommen. Laut gpresult sind jetzt auch wieder alle GPOs auf den Clients vorhanden wie sie sollen. Auch die verbleibende alte. Die Gruppe "Authentifizierte Benuter" ist vorhanden. Das Recht "Gruppenrichtlinie übernehmen" steht auf "Zulassen". Die Einstellungen im Reiter "Delegation" stimmen zwischen den alten und neuen GPOs überein. Die Gruppenmitgliedschaften aller User sind in Ordnung. Nun ist mir aber ein anderes Problem aufgefallen: "manage-bde.exe -protectors -adbackup x: -id "{...}" sollte ja eigentlich den BitLocker-WH-Key ins AD sichern. Der Befehl gibt auch eine Erfolgsmeldung aus. Aber der Key kommt im AD nicht an und ist im Computerkonto nicht zu sehen. Bei den Events, die ein Fehler sind, bleibt noch übrig: - Auf diesem Computer wird nun die angegebene Verzeichnisinstanz gehostet, doch konnte diese von Active Directory-Webdiensten nicht bedient werden. Von Active Directory-Webdiensten wird in regelmäßigen Abständen erneut versucht, den Vorgang auszuführen. - Der DFS-Replikationsdienst konnte keine Verbindung mit dem Domänencontroller "" zum Zugriff auf die Konfigurationsinformationen herstellen. Die Replikation wurde beendet. Der Dienst wiederholt den Vorgang beim nächsten Konfigurationsabfragezyklus, der in 60 Minuten eintritt. Dieses Ereignis kann durch TCP/IP-Verbindungs-, Firewall-, Active Directory-Domänendienste- oder DNS-Probleme verursacht werden. - Automatic registration failed. Failed to lookup the registration service information from Active Directory. Exit code: Unknown HResult Error code: 0x801c001d. - Automatic registration failed at join phase. Exit code: Unknown HResult Error code: 0x801c001d - Application Error: Name des fehlerhaften Moduls: GPOAdmin.dll

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.

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

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

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

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

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