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:
We are running the following:
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?
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.
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
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...
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:
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.
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.
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?