Group Policy Preferences: still useful, still pants
I have a love/hate relationship with Group Policy Preferences. On the one hand, they are an awesome time-saver. On the other, they are embarrassingly flawed. Last time I wrote about them I hoped upon hope that they would be better in Windows 7.
They are. A bit.
However, they still suck in certain circumstances.
My most recent annoyance is with the filtering system. This essentially allows you to create conditions for each setting that will be checked when Group Policy is processed. Only if those conditions are met will the settings be applied to the computer or user. These is what makes Group Policy Preferences so powerful, and there are many different types of conditions you can use.
Unfortunately, some of them are just plain broken.
One of the most common ones I find myself wanting to use is the group membership filter, which checks whether the computer or user is a member of a particular AD group. I’ve had problems in the past with these not correctly detecting nested group membership, and more recently, not working at all. What I’ve found is that the most intuitive ways of configuring these filters are the least reliable.
When you configure a security group filter (above), the natural thing to do is to click the little … button next to group name, and pick the group using the normal AD search dialogue. This then fills in the group SID:
Unfortunately, you’ve now broken your filter, at least if you use this method on a Files or Registry preference. Every time I’ve tried it, my clients have failed to apply the setting and left the following error in the Event log:
Log Name: Application
Source: Group Policy Files
Date: 18/02/2010 16:14:52
Event ID: 8196
Task Category: (2)
The client-side extension caught the unhandled exception 'filter expand' inside: 'Access violation (0xc0000005) occurred at 0x6172676f; the memory at 0x6172676f could not be 柠燃샨ċ.' See trace file for more details.
Yes, those characters really did appear in my Event Log.
Today I tried something different; I just typed in the name of the group, without picking it:
Again it failed, but with a subtly different and only slightly less cryptic error:
0x8007203a "The server is not operational."
That error led me here, to someone’s coding frustrations with undocumented bugs in the AD functions of the .NET Framework. His revelations on what worked for him, and what didn’t, led me to try something slightly else: just filling in the SAM account name name of the group, rather than the full name:
Lo and behold, it worked! It’s the simplest method available of specifying the group, but it isn’t the one that the GPP interface leads you to use.
- Picking the group from a list: access violation.
- Specifying the full group name: doesn’t work, returns inaccurate error message.
- Specifying the short name of the group: the only method that works.
The lesson here: I should stop trying to do things the right way, and take more shortcuts. Also, I should poke someone at Microsoft in the eye for not doing enough testing after they bought out DesktopStandard, who created them.
Anyone else have some annoyances/revelations on using Group Policy Preferences?