Windows Update. My favorite thing in the world when it comes to MCS machines. Recently a bunch of our MCS Non persistent Win10 VMs with Applayer have started to do this, and i cannot figure out why. Any pointers appreciated. "The start type of the Windows Update service was changed from disabled to demand start." "Windows Update started downloading an update." "Installation Started: Windows has started installing the following update: XenServer - SCSIAdapter - 9.1.6.58" "Windows Update started downloading an update." "Installation Started: Windows has started installing the following update: XenServer - System - 9.1.8.69" "Windows Update started downloading an update." "Installation Started: Windows has started installing the following update: XenServer - System - 9.1.10.83" At this point network stack on the VM go boom, and user gets disconnected. We have group polices to disable the windows update service, and they are being applied. We have group policies in place to stop windows updates applying driver level updates. We have Xenserver management set to not install drivers. Have registry keys set to block it for both Citrix Hypervisor and Xenserver flavors. What else outside of disabling the update service is required? One would think that is all we need to do but every reboot the damn thing wakes up and starts the process again.

That seems whacky given what policies you have in place, but I wonder if restricting the device installation for those hardware IDs would accomplish this? https://www.tenforums.com/tutorials/146562-prevent-windows-update-updating-specific-device-driver.html Heavy-handed approach, though.

Check Scheduled Tasks

Paul did you check your platform layer to make sure its disabled there using local policy. Of course we are supposed to set that policy wiht app lerying but i think that has been hit or miss if you dont set it yourself.

Thanks all for the responses. @Rob Zylowski I think so since we run a reseal script that sets WU to disabled along with a bunch of other tasks prior to finalizing and that script is SOP for all our layer tasks, but can certainly look. The wacky part is if i reboot an affected VM and then login with my own ID it does not replicate the issue, but if i hand it back to an affected user and they login, minutes later they have the problem. I strongly suspect it is something in the users Userlayer but whatever it is is not exposing itself as the culprit in the event logs.

hmm would eb interesting to test an affected user by renaming the user layer to see what happens wiht new one. Then you can give their old one back after the test

mind reader. Did that test and so far we are not seeing an issue. Well, other than annoyed developer having to rebuild their software stack.

Then you would think yhey could just reset disabling updates when they are logged in.

I don’t understand this reply. What I said was the test made clear the issue is with the userlayer since without it, no issue. I really don’t want to have to tell 20 users to suck it up and rebuild but not sure what else I can do.

Isnt the problem that windows update is running. Maybe it got enabled in the user layer so if they disable it again it should stop running.

The service is getting switched from disabled to demand start and then it runs, immediately pulling down driver updates. This despite the machine having policies designed to specifically stop that happening. I thought i knew how userlayers work, but are you telling me they can bypass group policy / registry settings on the master image?

Depends if you have issues applying group policy hut yes the user layer would override the master image settings and group policy should override all of that if and when it applies.

I changed the logon user for the up[date service to incorrect credentials. Havent had the issue since.