As I was implementing some Group Policy Preferences recently I stumbled upon a couple of strange behaviors that are everything else but intuitive. Here they go.

Action Types Behavior

The first topic includes the so called CRUD action types Create, Replace, Update or Delete and especially the difference between Replace and Update. Remember: there is a big variance with which items
you use them!

For File Items

Reverse to your expectations the Update Action does NOT update a file depending on its Last Modified Date. Rather it updates ONLY File Attributes. Thus said if you are trying to only update a file content that is older you will have to think of some other methods (see for example Rename below). Au contraire Replace will replace with whatever is in the source without taking into consideration the topicality of the target. Here you can find the TechNet reference.

An interesting aspect is that we are missing a "Rename" action for the files items. A way to accomplish this would be to first copy the old files with new names – here I do this via ‘create’ Normal.dotm Normal.dotm.orig in the same folder, but only if there were none beforehand – and only after that copy the new versions from a different source. In this precise scenario you will have the .orig files as they were before the deployment of this policy and the .dotm files as whatever version you are currently having under the source path.

Once again pay attention to the Order!

For Registry Items

You will be amazed to find out here that the Replace and Update for Registry Items are working much differently from the Files Items.

The most important in a nutshell: you will mostly all of the time use only Update Action. This takes care to update "settings defined within the preference item", in other words if you have a DWORD named Schema you can change its value from, say, 0x000000aa to 0x0000010. Since you normally want to change a single value or a set of values from a larger quantity of values within a key, this action is the only option for you.

Only rarely you would use the Replace Action, because if you have configured only one value within a key, where many values are available on the target machine, the Replace Action will delete all target values that are not present on the source key.

That said; take care also whether you are making changes to the HKEY_CURRENT_USER hive and if this is the case if you have enabled the Run in Logged on User option, coming right now below.

Common Options – Run in Logged on User’s Security Context Behavior

I would lastly like to call your attention to the fact that many are ignoring the common settings on the Items Preferences. Very important, this option is not ‘automagically’ enabled when you are creating policies under "User Configuration". Sad but true – Microsoft should have taken the burden to design better!

I won’t repeat the useful lecture from my colleague Mr. Moody which you can read here, but would like to point to some specifics of the inheritance (or properties propagation to child items) of this option. Normally you would set the ‘logged on user’ under the Registry Item preferences. But if there are many items and/or you were using the Registry Wizard there you end up with nested Collection Items that mirror the imported key structure. In such a case the question arises where you activate the ‘logged on user’ option. One virtual lab demanded that ALL items be set correctly. Sometimes this could take a while and you would be better advised to use the XML file to amend this by simply replacing all ‘userContext’ values from 0 to 1. (Hint from Moody)

In my test environment I simply renamed the Registry Wizard Collection Item and set the option only there. After that when I opened the XML file it had only one userContext="1". Nevertheless the Registry Items were updated under the test user profile. My environment was including a Server 2012 and Windows 7 Professional. So feel free to test under different circumstances and post me a comment with feedback.