• Patch Lady – no it’s not WSUS’s fault

    I saw this email come into my inbox blaming the forced upgrades to feature updates on WSUS.

    The email said:

    “For the third time in the last few months, Microsoft pushed updates to Win10 machines that had deferral preferences set. Windows 10 versions 1507, 1511, 1607, and 1703 have been affected and pushed to 1709, whether a user wanted it or not.

    Microsoft’s response to this invasive error? Just try rolling the update back – oh, and good luck with that.

    It’s time to accept that WSUS can’t be trusted to automate patching. With major downsides like no third-party updates and a complex user interface, WSUS has now struck out with this latest failing. It’s time for a better way to manage updates.”

    I disagree with this email. Actually WSUS was not at fault, it was a combination of Windows update for business group policy settings, dual scan bugs and … flat out bugs in the Windows update deferrals and detection that was the culprit here. If one has Windows Software Update Services and does not approve the feature release it doesn’t get installed. In fact WSUS is quite honestly not the greatest way to install the feature releases. It works fine to service them however. I don’t use WSUS in fact to deploy feature releases, I use a script to install the feature release when I want to.

    There are, however a few key things to keep in mind when using WSUS to patch on the back end:

    1. In your group policy settings do not use “No auto-restart with logged on users for scheduled automatic updates installations”. In my experience this has faulty detection and will often see some background task as “you” being online and thus not rebooting the machine when you want it to.
    2. Do use “Always automatically restart at the scheduled time”
    3. Use group policy to set active hours based on your needs.
    4. MAKE SURE you have the policy set “Do not allow update deferral policies to cause scans against Windows Update”. This was introduced a few months ago and fixed an annoying bug in Windows that allowed workstations to bypass the group policy patching settings you had in place and instead find updates from Windows update directly. It’s this “bug” that was causing some to believe that WSUS was failing in blocking updates.
    5. Do set up a separate Windows 10 WMI filtering for the group policies you set for automatic updates for Windows 10. I’ve found that you can’t piggy back the 10 patching on top of your 7 group policies.

    As we’re getting ready for the release of 1803, may I just say that I really really do want everyone on 1803. There are some really good and cool features in it (including one to throttle the bandwidth that updates use). [You can see some of the cool features in a Zdnet slide show] But I really really really don’t want you to get it on day one, nor on a day that Microsoft thinks you want it, because I’ve never seen the Microsoft update process get that right. I want you to have a backup of your system, and feel comfortable in the patching health of your system before it occurs (more on that in an upcoming blog post).

    So make sure you follow Woody’s advice to push it off to an appropriate time when you want it. I will disagree with Woody about that there’s no warning when they shift a release from semi-annual targeted (what used to be named current release) to semi-annual broad (the old current branch for business). There is one, but it’s typically buried in a blog post that only us slightly insane patch ladies follow and thus it’s easy to miss when they do it. They also will be doing what they did before where they “throttle” the update and evaluate the systems and offer it up to ones they deem ready for the update.

    Bottom line get ready for 1803.