Jump to content
Welcome to our new Citrix community!
  • 0

Windows 10 Ver. 1809 - Managing Windows Update/Windows Update Medic Service/Update Orchestrator Service

Matt Ford


Is there a proven method to disable these services since Microsoft has loaded Win 10 with multiple watchdogs to ensure this service is set to Manual (and running) in most cases?  We've disabled the services via the registry as well as any scheduled tasks associated with them and the services still turn on when we recompose the desktop pools with the published images.  We've even been able to observe the services turning back on after configuring this in a version of the OS layer and rebooting.  The scheduled tasks get recreated and shortly after they turn all of the services back on.  I'm at the brink of breaking the permissions on the folders that the scheduled tasks reside in with takeown/icacls commands but that seems really extreme for something that was so simple prior to ver. 1803.


Interested in others accounts of how they've addressed this issue - are you even configuring anything to disable the local services or going with the local GPO approach as mentioned in this article - https://support.citrix.com/article/CTX221769?  That was last updated March 2017 which predates the introduction of these services so that's what makes me believe there's more do than just that, but maybe I'm wrong.  If GPO is the preferred approach it still seems like it could potentially poison and/or bloat application/user layers and introduce inconsistency with unnecessary NGEN tasks running and whatever else it does behind the scenes since Windows 10 downloads and pre-stages the updates before applying them.


Additional details if it helps -

* VMWare Horizon 7.6, nonpersistent desktops

* Win 10 ver 1809 utilizing elastic app layers and user layers.

* Since we experience this issue during an edit of the OS layer so we're confident domain GPO's aren't influencing this behavior.



Any advice would be appreciated.

Link to comment

3 answers to this question

Recommended Posts

  • 0

We experienced the same thing with 1607, even with a configured WSUS environment. It would find its way back to MS to start installing updates. My desktop engineering team has said they have that resolved on 1709 and 1809, but I've yet to 'test' that theory. We have resorted to changing the respective services to use the Guest or LocalGuest account so they have no permission to run even if a task changes them to automatic from disabled.

Link to comment
  • 0

I've had no issues keeping Windows Update disabled in our images in our current 1709 image and our new 1809 image. I disable the WU service both in the OS Layer (manually disabling it; not via local GPO), as well as in a domain GPO. I don't think they exist anymore, but there were some random scheduled tasks in 1709 that used to change that behavior, which I disable in VMware OSOT in my Platform layer. These tasks were all in the Microsoft\Windows\rempl folder in Scheduled Tasks, and all were deleted. While I'm deleting a number of other tasks, I don't think any of them are known to turn on WU.


We do set the following registry key in our Platform layer:


Key: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

Value: NoAutoUpdate

Data: 1

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...