I understand and accept that Microsoft has changed patching in Windows 10, I expect that Microsoft will make these same changes to their other products including their new Server OS.
Microsoft has aggressively pushed Windows 10 in the consumer market by making it a free upgrade for both existing Windows 7 and Windows 8 machines and this has already reached many businesses that want the latest and greatest.
The majority of our in-house workstation have already been upgraded, I have requested that our customers don't upgrade yet as it prevents us from patching their machines, but we won't be able to hold the off for very long and it just a matter of time before it will cost us customers.
The question I have for Kaseya is what are you doing about it?
The missing patch functionality in Windows 10 is important to us can we expect to see a solution for this before it is to late?
One of our customer had problems with Win10 WU patching and rebooting without asking, like when the user let the workstation idle for a long time and there was even some data lost when it rebooted due to WU patching.
And they could not change the WU settings as Kaseya Patch Mgmt had Windows Automatic Update Configuration set to disabled.
Based on the content of the 9.2 webinar earlier in the week, it sounds like we will have Windows 10 patching support rolling out in the next few weeks.
HOWEVER, they way I understand it, Microsoft has removed the ability for applications to hold back patches. Kaseya will be able to push out all the KBs that you approve, but Kaseya cannot tell Windows "You shall apply no patches, unless I apply them manually." The end result is that you can approve patches, but Windows may decide to apply patches that you have denied. It sounds like this isn't Kaseya's fault, all 3rd party patching solutions will face this same issue due to Microsoft's change in policy.
In the webinars where it's been mentioned, Kaseya has stated that they are continuing to look for potential solutions, but I don't think there has been any traction in getting Microsoft to rethink this strategy.
Until there is a solution, it's fairly easy to block the Windows 10 upgrade.
<?xml version="1.0" encoding="UTF-8"?>
-<ScriptExport xmlns="www.kaseya.com/.../Scripting" xmlns:xsd="www.w3.org/.../XMLSchema" xmlns:xsi="www.w3.org/.../XMLSchema-instance">
-<Procedure treeFullPath="myProcedures - firstname.lastname@example.org.In Development" folderId="744659992700749" id="1826381144" treePres="3" name="System Configuration - Windows - Block Windows 10 Upgrade">
-<Statement name="SetRegistryValue" osType="Windows" continueOnFail="false">
<Parameter name="RegistryPath" value="HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\DisableOSUpgrade" xsi:type="StringParameter"/>
<Parameter name="Value" value="1" xsi:type="StringParameter"/>
<Parameter name="DataType" value="Integer" xsi:type="EnumParameter"/>
<Parameter name="RegistryPath" value="HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Gwx\DisableGwx" xsi:type="StringParameter"/>
Blocking Windows 10 upgrade is only a stopgap measure and does not completely prevent customers from upgrading their systems.
Being able to block/deny patches that have issues is a very important patch management feature.
Disabling Windows Updates is important to prevent Windows Updates and Kaseya Patch Management from clashing and in a large network can be very expensive long term if these Windows machines patch directly via the internet instead of the Patch Repository.
I don't have a solution to provide all I want to know is if there is a alternate plan for if Microsoft does not provide any solution that will work with the existing Patch Management module.
Simply put the last time we had an issue like this, the updated Windows Update Agent could not be deployed via Patch Management. We where told that this is a Microsoft issue and as far as I know it is still unresolved and no I'm not counting manually patching or running the workaround script as a proper solution.
I feel your pain, but I'm not really sure what you expect Kaseya to do about it. What would you like to see happen?
With Windows 10 cumulative updates are the 'new orange' - even using WSUS your options are to approve or deny big bunches of changes in a single KB update. www.computerworld.com/.../microsoft-cumulative-conjoined-windows-10-updates-are-here-to-stay.html. As far as I know Microsoft isn't providing standalone .MSU or .EXE files for most updates.
Fixing the patch scanning process shouldn't be that difficult - I really hope they at least get this sorted in 9.2. After that maybe it's just a matter of Kaseya 'unlocking' the Windows 10 native update process on Kaseya's Automatic Update schedule and letting the endpoint do it's thing, then locking it down again afterwards.
In short, Kaseya needs to add support for "Windows Update for Business". This means the ability to control the "ring" the machine subscribes to (fast or slow), the patch window hours and control the peer-to-peer patch source.
If Kaseya can't support this model as soon as details are released, then i'll just ignore the whole patch management module for Win10 machines, and build my own solution using scripts, powershell etc.
WUB is the new WSUS. However, details are still vague - can't find any documentation on it's registry settings API's, firewall rules, etc. as yet. Waiting (im)patiently for this info to be published. So far, it looks like reverse engineering the Windows 10 ADK will be required - see osddeployment.wordpress.com/.../getting-ready-to-deploy-windows-10-into-the-enterprise
After reading the "blogs.windows.com/.../" article that Craig Hart posted, I can see that I have to alter my expectation a bit as Microsoft does not want us to block specific patches any more;
... Selective updating at scale also creates customer-unique quality issues, since we rigorously test the platform as an integrated whole. Selective updating creates platform fragmentation for developers, which impedes innovation and creates quality problems with apps. And last but not least, selective updating is an expensive, thankless task for IT professionals. With Windows 10, we need a new approach for end-user devices at work...
Controlling where Windows 10 computers get their patches from and when they patch are still very important functions for Patch Management.
Correct me if I'm wrong, but you can do this:
I wrote that and applied it to all of my Windows agents (all versions). On Windows 8.1/2012 and below it prevents the endpoint from changing the windows update settings. On all versions of Windows (including 10) it stops Windows Update from checking for updates or applying updates unless you manually go to the update screen and click "Check for updates".
So none of the Windows 10 agents I'm monitoring are doing updates unless I'm manually doing them. I'm not sure if maybe I'm misunderstanding this situation, but I can confirm that my workstations in my office behave this way.
Eric, turning off windows updates is built into the VSA - go to Patch Management-> Windows Auto Update. No need for a script or to restart any services.
In any case, simply disabling all automatic patches (and patching manually) is NOT good patch management., therefore I don't think this is the answer.
Craig, the VSA does a similar job to what my procedure does. The procedure actually disallows the user to change their windows update settings, from the interface. Also this procedure allows the VSA to perform all patch management, rather than allowing the individual agents to patch themselves (this is the point of patch management after all).
My intention isn't at all to disable patches from being applied, it's to control when and which ones.
Also my reason for cycling the services is for auditing. If the services fail during the procedure I know there's an issue that will prevent an agent from being patched properly.
Sorry I didn't explain the whole procedure up front, I tend to have many plates spinning all at once when I write agent procedures (or any code really).
Eric, Kaseya's settings also disallow the user to change their settings and allows the VSA to manage all patching. I don't see any difference between your script and what Kaseya does natively (both just set the exact same registry keys).
The fact is, with Win10, setting these settings by either method simply leaves the win10 machine unpatched, unless you perform a 'hands on' manual patch run via the win10 UI.
In terms of responding to the OP - no there is basically no support for win10 patching in the VSA, other than the above mentioned ability to fully disable automatic-patching, and this is principally because of policy changes at Microsoft - something Kaseya doesn't have control over.
@Craig Hart If you read the start of my post you can see that I said that I understood and accepted fact that Microsoft changes is the cause of limited Windows 10 patching in Kaseya, there is absolutely no dispute in that fact.
What I'm trying to achieve here is community support in making sure that Kaseya will continue to look into finding a solution as the alternatives are simply too hard to sell.
Kaseya need to understand that this patch functionality (controlling when to patch and where to patch from) is critical to their customers' businesses.
HardKnoX sorry if I've strayed off-topic. I had hoped my first post about "Windows Update for Business" would be a starting point for further discussion.
I've since downloaded the Wino10 ADK and will be checking into the guts of group policies, in an attempt to script control of win10 updates.
FYI: VSA 9.2 (beta) seems to patch scan Win10 boxes successfully - it has picked up required office updates on test machines. I don't have a win10 box currently with OS level patches pending, so got to test that out but so far looking good in R9.2
The new Windows 10 release (1511) has some more Windows Update for Business bits to look into - technet.microsoft.com/.../mt577208(v=vs.85).aspx
They also list some keys to control Windows Update access - technet.microsoft.com/.../mt577208(v=vs.85).aspx
The article is based around the Enterprise / Education editions, though I suspect at least the 'delivery optimization' features extend to the Pro and Home editions. It would be great if Kaseya can start running with some of this stuff to see if they can integrate these controls into the VSA.
Fresh material on WUB - technet.microsoft.com/.../mt622729(v=vs.85).aspx - covering most of the relevant features (update source/delivery optimisation, deferring upgrades, deferring updates, pausing of updates)