Help! GPOs Stop Working After gpupdate /force in AVD Environment
Asked by
TechWhiz42
I'm facing some strange issues with Group Policy Objects (GPOs) in our Azure Virtual Desktop (AVD) environment, which is using Windows 11 multi-session. The session hosts are domain joined, and we're relying on GPOs for various settings. Here's what's happening:
1. Users log in normally, and at first, the GPOs apply just fine.
2. However, when some users encounter issues that appear unrelated, a tech on our helpdesk runs "gpupdate /force" in hopes of troubleshooting. This action requires a logoff to apply the changes.
3. After they log back in, several user settings fail to apply—missing desktop shortcuts, un-mapped drives, and unchanged background images. The Event Viewer throws errors like "0x80070003 - The system cannot find the path specified."
4. If users rerun "gpupdate /force" and skip the logoff prompt, the GPOs seem to work correctly, though some users report that missing items eventually show up on their own.
5. However, logging off and back in brings back the original issues.
We've tried various solutions:
- Clearing the local Group Policy Cache.
- Rebuilding the GPO from scratch.
- Enabling logging for more insights (but it mostly just confirms the path errors).
The only workaround that seems to work is logging off users, deleting their FSLogix profile VHDX, and starting anew, but this shouldn't be necessary after using "gpupdate /force". Has anyone else dealt with this kind of GPO issue?
Answers
That actually makes a ton of sense! The registry adjustment worked for us too. After we set "GroupPolicyState" to "0", GPOs started applying as they should—even after running a gpupdate.
Reply to this answer
It sounds like there might be an issue with the permissions or delegation settings on your GPOs. Ensure that your permissions allow "Domain Computers" to read machine GPOs and "Authenticated Users" to read user GPOs. You should check the Delegation tab for accurate settings.
Reply to this answer
Hey there! How many Domain Controllers do you have in your setup? And is your DNS configured properly? Make sure you can access netlogon without any issues from the affected machines.
CuriousUser101: We've got 3 DCs—1 in Azure and 2 on-prem. DNS seems correct. I accessed netlogon and sysvol from all 3 DCs without a hitch.
Reply to this answer
Looks like you may have stumbled onto the real problem! FSLogix's Group Policy caching behavior might be what's causing the mess. According to this Reddit post, adjusting a specific registry setting for FSLogix could help. Create a DWORD value named "GroupPolicyState" and set it to "0". This should help with synchronous policy processing at sign-in and fix the GPO application after a gpupdate.
Reply to this answer
Add your answer
Answers are reviewed before publication.
FSLogixFanatic: That's interesting. I thought the GPO would be consistently broken if there were a permissions issue. Seems odd that it only fails after a gpupdate.
CuriousUser101: I’ll look into that. But as you said, it works just fine initially—only breaks post-gpupdate.