brigachtal

Nein, der Backgroundrefresh arbeitet GPOs nur dann erneut ab, wenn Änderungen am GPO erkannt werden. Ausnahme sind SIcherheitsrichtlinien, die spätestens alle 16h erzwungen werden. Oder wenn man den Backrefresh entsprechend konfiguriert.

 

Dann hast du es nicht mit adms gemacht, oder führst eine von oben genannten Möglichkeiten durch. Kannst du in jeder Registry schnell nachvollziehen. ;)

 

Bye

Norbert

Hallo Norbert,

ich weiss jetzt nicht ob es ein Unterschied ist, ich verwende nicht die adms sondern die admx Files, aber das düfte doch keinen Unterschied machen.

Bzgl. "der Backgroundrefresh arbeitet GPOs nur dann erneut ab, wenn Änderungen am GPO erkannt werden" habe ich was neues gelernt, vielen Dank.

herzliche Grüße

brigachtal

Wie vergibst du denn Berechtigungen auf Registrywerte?

 

Bye

Norbert

 

 

Das stimmt nicht. Die würden nur dann wieder drin stehen, wenn du jedesmal ein gpupdate /force durchführst oder den Background-Refreshmodus änderst.

 

Bye

Norbert

Hi Norbert,

mit gpupdate /force ist klar. Ohne jede Änderungen an den Vorgaben bzgl. der Refreshzeit werden doch ca. alle 90min sowohl die Benutzer- als auch die Computer-GPOs aktualisiert.

Ich hatte in dieser Richtung bisher keine Probleme. Wenn ein Benutzer bspw. den Vorgabepfad für die Dokumentenablage in Word geändert hat, dann hat es eine bestimmte Zeit gedauert

und der Wert für diesen Parameter aus der GPO war wieder auf dem Client eingetragen.

herzliche Grüße

brigachtal

Die Policies sind nun aber nicht mehr vollständig verwaltbar und können durch die User jederzeit überschrieben werden.

Hi,

das sehe ich nicht so eng, weil beim nächsten Refresh der Gruppenrichtlinien wieder die Vorgabewerte drin stehen, dies gilt sowieso bei der nächsten Anmeldung des

Benutzers

Hallo,

ich habe bei mir das Problem mit den Office 2013 Gruppenrichtlinien für OEM Lizenzen wie folgt gelöst.

Ich verwende die ADMX Files aus den Office 2013 Gruppenrichtlinien und habe darin alle

Eintragungen in der Form

key="software\policies\microsoft\office\15.0 durch

key="software\microsoft\office\15.0 ersetzt.

D.h. Die Office 2013 GPO(s) legt bzw. legen die Registry Keys für Office 2013 auf dem

Arbeitsplatz nicht mehr unter

HKCU\Software\policies\microsoft\office\15.0 usw. usw. an sondern unter

HKCU\Software\microsoft\office\15.0 usw. usw. an.

Ich glaube, dass Microsoft in den OEM oder PKC Lizenzen von Office 2013 die Funktionalität eingebaut hat, dass diese Versionen den

üblichen Registry Pfad HKCU\Software\policies\microsoft\office\15.0 nicht verwenden.

Meine Methode hat den Nachteil, dass beim Löschen einer Office 2013 Policy die Office 2013 Registry Keys auf den Clients erhalten bleiben, aber

das stört mich eigentlich nicht.

Vielleicht hilft es auch einem anderen unter euch.

herzliche Grüße

Brigachtal