We enable this setting in kaseya "Disable - Disable Windows Automatic Update to let patch management control system patching."
however it seems that a lot of windows 10 computers still are auto updating. Is there something else i should be doing so patches are only managed by kaseya and not scheduled locally on the computer?
I know you prevent the user from manually running an update but i'd like to at least prevent the computer from updating on its own so i can manage it through kaseya.
if that is checked it should stop them from auto updateing the next time they check in. what are your settings in automatic update
We set automatic update to a weekly schedule.
I just found this in kaseya's help documentation and i think it explains it.
We (the business I am part of) are still looking for a solution for this as well. As of right now, we are not aware of any way to control Win10 updates through Kaseya.
interesting we have that as well and our computers don't auto update unless we tell them to via kaseya or a manual push.
We are seeing the same behavior with Windows 10. I have contacted and had fairly lengthy tickets with Kaseya support on this as well.
The basics are Windows 10 is changing the way they are deploying patches. (my current understanding is) MS has three types -
1. Critical/Immediate release patches. These should be able to be controlled by Kaseya but I am not confident.
2. Monthly Roll-ups. Again, should be able to be controlled by Kaseya but I am not confident.
3. Feature releases - "Creators update." These cannot be controlled by Kaseya and are pushed by MS based on what release train you are on. Supposedly, there are methods to delay and change tracks based on domain settings, however, this does not always work given our mixed environments.
No more "Patch Tuesday"
Then there is the transition from Patch management to Software Management and we have these issues, plus more....like not being able to stop patches that have been superseded.
we were affected by this issue: Windows 10 Updates out of control even if managed by Kaseya Patch Management System. The only way to resolve is to STOP and DISABLE the two services responsible of Windows Update:
Windows Update Service (wuauserv)
So, this is how we manage patch with Kaseya:
1. Start an agent procedure that ENABLE and START wuauserv and bits
2. Start scan patch
3. Start Patch
4. (with POST procedure in Patch Management) start an agent procedure that STOP and DISABLE wuauserv and bits
So, out of "Window Patch", these services are always disabled and started only "on demand".
This is the only way to avoid that Windows Update process start without control.
How did you execute the agent procedure prior to the scan? Is there a way to schedule a pre and post-scan procedure?
I see you can do that for the automatic update but dont see it for the scan.
Ok... So here's my question for you SIES, How exactly are you accomplishing the above without resorting to doing it manually.
The patching part is easy, as you can use the pre and post patch procedures to do the start/enable and stop/disable of the services. However how do you do the patch scans? I've yet to come up with a way to automate running anything specifically around the patch scans.
We are actually seeing the *opposite* behaviour - Windows 10 build to build upgrades are not happening automatically.
We have configured Kaseya patch management to disable automatic updates, which effectively sets this registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate DWORD = 1
The only other setting I can see that could be related is that we have set the registry key designed to prevent the upgrade of Windows 7 / 8 / 8.1 to Windows 10. We have applied this via policy to *all* agents (i.e. including Windows 10) and it *appears* this may be effective in suppressing Windows 10 build to build upgrades from taking place.
I'd be very grateful if someone could verify what we're seeing as we have the opposite problem - we have hundreds of Windows 10 machines that need manual upgrading every year or so to avoid getting stuck on an unsupported build. Here's the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\DisableOSUpgrade DWORD = 1
Elliot Tabush Jonathan
The process is completely automated because we perform patch scans just before the patch process. We find useless to do patch scans every day if (in our scenario) the patch process happens just 1 day a week.
1. On Friday at 12AM starts agent procedures that start windows updates services
2. On Friday at 12.15AM starts the scan patch process with Software Management
3. On Friday at 12.45AM starts the patch process with Software Management. At the end of patch process starts "post patch agent procedure" that stops windows update services
Hope it is more clear now.
Since Microsoft is forcing Upgrades at 18 months or claiming to stop Security/Critical updates if you do not: What are you doing to implement the Upgrades? Since 1607 the upgrade process requires a manual click of the "Upgrade and Restart" process. Simple restarts are no longer viable. Anybody care to share?
Most recently we've been leveraging powershell and the Windows Update API to tackle this, results so far have been fairly successful. The reason we're using the Windows Update API is to take advantage of BITS and (hopefully in the future) WUDO to save on bandwidth and avoid pushing large files around manually.
Once the feature upgrade downloads and 'installs' what's happening under the hood is that the upgraded Windows + Program files etc is staged under C:\$WINDOWS.~BT and as you've identified a simple restart won't complete the process. The trick is to finalise the upgrade which I've found you can do via:
C:\$WINDOWS.~BT\Sources\SetupHost.exe /finalize /update
This restarts the system and completes the upgrade process (renames Windows to Windows.old, places the staged Windows from C:\$WINDOWS.~BT into C:\Windows and a whole lot more).
Alternatively there are lots of blog posts about performing upgrades via the upgrade assistant or from the media e.g. joshheffner.com/automate-windows-10-in-place-upgrades-from-the-command-line
Thanks for the Reboot script Combo - It has been working great! "Most recently we've been leveraging powershell and the Windows Update API to tackle this," would you be willing to share the PS script?
OK I'll share, but on the proviso that anyone who can improve on it please share with the community so we can all benefit :)
The gotchas I've found with it (so far):
1. It leverages powershell to call WUA which makes Kaseya's subsequent patch scans fail (known Kaseya bug if *anything* except Kaseya and WU leverages WUA). To address this we're clearing the softwaredistribution folder out after the upgrade has completed per Kaseya's recommendation.
2. We've regularly found it reports the download as 'complete' when it's not, hence staging fails. Again we've taken to clearing the softwaredistribution folder out first (i.e. before running this powershell) and even then we've found until it attempts to stage the upgrade it won't 'recognise' that the download didn't complete - once it fails a subsequent download succeeds. The second download attempt logic is in the powershell. The downside of clearing softwaredistribution beforehand is it won't use WUDO and instead downloads the full media over the internet. I'm hopeful this is a temporary issue and future upgrades won't run into this.
Here's the code:
$FeatureUpdate = 'Feature update to Windows 10, version 1709'