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)
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      robinson.angrytech.internal
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.

In summary:

  • 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?

Tags: , ,

About The Angry Technician

The Angry Technician is an experienced IT professional in the UK education sector. Normally found in various states of annoyance on his blog. All views are those of his imaginary pet dog, Howard.

23 responses to “Group Policy Preferences: still useful, still pants”

  1. p858snake says :

    have you tried name@domain? (For example “domain computers@angrytech.local” (or how ever you format them using that way))

  2. StevenM says :

    Totally agree, potentially wonderful, actually frustrating! Thanks for the tip on just typing the group name in though :)

  3. Mr M says :

    Re your point about nested groups it’s always worth checking the consistency of domain functional level across the AD schema. (Only applies when your domain is old and has been upgraded… so guessing this isn’t the case in your post!) Otherwise nested groups don’t work properly. In some cases it will lure you into a sense of false security by appearing like nested groups work, or by letting you nest distribution groups but not security groups, thus confusing you. You probably knew that already. See here for reference: … Yes – that is a BRACKET in the URL.

    I have so many gripes on this subject as well as related ones.

    On the subject of GP and security group filtering, my main GP issue is still the one I had to actually call Microsoft about, and the one that turned out was a bug, but they never resolved. This was when I realised the GPMC group policy modelling wizard doesn’t correctly model software installations that are filtered by security group (where security is set on the software deployment object itself). It comes to something when Microsoft’s own troubleshooting tools lead you to spend hours investigating an potential, unknown ‘bigger problem’ when in actual fact it’s just the inaccuracy of the tool itself…

    • AngryTechnician says :

      I’d never noticed that GPMC problem before, but you’re right – just ran a model and it didn’t produce any results for software installation!

  4. Mike M says :

    Thank you for posting your findings! We spent many hours pulling our hair out (not much left in that department to give!) trying to figure out why were seeing this message in Event Viewer: error code ‘0x8007203a The server is not operational.’

    After lots of Googling and Binging (sounds like something one does in Las Vegas…) we stumbled upon this page. Most search results were related to Exchange problems. Thankfully, this page was one of those that Google found for us.

    Note, your solution is the ONLY one that works! The “” returns the same dreaded error message.

  5. JC Miller says :

    Thanks – this post was a huge help. I had previously used the Desktop Standard registry extension, and it worked with the full names.

  6. Daniel says :

    Great find. I’ve been seeing the same issue in the logs on my workstations. What the heck sort of event log error is “Access violation (0xc0000005) occurred at 0x000049e0; the memory at 0x000049e0 could not be 盌焚刈ȳ.’ “. Thanks, Microsoft.

    I agree with you, that while GPP is a great tool, there are still some major suckage points. For me, two of the main ones are:

    1. A massive bug (fixed only by an obscure hotfix, not a WSUS/Windows Update patch) that kills all services on a machine if you change the regional settings using GPP. If you do this, the regional settings get all screwed up, even for service accounts on the machine. This, in turn, causes services to fail at startup because the account they’re starting up as has borked regional settings.

    2. Print mapping via GPP on Vista is still massively broken in my environment. Works beautifully on XP and Windows 7, but Vista machines hang for 60+ minutes when trying to apply GPP print mappings.

  7. Mike Reynolds says :

    Found this site while spelunking for solution to another GPP frustration, thought I’d also second (third? fourth?) others’ comments that GPP is simultaneously quite useful (good features) and quite frustrating (bugs! bugs! bugs!). I’m sure anybody who has tried Immediate Tasks in Win7 has already found kb977353 to fix the first bug. But I also had to rig up two more workarounds to get them working, both by editing the scheduledtasks.xml.

    First was that gui doesn’t correctly configure xml if you want Computer scheduled task to run as SYSTEM (as if anybody ever wanted a Computer scheduled task to run as SYSTEM!). Answer: after editing in gui, change xml: remove “runAs” property, change data to “Service Account”, change data to “SYSTEM” (replace Userid if there), and remove.

    Second was that even after kb977353 immediate tasks were still getting deleted before they could run. Finally realized I could replace the TimeTrigger with a RegistrationTrigger, which allowed addition of a element. Delete the element, make the data longer in the future, and you’re golden.

    But why are we having to kludge this stuff at all? Isn’t there any quality control any more at Microsoft, or do they need billg back to put the fear of god back into them?

  8. Mike Reynolds says :

    Oops, sorry about no white space there, didn’t realize post was going to clean up so much. Wanted to mention my current GPP frustration, in case any ideas. I’ve found that shortcuts applied to newly reimaged/domain-joined machine don’t work. GPP shortcut gets applied no problem to machine already built, but not to first-bootup after reimaged machines. I fear a repeat of the Immediate Tasks problem, where timing screwed up. No good to just wait until next GP refresh, as I want these to be “apply once”, so that users can delete the shortcut if they don’t want it. This is if applying to Computer to %allusersprograms%.

    Same kind of thing happens if applied as User GPP to %programs% — if new user profile, shortcut doesn’t get applied. In both cases, registry GP/RunOnce registers the “apply once” GP task as having been applied.

    An appropriate name for this site — angry technician — as I find myself in that state a lot trying to use GPP’s.

  9. Claude-Alain says :

    I had the same problem, depending on the number of members in the security group.
    With your solution, no more problem!

  10. Ed Failor says :

    We just corrected this problem at my work on a GPO that had registry settings being applied inside GPPE using ILT. We had symptoms of XP clients performing policy updates where we were seeing Winlogon.exe to LDAP – TCP connections lasting 15 min in the ESTABLISHED state. For our clients updating policy against a Windows 2008 DC, this 15 min connection would eventually go away. For our clients working off of a Windows 2003 DC, the ESTABLISHED connection would last 15 min and turn into the dreaded CLOSE_WAIT. You can’t get rid of CLOSE_WAIT’s unless you reboot, so we were seeing our clients eventually exhaust their ports. By copying the AD security group name inside the Targeting Editor group field, deleting it, (which removes the SID), and then pasting it back into the group field, we are now seeing TCP connections being made and going away quickly, or moving into the TIME_WAIT state, which is a natural state for a connection to reach when it’s in the closing phases.

    We have a ticket open with MS Support, and they had never seen this symptom, though they are investigating it – though XP and Server 2003 are no longer in mainstream support – so it’s time to upgrade! Weee!!

  11. LSICT says :

    Just came across this article when investigating a similar issue. When deploying scheduled tasks with GP Prefs. The same issue occurs as with the groups. Select the account from the interface and it comes back as ‘domain\accountname’ and does not work (sets tasks to run as SYSTEM). If you just type the account samid (e.g. accountname) it works perfectly. I have spent the past week fixing things that Microsoft haven’t. Most recently this and the problem that terminal server remote apps can’t handle password expiry at all.

    Thank you Redmond. Great idea, half-ar*ed implementation!

  12. BobbyJ says :

    I’m so glad I found this post!
    I mentioned this problem (amongst others) on the technet forum back in August 2009!!!

    I figured these problems would be fixed in XP before it went out of mainstream support-I figured wrong. It is fustrating that such a powerful tool could be so full of snags and holes in the first place. To not bother fixing the issues when they are found is ridiculous. Microsoft should make the effort to make the product work as advertised for Windows XP too.

    • AngryTechnician says :

      It’s still not fixed for Windows 7 or Vista unless you manually install an hotfix that isn’t available through Microsoft Update, WSUS, or the Update Catalog. Some useful info in the link you posted, thanks.

  13. patrickhoban says :

    I was having the same frustrations with GPP…mainly nested groups or any terminal session items not working. I was able to get the 2008 SP2 patch mentioned in KB2300745 which as of today is the latest hotfix rollup for GPP. My initial testing shows that those are fixed but I need to do some more exhaustive testing. I’ll try to post back with some results.

  14. rvdmast says :

    Just wanted to mention that we had exactly this problem with deploying printers using GPP & security filtering, and that hotfix kb976399 seems to have fixed it for us.

  15. IT.Never.Ends... says :

    Thanks Alot, this post was very helpful, lucky i got to it on time before trying anything else.

  16. Jenny says :

    Dude, I just want to say thanks. I’ve been banging my head for over two full days and pouring through logs. I’ve become far more of an in-depth group policy expert than I’d ever wanted. And then, after hours of googling, I stumble on your post. I’m not sure whether I didn’t “set” the group security properly the first time or whether it got corrupt in my policy but just having the common name listed wasn’t enough for my security to pass on a printer deployment policy. Once I searched active directory so the group underlined and a SID was populated underneath it, success. Thanks, man. I have to say, I never would have guessed that would be the answer. I am doing a serious happy dance over here. What a way to end a crappy work week! Wooohooo!!!!!

  17. Mr M says :

    Just googled “0x8007203a The server is not operational”, first result, this page. Doing a bit of temp work for Bond. Life is funny like that… #incestuous

    • The Angry Technician says :

      I have a feeling that bug has been fixed in more recent GPP hotfixes. Try applying KB2561285 and see if the problem goes away (I know that KB has nothing to do with the bug, but GPP hotfixes are cumulative).

      • Mr M says :

        Either way, I recreated the item for which I was using targeting (scheduled task in my case) and typed the group name in, refreshed policy on client, and that event was no longer created.

        Annoying thing is that the darned scheduled task still isn’t showing up… *begins troubleshooting further*

%d bloggers like this: