Wir haben ein Problem, bei dem einige Computer nicht alle ihre GPOs zu übernehmen scheinen. Wenn wir im Gruppenrichtlinienverwaltungseditor nachsehen, sehen wir viele GPOs mit „rotem x“ und „Datei nicht gefunden“ (und bei denen nicht angegeben ist, um welches GPO es sich handelt).
Ein wenig zu unserer Umgebung: Wir haben 4 Domänencontroller auf der Funktionsebene von Server 2008 R2. 2 DCs sind Server2k8R2 vor Ort, 2 andere sind externe AWS EC2-Instanzen, auf denen Server 2016 läuft.
Beim Ausführen von „net share“ werden sowohl NETLOGON als auch SYSVOL für die beiden 2K8R2-DCs im Vergleich zu den 2K16-DCs auf VERSCHIEDENEN Pfaden freigegeben (ich weiß nicht, ob das ein Problem ist).
Server2016 DCs show these paths:
NETLOGON - C:\Windows\SYSVOL\sysvol\domain.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL\sysvol
Server 2008 R2 DCs show these paths:
NETLOGON - C:\Windows\SYSVOL_DFSR\sysvol\superior.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL_DFSR\sysvol
In allen Fällen ist C:\Windows\SYSVOL\sysvol mit Ausnahme des Ordners domain.local leer.
Beim Ausführen von „DCDIAG“ wird für alle vier der „SystemLog“-Test fehlgeschlagen, und es werden Warnungen beim DFSREvent-Test angezeigt:
AWSDC01 & AWSDC02:
SystemLog test-
"The Netlogon service encountered a client using RPC signing instead of RPC sealing".
"The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account.
DFSREvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
"
OnSite-DC1:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
SystemLog test - "An error event occurred. Event ID 0xC2000001. Unexpected failure. Error code 490@01010004"
OnSite-DC2:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
and
"This computer could not authenticate with \\AWSDC01.domain.local, a Windows domain controller for domain DOMAINNAME, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized."
Weitere Hinweise:
-Event viewer logs (on on-site DC1 and on-site DC2) under application and services > DFS replication show only information about replication between each other. No mention of replication between the AWS DC's.
- Every hour the on-prem DCs show a DFS error "the dfs replication service is stopping communication with partner {other on-prem DC} for replication group Domain System Volume due to an error. Error 9036.
AWS DC02 only shows error logs regarding DFS replication with on-prem DC02. Same error 9036 "replication service stopping due to an error".
AWS DC01, same thing - only shows logs regarding DFS replication with on-prem DC01. Error 9036 "replication service stopped due to an error".
Irgendeine Idee, was hier los sein könnte oder wo wir als nächstes suchen sollen?
Antwort1
Die Fehler deuten auf ein Authentifizierungsproblem hin, sodass das jüngste Kerberos-Update – auf das Greg Askew verweist – durchaus die Ursache sein könnte, insbesondere wenn Sie das Update vor Kurzem durchgeführt haben und das Problem zu diesem Zeitpunkt auftrat. Wenn Sie dies vermuten, sollten Sie das Update vorübergehend entfernen und dann, wenn alles wieder funktioniert, die 2008-Server so schnell wie möglich per Dcpromo ausschalten.
Sie könnten dieses Tool ausprobieren: https://www.microsoft.com/en-us/download/details.aspx?id=30005
Ich bin sicher, dass ich auch schon einmal ein anderes Replikationsüberwachungstool von MS verwendet habe, ich kann mich nur gerade nicht daran erinnern, wie es heißt. Es war eine MSI-Installation, das ist alles, woran ich mich erinnern kann! Vielleicht war es nur FRS-Diagnose, nicht DFRs.
Die AD-Replikation ist in hohem Maße von DNS und synchronisierter Zeit abhängig. Überprüfen Sie daher unbedingt alle Einstellungen dreimal. Sie können die Zeiten vergleichen mit:
net time \\server
Prüfen Sie, ob es Unterschiede gibt – ob es überhaupt funktioniert (d. h. ob beim Ausführen des Befehls kein Verbindungsproblem zwischen den Servern besteht). Andernfalls versuchen Sie, sie alle von derselben externen Zeitquelle aus zu synchronisieren, z. B. pool.ntp.org.
Um DNS zu testen, pingen Sie von jedem anderen Server aus jeden Server-FQDN an und vergleichen Sie die Ergebnisse miteinander und mit Ihren Erwartungen. Ich gehe davon aus, dass Sie ein VPN oder ein ähnliches nicht-nat-L3-Routing zwischen dem lokalen Server und AWS haben. Beispielsweise kann 192.168.1.10 10.0.0.2 oder die „internen“ IPs des lokalen Servers und von AWS anpingen (ich kenne mich nur mit Azure aus, also ist es möglicherweise nicht dasselbe. Verzeihen Sie mir, wenn AWS irgendwie anders funktioniert).
Möglicherweise möchten Sie auch sowohl AWS als auch die lokalen AD-Sites und -Dienste überprüfen, zu NTDS navigieren und sich die Replikationsbeziehungen ansehen. Sie können mit der rechten Maustaste klicken und replizieren und prüfen, ob (umschrieben) „OK“ oder „Geht nicht“ angezeigt wird – dies könnte helfen, das Problem einzugrenzen.