17
GPOs greifen nur teilweise
Moin @all!
Ich habe (wieder mal) ein Problem(chen), was für Euch Pro's sicherlich nur eine Kleinigkeit (ein Muntermacher für den heutigen Morgen) ist....
Bei uns sind einige GPOs definiert, die auf einigen Clients alle vollkommen greifen und auf anderen Clients nur teilweise. gpresult/r zeigt aber an, dass die GPOs angewendet werden (oder eben nicht). Die entsprechenden Clients/User sind alle in den OE.
Woran kann das liegen?
THX für die Antwort(en).
Ich habe (wieder mal) ein Problem(chen), was für Euch Pro's sicherlich nur eine Kleinigkeit (ein Muntermacher für den heutigen Morgen) ist....
Bei uns sind einige GPOs definiert, die auf einigen Clients alle vollkommen greifen und auf anderen Clients nur teilweise. gpresult/r zeigt aber an, dass die GPOs angewendet werden (oder eben nicht). Die entsprechenden Clients/User sind alle in den OE.
Woran kann das liegen?
THX für die Antwort(en).
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3728973078
Url: https://administrator.de/forum/gpos-greifen-nur-teilweise-3728973078.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
17 Kommentare
Neuester Kommentar
Moin,
leider wieder zu schwammig formuliert. Was funktioniert denn nicht?
Beispiel: Führst du eine GPO für alle User aus und verbindest hier für Gruppe A einen Drucker, dann wird dir gpresult für Gruppe B eine Erfolgreiche Verarbeitung der GPO anzeigen, aber keinen Drucker verbinden.
Also nochmal von Vorne: Was genau funktioniert nicht und wie ist das was nicht funktioniert konfiguriert?
Gruß
Doskias
leider wieder zu schwammig formuliert. Was funktioniert denn nicht?
Beispiel: Führst du eine GPO für alle User aus und verbindest hier für Gruppe A einen Drucker, dann wird dir gpresult für Gruppe B eine Erfolgreiche Verarbeitung der GPO anzeigen, aber keinen Drucker verbinden.
Also nochmal von Vorne: Was genau funktioniert nicht und wie ist das was nicht funktioniert konfiguriert?
Gruß
Doskias
Hi.
Schau dir mal am Client per rsop.msc (in CMD) an, ob die Einstellungen korrekt gesetzt werden.
Gruß,
TheToxic
Schau dir mal am Client per rsop.msc (in CMD) an, ob die Einstellungen korrekt gesetzt werden.
Gruß,
TheToxic
Wurde in der GPO in der Delegierung eine Einstellung geändert?
Hier sollte Standardmäßig stehen (kann aber nach Bedarf und Situation angepasst werden):
Das Anmeldescript per GPO wird in der GPO ja üblicherweise in der Benutzerkonfiguration eingestellt.
Die GPO ist auch an der OU der Benutzer und nicht der Workstation verknüpft?
Benutzerkonfig -> OU der Benutzer
Computerkonfig -> OU der Computer
Hier sollte Standardmäßig stehen (kann aber nach Bedarf und Situation angepasst werden):
- Authentifizierte Benutzer -> Lesen
- Domänen-Admins -> Einstellung bearbeiten,...
- Domänencontroller der Organisation -> Lesen
- Organisations-Admins -> Einstellung bearbeiten,...
- SYSTEM -> Einstellung bearbeiten,...
Das Anmeldescript per GPO wird in der GPO ja üblicherweise in der Benutzerkonfiguration eingestellt.
Die GPO ist auch an der OU der Benutzer und nicht der Workstation verknüpft?
Benutzerkonfig -> OU der Benutzer
Computerkonfig -> OU der Computer
An der Delegierung ist nichts verändert worden, ergo stimmen die Einstellungen alle. Und ja, die GPO ist an der OU der Benutzer verknüpft, alles Andere würde keinen Sinn ergeben. Zudem besteht das Problem ja nur teilweise und nicht überall.
Und haben auch alle User zugriff auf den Pfad wo das Update.bat liegt?
Ja, der Pfad ist für alle zugänglich. Führe ich den Befehl in der bat-Datei manuell aus, wird diese auch ausgeführt.
Schade. Wäre auch zu einfach gewesen.
Was sagen denn die Windows-Protokolle? Hier steht meist mehr als angewandt oder nicht. Hier kannst du dann sehen warum es nicht funktioniert hat. Pfad nicht gefunden, etc.
Was sagen denn die Windows-Protokolle? Hier steht meist mehr als angewandt oder nicht. Hier kannst du dann sehen warum es nicht funktioniert hat. Pfad nicht gefunden, etc.
Mal ein Schuss ins Blaue...
Verbindest du Laufwerke per Anmeldescript und diese werden nicht angezeigt, ich habe da nämlich ein ähnliches Problem....
Konfiguriere mal in der GPO irgendeine Pille-Palle Einstellung und prüfe ob diese greift.
z.B. Kopiere eine Datei nach C:\Temp oder ähnliches.
Evtl. kannst du so ausschließen ob es an der Verarbeitung der GPO im allgemeinen oder an der Verarbeitung des Scripts liegt.
Verbindest du Laufwerke per Anmeldescript und diese werden nicht angezeigt, ich habe da nämlich ein ähnliches Problem....
Konfiguriere mal in der GPO irgendeine Pille-Palle Einstellung und prüfe ob diese greift.
z.B. Kopiere eine Datei nach C:\Temp oder ähnliches.
Evtl. kannst du so ausschließen ob es an der Verarbeitung der GPO im allgemeinen oder an der Verarbeitung des Scripts liegt.
@Doskias:
Muss/werde ich mir mal ansehen.
@TheToxic:
Nein, es werden keine Laufwerke per Anmeldescript verbunden, dies geschieht bei uns über die Sicherheitsgruppenzugehörigkeit.
Die bat-Datei macht im Grunde genau das, was Du vorgeschlagen hast, und zwar bei jeder Anmeldung eine Datei auf den Client zu kopieren.
Das Komische ist ja, dass an den besagten Clients im Grunde alles GPOs bis eben auf diesen greifen. Somit kann es im allgemeinen nicht an der Verarbeitung dieser liegen und das Script an sich funktioniert an anderen Clients.
Muss/werde ich mir mal ansehen.
@TheToxic:
Nein, es werden keine Laufwerke per Anmeldescript verbunden, dies geschieht bei uns über die Sicherheitsgruppenzugehörigkeit.
Die bat-Datei macht im Grunde genau das, was Du vorgeschlagen hast, und zwar bei jeder Anmeldung eine Datei auf den Client zu kopieren.
Das Komische ist ja, dass an den besagten Clients im Grunde alles GPOs bis eben auf diesen greifen. Somit kann es im allgemeinen nicht an der Verarbeitung dieser liegen und das Script an sich funktioniert an anderen Clients.
Und zu den Anmeldeskripten:
Skriptverzögerung deaktiviert? Ansonsten greifen Anmeldeskripte erst 5 Minuten nach der Anmeldung.
Skriptverzögerung deaktiviert? Ansonsten greifen Anmeldeskripte erst 5 Minuten nach der Anmeldung.
Eine Scriptverzögerung ist nicht aktiv. Selbst wenn, da die Clients stundenlang am Stück laufen, müsste das Script ausgeführt worden sein.
Zitat von @SuperNooby:
Eine Scriptverzögerung ist nicht aktiv. Selbst wenn, da die Clients stundenlang am Stück laufen, müssten es gegriffen haben.
Eine Scriptverzögerung ist nicht aktiv. Selbst wenn, da die Clients stundenlang am Stück laufen, müssten es gegriffen haben.
Die Skriptverzögerung ist immer aktiv, wenn man sie nicht deaktiviert. Aber es stimmt. Wenn sie stunden durchlaufen, dann sollte es irgendwann gehen. Wenn sie aber nicht deaktiviert wurde, dann kann dein GRESULT dir eine erfolgreiche Durchführung anzeigen, wenn du nachschaust ist aber nichts zu sehen, da das Skript halt noch nicht ausgeführt wurde.
Kannst du einen Screenshot der Einstellung deiner GPO hier posten?
An der GPO kann es nicht liegen, da sie an anderen Clients greift. Aber der besagte Client nimmt die anderen GPOs ohne Murren an.
Ich hab das mal mit meinen Skript-GPOs verglichen. Ich hab bei mir immer den vollständigen Skriptpfad hinterlegt, nicht nur den Dateinamen und verzichte auf Leerzeichen. Ich weiß aber nicht ob das Gewohnheit ist oder erforderlich.
Du sagst ja, einige Clients holen sich das Skript und andere nicht. Haben die Clients denn das gleiche OS. Es ist durchaus denkbar, wenn auch unwahrscheinlich, dass einige Client-OS-Versionen den Pfad so wie er ist akzeptieren und andere dort einen Fehler machen. In dem Fall würdest du aber in den Windows-Protokollen irgendwo finden, dass der Pfad zum Skript nicht gefunden wurde.
Du sagst ja, einige Clients holen sich das Skript und andere nicht. Haben die Clients denn das gleiche OS. Es ist durchaus denkbar, wenn auch unwahrscheinlich, dass einige Client-OS-Versionen den Pfad so wie er ist akzeptieren und andere dort einen Fehler machen. In dem Fall würdest du aber in den Windows-Protokollen irgendwo finden, dass der Pfad zum Skript nicht gefunden wurde.
1Zitat von @Doskias:
Ich hab das mal mit meinen Skript-GPOs verglichen. Ich hab bei mir immer den vollständigen Skriptpfad hinterlegt, nicht nur den Dateinamen und verzichte auf Leerzeichen. Ich weiß aber nicht ob das Gewohnheit ist oder erforderlich.
Du sagst ja, einige Clients holen sich das Skript und andere nicht. Haben die Clients denn das gleiche OS. Es ist durchaus denkbar, wenn auch unwahrscheinlich, dass einige Client-OS-Versionen den Pfad so wie er ist akzeptieren und andere dort einen Fehler machen. In dem Fall würdest du aber in den Windows-Protokollen irgendwo finden, dass der Pfad zum Skript nicht gefunden wurde.
Ich hab das mal mit meinen Skript-GPOs verglichen. Ich hab bei mir immer den vollständigen Skriptpfad hinterlegt, nicht nur den Dateinamen und verzichte auf Leerzeichen. Ich weiß aber nicht ob das Gewohnheit ist oder erforderlich.
Du sagst ja, einige Clients holen sich das Skript und andere nicht. Haben die Clients denn das gleiche OS. Es ist durchaus denkbar, wenn auch unwahrscheinlich, dass einige Client-OS-Versionen den Pfad so wie er ist akzeptieren und andere dort einen Fehler machen. In dem Fall würdest du aber in den Windows-Protokollen irgendwo finden, dass der Pfad zum Skript nicht gefunden wurde.
Das kann ich so bestätigen. Ggf. auch das Script nicht im Verzeichnis der GPO sondern unter Netlogon ablegen
Was sagen die Windows-Logs am Client, wie von doskias vorgeschlagen.
Zur aller größten Not den Client aus dem AD und wieder aufnehmen. Ggf. ist hier eine Vertrauensstellung zum DC gestört...
Es kann leider vieles sein
Moin,
die GPO enthält ein Script ,welches "beim Anmelden" ausgeführt werden soll.
Ist in den betroffenen Clients eine SSD/ NVMe installiert und bei denen, bei denen es klappt noch eine olle HDD?
Falls ja: dein Rechner ist schneller verfügbar (und die User melden sich schneller an) als dass dein Netzwerk verfügbar ist.
Ich kenne das zwar eigentlich nur von GPOs, die Computerkonfigurationen abarbeiten, aber prüfe mal, ob bei euch "auf Netzwerk warten" eingestellt ist. Bei uns lag die magische grenze bei 60 Sekunden.
https://www.itnator.net/auf-netzwerk-warten-gruppenrichtlinie-gpo/
Gruß
em-pie
die GPO enthält ein Script ,welches "beim Anmelden" ausgeführt werden soll.
Ist in den betroffenen Clients eine SSD/ NVMe installiert und bei denen, bei denen es klappt noch eine olle HDD?
Falls ja: dein Rechner ist schneller verfügbar (und die User melden sich schneller an) als dass dein Netzwerk verfügbar ist.
Ich kenne das zwar eigentlich nur von GPOs, die Computerkonfigurationen abarbeiten, aber prüfe mal, ob bei euch "auf Netzwerk warten" eingestellt ist. Bei uns lag die magische grenze bei 60 Sekunden.
https://www.itnator.net/auf-netzwerk-warten-gruppenrichtlinie-gpo/
Gruß
em-pie
1
