Probleme im AD am Außenstandort
Hi,
wir haben ein Problem mit AD und GPO am Außenstandort und ich stehe momentan mächtig auf dem Schlauch. Irgendwas übersehe ich. Ich bräuchte mal Denkanstöße.
Setup
An einem Standort ist es so, dass die Clients in einem Subnetz sind, von welchem aus sie nur den DC vor Ort erreichen können. Das ist so gewollt. Die Clients in diesem Subnetz haben diesen lokalen DC als einzigen DNS-Server eingetragen und können FQDN und SRV aus der betreffenden Zone korrekt auflösen. Die Clients können der Domäne beitreten. Man kann sich anschließend mit einem Konto aus dieser Domäne anmelden. Man kann sich auch mit Konten aus anderen Domänen des Forest anmelden. Auch wenn diese Konten noch nie vorher an diesem Client angemeldet waren. Die Authentifizierung über den DC vor Ort funktioniert also.
Das Problem
Die Clients in diesem Subnetz bekommen keine GPO. Nichts. Wenn man "gpresult /r" ausführt, dann kommt "INFO: Benutzer "..." hat keine RSOP-Daten." Auch nicht, wenn man mit "/scope user" oder "/scope computer" eingrenzt. Als Client OS haben wir bisher Win10 und Win2008R2 getestet. Einmal ein Blech und einmal eine VM unter ESX.
Die lokalen Uhren sind synchron mit dem DC und dem Rest der Domäne. Zeitzone und Datum stimmen auch.
Bei Anmeldung mit einem Domänen-Admin:
Im Ereignisprotokoll steht im betreffenden Eintrag unter Details nur:
"GPRESULT /H GPReport.html" kann ich nicht ausführen, weil da wieder kommt: "INFO: Benutzer "..." hat keine RSOP-Daten."
Also: Habt Ihr Ideen, wo ich jetzt noch ansetzen kann?
E.
wir haben ein Problem mit AD und GPO am Außenstandort und ich stehe momentan mächtig auf dem Schlauch. Irgendwas übersehe ich. Ich bräuchte mal Denkanstöße.
Setup
- Alle DC dieser Domäne sind Windows 2016
- Domäne in der Zentrale, 2 DC's
- 4 Standorte mit je einem DC dieser Domäne. Alle diese DC sind GC und DNS mit Zone für diese Domäne. Standleitung >= 2Mbit.
- PDC-Emulator auf DC in der Zentrale
- Peplikation ohne Probleme. Domänen-Objekte und SYSVOL werden repliziert. Alle GPO-Dateien sind vorhanden.
- Standorte sind im AD abgebildet (Subnet- und Site-Objekte)
- Die DC's und die Clients an den Standorten erkennen ihren jeweiligen Standort (überprüft mit "nltest /DsGetSite")
An einem Standort ist es so, dass die Clients in einem Subnetz sind, von welchem aus sie nur den DC vor Ort erreichen können. Das ist so gewollt. Die Clients in diesem Subnetz haben diesen lokalen DC als einzigen DNS-Server eingetragen und können FQDN und SRV aus der betreffenden Zone korrekt auflösen. Die Clients können der Domäne beitreten. Man kann sich anschließend mit einem Konto aus dieser Domäne anmelden. Man kann sich auch mit Konten aus anderen Domänen des Forest anmelden. Auch wenn diese Konten noch nie vorher an diesem Client angemeldet waren. Die Authentifizierung über den DC vor Ort funktioniert also.
Das Problem
Die Clients in diesem Subnetz bekommen keine GPO. Nichts. Wenn man "gpresult /r" ausführt, dann kommt "INFO: Benutzer "..." hat keine RSOP-Daten." Auch nicht, wenn man mit "/scope user" oder "/scope computer" eingrenzt. Als Client OS haben wir bisher Win10 und Win2008R2 getestet. Einmal ein Blech und einmal eine VM unter ESX.
Die lokalen Uhren sind synchron mit dem DC und dem Rest der Domäne. Zeitzone und Datum stimmen auch.
Bei Anmeldung mit einem Domänen-Admin:
- hat dieser lokale Admin-Rechte (über die standardmäßige Verschachtelung der "Domänen-Admins" in den lokalen "Administratoren")
- kommt bei "gpupdate /force":
Die Richtlinie wird aktualisiert...
Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, neue Gruppenrichtlinieneinstellungen für diesen Benutzer oder Computer abzurufen. Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". Dieser Vorgang wird automatisch beim nächsten Aktualisierungszyklus wiederholt. Computer, die der Domäne beigetreten sind, müssen über eine geeignete Namensauflösung sowie über eine Netzwerkverbindung zu einem Domänencontroller zum Ermitteln von neuen Gruppenrichtlinienobjekten und -einstellungen verfügen. Wenn die Gruppenrichtlinie erfolgreich ist, wird ein Ereignis protokolliert.
Die Computerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, neue Gruppenrichtlinieneinstellungen für diesen Benutzer oder Computer abzurufen. Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". Dieser Vorgang wird automatisch beim nächsten Aktualisierungszyklus wiederholt. Computer, die der Domäne beigetreten sind, müssen über eine geeignete Namensauflösung sowie über eine Netzwerkverbindung zu einem Domänencontroller zum Ermitteln von neuen Gruppenrichtlinienobjekten und -einstellungen verfügen. Wenn die Gruppenrichtlinie erfolgreich ist, wird ein Ereignis protokolliert.
Lesen Sie zur Fehlerdiagnose das Ereignisprotokoll, oder führen Sie den Befehl "GPRESULT /H GPReport.html" aus, um auf Informationen über Gruppenrichtlinienergebnisse zuzugreifen.
Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, neue Gruppenrichtlinieneinstellungen für diesen Benutzer oder Computer abzurufen. Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". Dieser Vorgang wird automatisch beim nächsten Aktualisierungszyklus wiederholt. Computer, die der Domäne beigetreten sind, müssen über eine geeignete Namensauflösung sowie über eine Netzwerkverbindung zu einem Domänencontroller zum Ermitteln von neuen Gruppenrichtlinienobjekten und -einstellungen verfügen. Wenn die Gruppenrichtlinie erfolgreich ist, wird ein Ereignis protokolliert.
Die Computerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, neue Gruppenrichtlinieneinstellungen für diesen Benutzer oder Computer abzurufen. Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". Dieser Vorgang wird automatisch beim nächsten Aktualisierungszyklus wiederholt. Computer, die der Domäne beigetreten sind, müssen über eine geeignete Namensauflösung sowie über eine Netzwerkverbindung zu einem Domänencontroller zum Ermitteln von neuen Gruppenrichtlinienobjekten und -einstellungen verfügen. Wenn die Gruppenrichtlinie erfolgreich ist, wird ein Ereignis protokolliert.
Lesen Sie zur Fehlerdiagnose das Ereignisprotokoll, oder führen Sie den Befehl "GPRESULT /H GPReport.html" aus, um auf Informationen über Gruppenrichtlinienergebnisse zuzugreifen.
Im Ereignisprotokoll steht im betreffenden Eintrag unter Details nur:
Quelle: GroupPolicy
ID: 1030
ErrorDescription: Der angegebene Server kann den angeforderten Vorgang nicht ausführen.
DCName: \\xyz-dc.domain.tld
...
ID: 1030
ErrorDescription: Der angegebene Server kann den angeforderten Vorgang nicht ausführen.
DCName: \\xyz-dc.domain.tld
...
"GPRESULT /H GPReport.html" kann ich nicht ausführen, weil da wieder kommt: "INFO: Benutzer "..." hat keine RSOP-Daten."
- Suche im Web nach o.g. Eventlog-Eintrag (Quelle & ID) hat mich auch nicht weitergebracht.
- DNS-Fehler kann ich ausschließen. Ich habe soeben alle SRV-Records überprüft. Nirgends sind irgendwelche "Leichen" drin. Die Records für diesen Standort verweisen für LDAP, Kerberos und GC auf den DC vor Ort. "nltest /DsGetDC:domain.tld" liefert korrekt den DC vor Ort
- Zwischen Client und DC ist keine Firewall. Lokale Firewalls sind aus.
- Der DC vor Ort wurde auch schon einmal neu aufgesetzt.
Also: Habt Ihr Ideen, wo ich jetzt noch ansetzen kann?
E.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 390295
Url: https://administrator.de/forum/probleme-im-ad-am-aussenstandort-390295.html
Ausgedruckt am: 01.04.2025 um 17:04 Uhr
19 Kommentare
Neuester Kommentar
Mahlzeit,
Wie realisiert du, dass der DC zwar mit der Zentrale repliziert, aber die Clients nur lokalen Zugriff haben?
Kannst du von einem dortigen Client den Policies-Ordner unter \\Domain.tld\sysvol\domain.tld erreichen?
Zitat von @emeriks:
An einem Standort ist es so, dass die Clients in einem Subnetz sind, von welchem aus sie nur den DC vor Ort erreichen können. Das ist so gewollt. Die Clients in diesem Subnetz haben diesen lokalen DC als einzigen DNS-Server eingetragen und können FQDN und SRV aus der betreffenden Zone korrekt auflösen. Die Clients können der Domäne beitreten. Man kann sich anschließend mit einem Konto aus dieser Domäne anmelden. Man kann sich auch mit Konten aus anderen Domänen des Forest anmelden. Auch wenn diese Konten noch nie vorher an diesem Client angemeldet waren. Die Authentifizierung über den DC vor Ort funktioniert also.
An einem Standort ist es so, dass die Clients in einem Subnetz sind, von welchem aus sie nur den DC vor Ort erreichen können. Das ist so gewollt. Die Clients in diesem Subnetz haben diesen lokalen DC als einzigen DNS-Server eingetragen und können FQDN und SRV aus der betreffenden Zone korrekt auflösen. Die Clients können der Domäne beitreten. Man kann sich anschließend mit einem Konto aus dieser Domäne anmelden. Man kann sich auch mit Konten aus anderen Domänen des Forest anmelden. Auch wenn diese Konten noch nie vorher an diesem Client angemeldet waren. Die Authentifizierung über den DC vor Ort funktioniert also.
Wie realisiert du, dass der DC zwar mit der Zentrale repliziert, aber die Clients nur lokalen Zugriff haben?
Kannst du von einem dortigen Client den Policies-Ordner unter \\Domain.tld\sysvol\domain.tld erreichen?
Moin,
habt ihr die DCs in der Zentrale aufgesetzt? Kontrolliere mal die Service Records im DNS ob dort falsche Sitezuordnungen drin sind.
/Thomas
Mal so ins Blaue:
Ich vermute die Clients versuchen die GPOs auf dem "Haupt" DC zu ziehen, was sie natürlich nicht können.
Ipconfig liefert alles richtig zurück?
Gibt es vielleicht noch einen zweiten DNS oder so?
Vielleicht bringt es was den gpsvcdebuglevel zu aktivieren und es wird ein log erstellt, obwohl ich es nicht glaube.
Ich vermute die Clients versuchen die GPOs auf dem "Haupt" DC zu ziehen, was sie natürlich nicht können.
Ipconfig liefert alles richtig zurück?
Gibt es vielleicht noch einen zweiten DNS oder so?
Vielleicht bringt es was den gpsvcdebuglevel zu aktivieren und es wird ein log erstellt, obwohl ich es nicht glaube.
Hi
Das hier mal auf deinem DC kontrolliert ?
https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfun ...
Mit freundlichen Grüßen Nemesis
Das hier mal auf deinem DC kontrolliert ?
https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfun ...
Mit freundlichen Grüßen Nemesis
Hallo emeriks,
Du schreibst, daß an einem Standort die Clients aus dem Subnetz keine GPO bekommen.
Kannst Du einen oder mehrere Clients testweise in das Subnetz verschieben, wo der DC ist?
Dann sollten die GPO gezogen werden.
Dann verschiebe einen Client testweise in ein anderes Subnetz am Standort und teste erneut.
Werden dann die GPOs gezogen, deutet das für mich auf ein Netzwerk-/Routingproblem hin.
Möglicherweise wird das holden der GPOs geblockt (Protokoll, Port?).
Nur mal so als Zwischenmeldung meinerseits.
Gruss Penny.
Du schreibst, daß an einem Standort die Clients aus dem Subnetz keine GPO bekommen.
Kannst Du einen oder mehrere Clients testweise in das Subnetz verschieben, wo der DC ist?
Dann sollten die GPO gezogen werden.
Dann verschiebe einen Client testweise in ein anderes Subnetz am Standort und teste erneut.
Werden dann die GPOs gezogen, deutet das für mich auf ein Netzwerk-/Routingproblem hin.
Möglicherweise wird das holden der GPOs geblockt (Protokoll, Port?).
Nur mal so als Zwischenmeldung meinerseits.
Gruss Penny.
Moin,
Ist da eine Firewall zwischen den beiden Netzen? Vermutlich.
Sind die Ports alle offen, die die Windows-Domain so braucht?
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
<edit>Hier klicken</edit>
hth
Erik
Zitat von @emeriks:
Zitat von @Penny.Cilin:
Kannst Du einen oder mehrere Clients testweise in das Subnetz verschieben, wo der DC ist?
Dort laufen bereits einige Memberserver, und diese haben keine Probleme damit.Kannst Du einen oder mehrere Clients testweise in das Subnetz verschieben, wo der DC ist?
Ist da eine Firewall zwischen den beiden Netzen? Vermutlich.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
<edit>Hier klicken</edit>
hth
Erik