132501
30.01.2019
15125
8
0
GPO wird teilweise nicht angewandt. GPResult -R Zugriff verweigert
Hallo zusammen,
wir haben in unserer Umgebung die Folder Redirection per Standard für jeden User aktiviert. Einige Clients sind allerdings davon ausgenommen und haben die User GPO "Redirect to local path" erhalten. Dies hat bis jetzt auch normal funktioniert. Daten auf Desktop, in Dokumente etc. wurden unter C:\ abgelegt.
Nun haben wir das Problem, dass einige der betroffenen Nutzer wieder Redirection auf den Server aktiviert haben. Allerdings nicht alle Verzeichnisse. Nur Desktop und Dokumente. Downloads wird weiterhin local abgelegt. An der Umgebung hat sich zumindest bewusst nichts geändert. Auffällig ist, dass es nur Windows 7 Clients betrifft. Windows 10 Clients haben das Problem nicht. Führe ich auf einem betroffenen Client gpupdate /force aus, erscheint die Meldung siehe Bild. Eine Neuanmeldung oder gar ein Neustart hilft allerdings nicht.
Bei gpresult -r erscheint die Meldung "Zugriff verweigert", was auch schon mal mindestens ungewöhnlich ist, das wird nicht explizit gesperrt.
Danke vorab.
wir haben in unserer Umgebung die Folder Redirection per Standard für jeden User aktiviert. Einige Clients sind allerdings davon ausgenommen und haben die User GPO "Redirect to local path" erhalten. Dies hat bis jetzt auch normal funktioniert. Daten auf Desktop, in Dokumente etc. wurden unter C:\ abgelegt.
Nun haben wir das Problem, dass einige der betroffenen Nutzer wieder Redirection auf den Server aktiviert haben. Allerdings nicht alle Verzeichnisse. Nur Desktop und Dokumente. Downloads wird weiterhin local abgelegt. An der Umgebung hat sich zumindest bewusst nichts geändert. Auffällig ist, dass es nur Windows 7 Clients betrifft. Windows 10 Clients haben das Problem nicht. Führe ich auf einem betroffenen Client gpupdate /force aus, erscheint die Meldung siehe Bild. Eine Neuanmeldung oder gar ein Neustart hilft allerdings nicht.
Bei gpresult -r erscheint die Meldung "Zugriff verweigert", was auch schon mal mindestens ungewöhnlich ist, das wird nicht explizit gesperrt.
Danke vorab.
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: 399878
Url: https://administrator.de/contentid/399878
Ausgedruckt am: 22.11.2024 um 21:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
habt Ihr die letzten Windows Updates installiert?
Nicht dass es damit zusammenhängt?
Gruss Penny
habt Ihr die letzten Windows Updates installiert?
Nicht dass es damit zusammenhängt?
Gruss Penny
Updates werden hier regelmäßig installiert. Ganz auszuschließen ist es nicht. Die Frage ist auch seit wann es so ist. Ist vermutlich nicht unmittelbar aufgefallen.
Bei gpresult -r erscheint die Meldung "Zugriff verweigert", was auch schon mal mindestens ungewöhnlich ist, das wird nicht explizit gesperrt
Das ist zu erwarten, wenn Du die Kommandozeile nicht elevated gestartet hast. In deinem Screenshot ist das nicht der Fall.Rechtsklick auf cmd.exe ->als Administrator ausführen und dann klappt das.
gpresult -r sollte auch ohne Admin Privilegien ausführbar sein. Zumindest ist das auf all den anderen Clients der Fall. gpresult -r mit Admin Credentials führt zu einem anderen Fehler, denn ich leider nicht auf Screenshot habe.
EDIT:
Habe das hier gefunden und werde es morgen mal testen:
https://social.technet.microsoft.com/Forums/lync/en-US/c0ee4e1c-9278-404 ...
EDIT:
Habe das hier gefunden und werde es morgen mal testen:
https://social.technet.microsoft.com/Forums/lync/en-US/c0ee4e1c-9278-404 ...
Hat hier jemand noch eine Idee?
Der Versuch im Technet hat nicht funktioniert.
Der Versuch im Technet hat nicht funktioniert.
Konnte das Problem jetzt etwas eingrenzen.
Bei Ausführung von RSoP kommt der Fehler:
Das Interessante ist, dass dies nur die Rechner in der OU "EEK" betrifft. Die Clients in "EE" haben dieses Problem nicht, dort ziehen aber die exakt selben Richtlinien (lediglich mit minimal anderer Konfiguration, wie z. B. andere User in die lokale Admingruppe etc.).
RSoP wird nicht durch eine GPO abgeschaltet.
Hier hat es keinerlei Anpassungen gegeben in den letzten Monaten.
Bei Ausführung von RSoP kommt der Fehler:
Das Interessante ist, dass dies nur die Rechner in der OU "EEK" betrifft. Die Clients in "EE" haben dieses Problem nicht, dort ziehen aber die exakt selben Richtlinien (lediglich mit minimal anderer Konfiguration, wie z. B. andere User in die lokale Admingruppe etc.).
RSoP wird nicht durch eine GPO abgeschaltet.
Hier hat es keinerlei Anpassungen gegeben in den letzten Monaten.
So bin noch ein Schritt weiter:
Habe nach diesem Fehler gegoogelt und ein Script gefunden, welches nicht weiter beschrieben ist. So wie ich das sehe wird das Repository damit gelöscht und zurückgesetzt. Bei Neuanmeldung dann natürlich neu geschrieben und erstellt. Danach funktioniert es auch wieder so halbwegs:
Die angewandten GPOs werden wieder angezeigt aber nicht die Gruppenzugehörigkeiten. Die GPOs hatten auf dem Client auch keinen Effekt. Ich habe den PC dann testweise aus der Domäne genommen und wieder hinzugefügt. Allerdings taucht er bis jetzt nicht in der Domäne auf. Da muss noch mal schauen.
Das Script:
Was mich nur total wundert ist, dass dieses Problem nur eine Hand voll Windows 7 User der gleichen OU haben. Windows 10 User haben es nicht und auch andere User mit Windows 7 in anderen OUs haben es nicht.
Habe nach diesem Fehler gegoogelt und ein Script gefunden, welches nicht weiter beschrieben ist. So wie ich das sehe wird das Repository damit gelöscht und zurückgesetzt. Bei Neuanmeldung dann natürlich neu geschrieben und erstellt. Danach funktioniert es auch wieder so halbwegs:
Die angewandten GPOs werden wieder angezeigt aber nicht die Gruppenzugehörigkeiten. Die GPOs hatten auf dem Client auch keinen Effekt. Ich habe den PC dann testweise aus der Domäne genommen und wieder hinzugefügt. Allerdings taucht er bis jetzt nicht in der Domäne auf. Da muss noch mal schauen.
Das Script:
net stop winmgmt
pause
c:
cd c:\windows\system32\wbem
rd /S /Q repository
regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll
mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
for /f %%s in ('dir /b *.mfl') do mofcomp %%s
mofcomp exwmi.mof
mofcomp -n:root\cimv2\applications\exchange wbemcons.mof
mofcomp -n:root\cimv2\applications\exchange smtpcons.mof
mofcomp exmgmt.mofWas mich nur total wundert ist, dass dieses Problem nur eine Hand voll Windows 7 User der gleichen OU haben. Windows 10 User haben es nicht und auch andere User mit Windows 7 in anderen OUs haben es nicht.
1
Hallo zusammen.
Noch eine Rückmeldung, auch wenn der Thread schon ziemlich alt ist...
Das beschriebene Problem betraf in unserem Fall eine Windows-10-VM (Vers. 1909, 64bit auf Hyper-V), wobei auch RSOP fehlende Rechte meldete. Nach Anwendung des Skripts werden die Gruppenrichtlinien wieder verarbeitet.
Grüße
Wolfgang
Noch eine Rückmeldung, auch wenn der Thread schon ziemlich alt ist...
Das beschriebene Problem betraf in unserem Fall eine Windows-10-VM (Vers. 1909, 64bit auf Hyper-V), wobei auch RSOP fehlende Rechte meldete. Nach Anwendung des Skripts werden die Gruppenrichtlinien wieder verarbeitet.
Grüße
Wolfgang
