Donnerstag, 12. April 2012

"Apply once and do not reapply" - aber so war das nicht gemeint!

Group Policy Preferences sind schon eine tolle Sache.
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".





Was passiert hier also?
Wie weiß der Client, dass dieses Item schon einmal angewendet wurde?

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}"

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

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:


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.


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.

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.

Update 20.08.2012

Die gute Nachricht, unter Windows Server 2012 wird beim Kopieren von Items eine neue ID erzeugt!

Kommentare:

  1. Siehe auch
    http://blogs.technet.com/b/deds/archive/2009/07/24/ein-mal-und-nie-wieder-gp-preferences-apply-once-option.aspx

    AntwortenLöschen
  2. Schlechte Nachricht:
    das 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...

    AntwortenLöschen