19
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.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte 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: 21.04.2025 um 08:04 Uhr
19 Kommentare
Neuester Kommentar
Moin,
ich würde mal klein anfangen:
Kann auf das Sysvol und die GPOs des lokalen DCs überhaupt zugegriffen werden, also mal vom lokalen Client testen.
Wie sind denn die DNS Einstellungen am lokalen PC und DC?
Gruss
ich würde mal klein anfangen:
Kann auf das Sysvol und die GPOs des lokalen DCs überhaupt zugegriffen werden, also mal vom lokalen Client testen.
Wie sind denn die DNS Einstellungen am lokalen PC und DC?
Gruss
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?
Zitat von @sabines:
Kann auf das Sysvol und die GPOs des lokalen DCs überhaupt zugegriffen werden, also mal vom lokalen Client testen.
Ja das geht. Die Dateien können auch gelesen werden (dort, wo für die GPO's entsprechende Rechte existieren)Kann auf das Sysvol und die GPOs des lokalen DCs überhaupt zugegriffen werden, also mal vom lokalen Client testen.
Wie sind denn die DNS Einstellungen am lokalen PC
Wie ich schon schrieb:Clients nutzen diesen DC/DNS als einzigen DNS-Server.
und DC?
Der DC ist selbst DNS. Er hostet die AD-integrierte Zone für diese AD-Domäne und die Namensauflösung von den Clients für Records dieser Domäne funktioniert.Zitat von @goscho:
Wie realisiert du, dass der DC zwar mit der Zentrale repliziert, aber die Clients nur lokalen Zugriff haben?
DC steht in einem anderen Subnetz vor Ort und kann mit der Zentrale voll kommunizieren.Wie realisiert du, dass der DC zwar mit der Zentrale repliziert, aber die Clients nur lokalen Zugriff haben?
Die Clients sind in einem eigenen Subnetz vor Ort und kommen nur in das Server-Subnetz vor Ort. Das wird einfach über entsprechende Routing-Regeln gesteuert.
Kannst du von einem dortigen Client den Policies-Ordner unter \\Domain.tld\sysvol\domain.tld erreichen?
Ja. Und alles lesen, wo Rechte entsprechend vergeben sind.
Hallo,
Grüße
lcer
Der DC vor Ort wurde auch schon einmal neu aufgesetzt.
verzeih die Frage: Die Clients sind auch in der korrekten Domäne? Verzeichnen die Computerkonten auf dem DC irgendwelche aktuellen Einträge (letzter Zugriff etc.)?Grüße
lcer
Zitat von @lcer00:
verzeih die Frage: Die Clients sind auch in der korrekten Domäne? Verzeichnen die Computerkonten auf dem DC irgendwelche aktuellen Einträge (letzter Zugriff etc.)?
Ja, das sind sie.verzeih die Frage: Die Clients sind auch in der korrekten Domäne? Verzeichnen die Computerkonten auf dem DC irgendwelche aktuellen Einträge (letzter Zugriff etc.)?
Moin,
habt ihr die DCs in der Zentrale aufgesetzt? Kontrolliere mal die Service Records im DNS ob dort falsche Sitezuordnungen drin sind.
/Thomas
habt ihr die DCs in der Zentrale aufgesetzt?
Ja, alles von uns und in unserer Kontrolle.Kontrolliere mal die Service Records im DNS ob dort falsche Sitezuordnungen drin sind.
Schrieb ich bereits. Heute erst explizit alle SRV überprüft.
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.
Zitat von @sabines:
Ich vermute die Clients versuchen die GPOs auf dem "Haupt" DC zu ziehen, was sie natürlich nicht können.
Kann sein. Die Frage wäre: Warum?Ich vermute die Clients versuchen die GPOs auf dem "Haupt" DC zu ziehen, was sie natürlich nicht können.
Ich könnte das per Wireshark überprüfen. Das ist mir im Moment aber etwas zu aufwändig. Das behalte ich mir als Plan X vor.
Ipconfig liefert alles richtig zurück?
Ja.Gibt es vielleicht noch einen zweiten DNS oder so?
Ja sicher. In der Zentrale. Diese sind aber für die Clients vor Ort irrelevant, weil der DNS-Server, mit welchem sie konfiguriert sind, die betreffende Zone selbst hosted.Vielleicht bringt es was den gpsvcdebuglevel zu aktivieren und es wird ein log erstellt, obwohl ich es nicht glaube.
Nee, bringt nichts. Er verarbeitet ja keine GPO.
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
1
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.
1Zitat 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?
Das hat nichts damit zu tun. Andere Clients aus anderen Subnetzen können diese GPOs doch probemlos laden.
Du hast doch an einem Standort bei einem Subnetz Probleme, verstehe ich das richtig?
Gibt es an diesem Standort mehrere Subnetze?
Welches Windows 10 (Buildlevel?) wurde getestet?
Mir scheint so, als wenn der Zugriff auf die GPOs geblockt wird, Berechtigungen zum lesen sind vorhanden?
Gruss Penny.
Gibt es an diesem Standort mehrere Subnetze?
Welches Windows 10 (Buildlevel?) wurde getestet?
Mir scheint so, als wenn der Zugriff auf die GPOs geblockt wird, Berechtigungen zum lesen sind vorhanden?
Gruss Penny.
1
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.
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
Das kann ich Dir leider nicht mehr sagen. Der betreffende Client wurde inzwischen von den Admins vor Ort plattgemacht.
Aber ich habe inzwischen die Lösung.
s.u.
Aber ich habe inzwischen die Lösung.
s.u.
Zitat von @erikro:
Ist da eine Firewall zwischen den beiden Netzen? Vermutlich. Sind die Ports alle offen, die die Windows-Domain so braucht?
Nein keine FW dazwischen.Ist da eine Firewall zwischen den beiden Netzen? Vermutlich.
Sind die Ports alle offen, die die Windows-Domain so braucht?
Die Lösung ist etwas seltsam. Ich gehe davon aus, dass das ein fetter Bug ist.
Wir haben u.a. noch eine weitere Domäne im selben Forest, welche rein für Verwaltungsaufgaben und für die ganzen Applikationsserver dient. Aus dieser Domäne sind 3 GPO für die Computer am betreffenden Standort verlinkt. Einmal direkt an der Domäne und zwei andere am Standort-Objekt. Sobald man diese Links entfernt funktioniert sofort die GPO-Verarbeitung an den Clients, sowohl für den Computer als auch für den Benutzer. Verlinkt man eine beliebige dieser GPO wieder, geht die GPO-Verarbeitung sofort wieder nicht.
Nun ist mir klar, dass ein Client eine GPO nicht verarbeiten kann, wenn kein DC aus jener Domäne erreichbar ist, in welcher diese GPO gespeichert ist. Aber mir ist in all den Jahren noch nie aufgefallen, dass die GPO-Verarbeitung dann komplett aussteigt. Also auch nicht alle anderen GPO verarbeitet, welche für den Client und/oder Benutzer sonst noch gelten, und für welche auch die betreffenden DCs erreichbar sind.
Ich kann mir auch nicht vorstellen, dass das von Microsoft so gewollt ist. Ich gehen von einem Bug aus.
"Lösung"
Unser Würgarround ist nun, dass wir auch für diese anderen Domäne jetzt einen weiteren DC an diesem Standort platziert haben. Da diese Konstellation mit den Subnetzen nur vorrübergehen während der Projektphase ist, können wir das verschmerzen. Nach Abschluss des Projekts, wenn alle Geräte in den "richtigen" Subnetzen sind, kann dieser DC wieder weg.
Damit funktioniert die GPO-Verarbeitung auch dann, wenn die GPO's aus der anderen Domäne verlinkt sind.
Danke für Eure Beteiligung!
Wir haben u.a. noch eine weitere Domäne im selben Forest, welche rein für Verwaltungsaufgaben und für die ganzen Applikationsserver dient. Aus dieser Domäne sind 3 GPO für die Computer am betreffenden Standort verlinkt. Einmal direkt an der Domäne und zwei andere am Standort-Objekt. Sobald man diese Links entfernt funktioniert sofort die GPO-Verarbeitung an den Clients, sowohl für den Computer als auch für den Benutzer. Verlinkt man eine beliebige dieser GPO wieder, geht die GPO-Verarbeitung sofort wieder nicht.
Nun ist mir klar, dass ein Client eine GPO nicht verarbeiten kann, wenn kein DC aus jener Domäne erreichbar ist, in welcher diese GPO gespeichert ist. Aber mir ist in all den Jahren noch nie aufgefallen, dass die GPO-Verarbeitung dann komplett aussteigt. Also auch nicht alle anderen GPO verarbeitet, welche für den Client und/oder Benutzer sonst noch gelten, und für welche auch die betreffenden DCs erreichbar sind.
Ich kann mir auch nicht vorstellen, dass das von Microsoft so gewollt ist. Ich gehen von einem Bug aus.
"Lösung"
Unser Würgarround ist nun, dass wir auch für diese anderen Domäne jetzt einen weiteren DC an diesem Standort platziert haben. Da diese Konstellation mit den Subnetzen nur vorrübergehen während der Projektphase ist, können wir das verschmerzen. Nach Abschluss des Projekts, wenn alle Geräte in den "richtigen" Subnetzen sind, kann dieser DC wieder weg.
Damit funktioniert die GPO-Verarbeitung auch dann, wenn die GPO's aus der anderen Domäne verlinkt sind.
Danke für Eure Beteiligung!
2
