Anyone else noticing that after a Windows 10 computer upgrades to version 1803 you lose control to set Automatic Updates? The checkbox to select the endpoint isn't even there.
I am pretty sure this is because Windows no longer gives you the control/option to stop Windows updates.
Windows is pretty much going to install everything. You have little control now with the newer feature updates.
True, we've seen this before on earlier Windows builds as well. We've had completely identical machines, installed at the same time, where one will have the checkbox and the other won't.
Corey is right, Windows doesn't give you that amount of control anymore, at least not in the old way. So, I heard Kaseya will update the status on Windows 10 machines to show "Automatic Update not supported", meaning you can't set the 'Windows Auto Update' option, since it has no meaning in the old Patch Management module..
I've been told Software Management will get options to control Windows 10 better in the elusive Kaseya 9.6. And it's supposed to be possible to schedule Windows build updates from Kaseya, Since it's awfully quiet on this version I'm not sure if that really can be done, since Microsoft is keeping this control almost exclusively for their own software like WSUS. There are option to use, but not sure what Kaseya wants to do...
I think this is only partly true and Kaseya has seemingly used the confusion as an excuse to opt-out of controlling the settings. Perhaps it was too hard for them to implement checks to distinguish Windows 10 vs Windows 10 Pro/Enterprise.
The 'disable' setting available (sometimes) through Kaseya simply implements the registry key outlined here - support.microsoft.com/.../how-to-configure-automatic-updates-by-using-group-policy-or-registry-s - which according to the article (and my testing) still applies to the current builds of Windows 10 Pro/Enterprise.
Since Kaseya have 'given up' controlling this we scheduled a weekly script that sets the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate DWORD 1. Lo and behold the few 1709 and 1803 machines that were reporting the configuration as 'user control' are now showing 'disabled'.
As OudjesEric points out - the checkbox isn't even consistently shown or hidden for machines running the same builds, so who knows what they are trying to achieve there.
In terms of automation of feature updates (a.k.a. upgrades, like the upcoming 1809) - we have two procedures that can be scheduled and are generally successful. Probably the most reliable is the silent download and run of the 'Windows update assistant' but we also developed a procedure that uses powershell, leveraging the WUA API to stage and install the feature update. The whole regular upgrade requirement is still a bit of a pain and sometimes the procedures won't work for some machines but certainly the upgrade attempts can be both automated and scheduled, despite Kaseya not yet offering this capability.
Kaseya is planning for a release in 9.6 for build patches as well as the true disabling of update apparently (was just announced as a recent Kaseya mini-connect to us). But what Combo suggested is a good temporary solution which can be used with variables to disable / enable easily.
This looks like a good way to fix this permanently. I'm looking at creating the GPO to put the reg key in and maybe create the same procedure to update the reg key in case it changes. I'm not sure that we would need it to run weekly but I could definitely put it in to run after we do our scheduled updates. Or I can just schedule the GPUpdate procedure to run on a schedule.
I have created a procedure that sets that reg bit, stops the service, and runs a patch scan. That will at least disable the auto updates for now. Thank you for your help guys.
Keith Botelho can you share your procedure for this.. I can use this if you don't mind.. We are not an MSP too so if you want share it, please send me an email to email@example.com
Just keep in mind, that Windows will most likle restart Windows update service on its own. I have tried this before and found that to happen almost every time.
Thus far with the wuauserv service stopped it's stayed off for now. Of course that may change on the next patch cycle so I'm trying to tie all of the these together as a post-procedure run to re-set everything if needec.
I may be wrong but I believe the wuauserv service must be running for proper (online) patch scans to complete correctly, so disabling it isn't really a good option.
The reason we have scheduled the registry procedure weekly is that this setting is usually controlled via GPO and may not persist through OS upgrades (since it might be expected that group policy will take care of this). If you are only managing a few domains and everything is GPO controlled you shouldn't need to run or schedule the registry procedure - we don't have that luxury as a MSP so instead we take the conservative approach of regularly running the registry procedure to try to keep it compliant.
I was actually running a test to check for that but it looks like something started the service back up for the scan. I ran a Patch Status test on a test Win10 machine where I had disabled the wuauserv service and when I checked this morning it's showing the currently installed patches and the missing approved ones and the service is currently running. So maybe kicking off the scan turns on the service if it is off.
Kaseya doesn't do a patch scan with internal wizardry but uses the Windows Update service. So, the service needs to be started for Kaseya to be able to do a scan, that's been the way it is for years.
Kaseya is betting on Software Management to change that, 9.6 should be a big step forward, whenever it's going to come out. I'm not 100% sure that doesn't use the Windows Update service, but it seems a really good idea if Kaseya want's us to be in control. Just not sure if Microsoft will permit that in any way that is going to be reliable and current on all patches released.....