Group Policy Preferences sind schon eine tolle Sache.
Mal eben schnell und flexibel ein paar Einstellungen verteilen.
Mal eben schnell und flexibel ein paar Einstellungen verteilen.
Was aber wenn diese Einstellungen wirklich nur "Preferences" sein sollen?
Im übertragenen Sinne also "Voreinstellungen".
Auch das ist kein Problem.
In den Eigenschaften jedes Items lässt sich eine Checkbox aktivieren:
"Apply once and do not reapply".
Auch das ist kein Problem.
In den Eigenschaften jedes Items lässt sich eine Checkbox aktivieren:
"Apply once and do not reapply".
Das Geheimnis verbirgt sich in der dazugehörigen XML Datei.
Wird die Checkbox aktiviert, so wird in dieser Datei ein Eintrag erzeugt:
<Filters><FilterRunOnce hidden="1" not="0" bool="AND" id="{2B28F5C1-237A-4EDB-8318-F2B862493D89}"
Wird die Checkbox aktiviert, so wird in dieser Datei ein Eintrag erzeugt:
<Filters><FilterRunOnce hidden="1" not="0" bool="AND" id="{2B28F5C1-237A-4EDB-8318-F2B862493D89}"
Die genannte ID ist natürlich generiert und unterscheidet sich zwischen den
einzelnen Policies und Items.
Diese ID wird auf dem Client gespeichert:
HKCU\Software\Microsoft\Group Policy\Client\RunOnce
einzelnen Policies und Items.
Diese ID wird auf dem Client gespeichert:
HKCU\Software\Microsoft\Group Policy\Client\RunOnce
HKLM\Software\Microsoft\Group Policy\Client\RunOnce
Ist unter diesen Schlüsseln bereits die ID des Items enthalten,
wird es nicht erneut angewendet.
In einer perfekten Welt wäre hier der Artikel am Ende und alle wären glücklich.
Aber das wäre natürlich zu einfach. Die RunOnce GUID bereitet mehr Probleme als vermutet.
Es gibt verschiedene Situationen bei denen es zu ungewünschten Effekten kommen kann:
Es gibt verschiedene Situationen bei denen es zu ungewünschten Effekten kommen kann:
Kopieren von Items:
Wird ein Item in der GUI kopiert, bleibt dummerweise die ID im XML File gleich, was zur Folge hat, dass das kopierte Item nicht angewendet wird.
Sollen also z.B. fünf Dateien kopiert werden und es wird ein Item angelegt und anschließend vier mal kopiert, so wird nur die erste Datei kopiert.
Die folgenden vier Dateien (Items) werden nicht kopiert, da bereits die ID hinter den genannten Registry-Keys hinterlegt sind.
Die folgenden vier Dateien (Items) werden nicht kopiert, da bereits die ID hinter den genannten Registry-Keys hinterlegt sind.
Das genannte Verhalten habe ich bereits hier reklamiert:
http://social.technet.microsoft.com/Forums/nb-NO/winserverGP/thread/ab2fa3c8-3ad0-4068-8a99-da70f7f1f34e
http://social.technet.microsoft.com/Forums/nb-NO/winserverGP/thread/ab2fa3c8-3ad0-4068-8a99-da70f7f1f34e
Im Nachhinein musste ich feststellen, dass diese teilweise schon seit 2009 bekannt ist, jedoch immer noch keine Lösung seitens Microsoft vorliegt.
Item Level Targeting und RunOnce:
Erschwerend hinzu kommt, dass "Apply once and do not reapply" nicht wirklich mit Item Level Targeting (Zielgruppenadressierung) zusammen spielt.
Auch wenn die Bedingungen des ILT nicht erfüllt sind, wird die ID des RunOnce Filters in die Registry gespeichert.
Das Item wird also nie mehr angewendet, auch wenn die Bedingungen des Item Level Targeting irgendwann erfüllt sein sollten.
Fehlende Fehlerprüfung:
Auch hier wurde nicht (oder wenig) mitgedacht.
Selbst wenn das Item nicht korrekt angewendet werden konnte,
die ID wird auch dann in der Registrierung hinterlegt.
die ID wird auch dann in der Registrierung hinterlegt.
Besserung in Sicht:
Die gute Nachricht, zwei der drei Fehlerquellen werden mit SP1 für Windows 7 bzw. Server 2008 R2 beseitigt.
Verantwortlich hierfür ist dieser Hotfix:
http://support.microsoft.com/kb/2284538/en-us
Was bleibt, das Kopieren der Items.
Dieses erzeugt auch unter SP1 noch denselben Fehler.
Die gute Nachricht, unter Windows Server 2012 wird beim Kopieren von Items eine neue ID erzeugt!
Dieses erzeugt auch unter SP1 noch denselben Fehler.
Update 20.08.2012
Die gute Nachricht, unter Windows Server 2012 wird beim Kopieren von Items eine neue ID erzeugt!
Siehe auch
AntwortenLöschenhttp://blogs.technet.com/b/deds/archive/2009/07/24/ein-mal-und-nie-wieder-gp-preferences-apply-once-option.aspx
Schlechte Nachricht:
AntwortenLöschendas was KB2284538 für WIN 7 behoben hat, finden wir in WIN 8.1 wieder:
Einmal wegen ILT nicht angewendete Preferences werden - wenn "Apply Once" aktiviert ist - auch in Zukunft nicht angewendet (selbst wenn die ILT Bedingung erfüllt ist).
Ohne Worte...