Group policy "applied" but not making any settings until running a GPUPDATE /force

[MrBeatnik]

Hi folks.

We have a strange problem with our linked clone desktops.

The pool builds the desktop and registers with AD correctly using QuickPrep. When a user logs in, settings that the group policy would normally apply are not apparently working.

However, the GPRESULT /R command shows all policies correctly! All policies appear to be getting applied.

But when doing a RSOP.MSC, none of the settings can be seen.

As soon as I do a GPUPDATE /FORCE, the policy starts working:

• Desired effects are immediately seen on the desktop (i.e. one setting is to hide the C drive in explorer).
• RSOP.MSC now shows the settings that were previously missing.
• GPRESULT /R shows no difference.

We are running the following:

• VMware View 5.2
• Non-Persistent Desktops - destroyed on logout.
• Windows 7
• OU has inheritance blocked, and settings are not set anywhere else (i.e. not conflicting settings).

It appears that if an available desktop is left long enough for the group policy refresh to occur before a user logs in, then all works correctly. It's just like the policy is not working correctly before a normal refresh (whether forced or timed).

Any advice?

[gmtx]

If these are Group Policy Preferences not working I'd have a hard look here Recommended Updates for Group Policy in Windows Client and Server Products for some of the available hotfixes.

Geoff

[MrBeatnik]

Thanks for the reply.

Unfortunately, these are just regular GPo. Nothing fancy at all. I had a look at the link, but couldn't see anything particularly pertinent.

We don't get the issue on physical machines, which is why I was posting here.

It appears to be a problem with how the base image is applying the Group Policy when it creates a linked clone...

[Zaim33]

This sounds like a common GPO issue for computer settings where the desktop will not action any policy settings until the 2nd (or even 3rd) reboot.

You can 'bake' GPO settings into a desktop by ensuring your master image gets policy settings while it is on then open secpol.msc on the master image and checking that some settings are managed by GPO. Worth opening secpol.msc on your deployed images as well to see if any settings are being applied by GPO (unlikely from what you've said) before you run GPUPDATE or reboot..

For the failed desktops before you do a GPUPDATE can you reboot the desktops once and then twice after they are built (as long as they don't refresh on reboot) and see if the policy settings take effect.

Check out Group Policy Basics - Part 3: How Clients Process GPOs - Midnight Musings of a Technical TAM - Site... for more detail, in particular:

1. When a GPO is processed, your client checks to see whether any settings have been configured which require foreground processing.
2. If it finds any of these settings configured, it makes a note of this and schedules these settings to be applied the next time the client reboots or logs in (depending on what is required for the particular setting)
3. The next time a startup or login occur, the settings identified are processed using foreground processing rules

Also check to see if you have asynchronous policy processing and Wait for Network at Startup and Logon disabled in your policy. These will speed up computer logon but will impact policy processing. If you set these to Wait for the network and force synchronous policy processing then all policies should get processed.

[MrBeatnik · Accepted solution]

Thanks for the info.

Part of the problem is the refresh on reboot making it difficult to diagnose...

In the end I just left the domain and stayed as part of a workgroup.

Previously we had the master image joined to the domain in an OU with no GPO applying. For some reason, leaving it as workgroup seems to be resolving the issue for us now. I don't know if this has happened due to a Windows Update that was processed into the master image, but it's quite strange as we didn't have the issue previously... or at least didn't appear to.

[Ray_handels]

Hey,

Sorry to break up an old ticket but we seem to have the exact same issue.

Have you ever found another solution than just removing the golden image out of the domain? And does this still work for you?

And if this is the way to go why wouldn't VMWare post that best practice is to leave the golden image out of the domain?