Newsletter Archives

  • Wrapping up July’s updates


    Susan Bradley

    By Susan Bradley

    We’re at the dividing line. We are working on getting July’s updates installed and reviewing whether we have Windows 10 22H2 installed. Meanwhile, that window of opportunity for installing updates is closing soon.

    But that’s just the Windows side of the patching world. On the Apple side, we’ve had to deal with zero-day patches this month. Not to be left out, Android is doing last-minute beta testing on Android 14 beta 4.1.

    Read the full story in our Plus Newsletter (20.32.0, 2023-08-07).

  • Firmware and drivers


    Susan Bradley

    By Susan Bradley

    Why are drivers and firmware so important?

    Once upon a time, you would set up a computer and any display adapter driver or firmware would be automatically installed to match the hardware. More than likely, you would not install new drivers for a long, long time.

    But now with both Windows 10 and 11, I annually review drivers and firmware as the Windows feature releases come out. I go through certain steps and processes to rule out issues that might have been triggered by out-of-date drivers, especially if I’ve encountered side effects that I can’t otherwise explain.

    Read the full story in our Plus Newsletter (20.14.0, 2023-04-03).

  • Patch Lady – if you use WSUS can I get your feedback?

    The first ever unofficial survey on Microsoft’s on premise patching tool called WSUS.

    If you use the platform, can you fill out my unofficial survey please?  I will be sharing the results in a few weeks.

  • Is WSUS a dead horse?

    A friend of mine wants to know:

    Does anyone still use WSUS in corporate environment or is it a dead horse?

    The reason why he’s asking — there’s an article on the old WSUS Product Team Blog, dated March 2, 2018, that talks about WSUS failing to import updates. He says the problem’s still there, and MS isn’t giving him anything but crickets.

    Those of you who do (or did) use WSUS — are you seeing the same problem, or similar problems? Do you figure WSUS is all but dead, or is there life left in the tired old horse?

  • More WSUS Sync failures

    Those of you working on update servers over the weekend have my sympathy.

    There’s a lot of confusion over last Thursday’s KB 4458469 cumulative update for Win10 1803, KB 4457136 for 1709, KB 4457141 for 1703, and KB 4457127 for 1607. As best I can tell, all of those patches have been pulled — except they’re still in the Update Catalog.

    To add to the mayhem, we have this report from @nazzy:

    Getting intermittent sync failures again starting 9/17 for both scheduled AND manual syncs.  Can anyone else confirm?

    and from an anonymous poster:

    I can confirm that It was working up until 9/21/2018 then all day today (22 Sept) fails WSUS sync

    Of course, a big chunk of Microsoft staff is in Orlando, getting ready for Ignite. Are we going to see any sort of resolution on this in the near term?

    Great way to treat your corporate customers….

  • The unholy mess that has emerged from Win10 WSUS Dual Scan

    Those of you who just go about your business with Windows don’t need to worry. But the folks who are in charge of Windows Update servers should be conversant with the, uh, nuances of a feature called Dual Scan.

    Dual Scan first came to my attention back in July last year when Win10 1607 machines with “Defer feature updates” set were suddenly getting pushed onto 1703. As I said back then:

    one of the warnings I found surprising goes like this: If you have “Defer feature updates” checked on your machines, that setting triggers a dual-scan mode, where those machines will look for updates both through WSUS and directly through Windows Update — even if they are behind WSUS.

    which, to me, was a bit of dirty pool. Dirty almost-undocumented pool.

    Last Friday, we got a whole bunch of documentation in a Technet article called Windows 10 Updates and Store GPO behavior with DualScan disabled and SCCM SUP/WSUS managed. If you think that’s a mouthful, take a look at the chart that clarifies what’s up with the GPOs surrounding updates on machines that are attached to an update server.

    Do you think they could make this a bit more complicated?

    Just asking for a friend….

  • 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.

  • KB 4025331 for Server 2012 and KB 4025336 for Server 2012 R2 breaking WSUS and SCCM

    Summary from Günter Born on his BornCity blog.

    • KB 4025336 blocks the client’s connection to WSUS

    • After installing KB 4025331, no more Office and Windows updates could be installed from clients via SCCM.

    In both cases, uninstalling the updates solves the problems.

  • WSUS servers fails to synchronize with the Microsoft servers

    From PerthMike.

    Workaround is to untick the UPGRADES category. Could be the Creator’s Update/Upgrade causing havoc.

    But Microsoft recommends against turning off upgrades “since that will expire all of the upgrades in SCCM environments until the upgrades classification is rechecked and resynced.”

    There’s a significant discussion on . Call me old fashioned, but I don’t replicate patchmanagement posts because of a warning “The content on the email list is intended for assisting administrators.  If you would like to use any of this content in a blog or media publication, please contact the owners of the list for approval.”

    I’m also seeing reports that managed Win7 machines are rebooting twice after this month’s patches.

    Wait, folks. Thar be tygers here….

  • Two WSUS offline update related questions

    Thanks to ch100, who pointed out that WSUS Offline Update is a third-party tool that has nothing to do with WSUS. I’ve moved the questions and answers to a comment, attached to this message. While my quick reading led me to believe the posters were talking about WSUS, in fact they were talking about a product that has nothing to do with WSUS.

    My bad. Sorry.

  • Microsoft offers the final (?) word on ESD for WSUS, take 3: KB 3159706 replaces botched KB 3148812

    But will it work?

    Server 2012 R2 propped up.

    InfoWorld Woody on Windows

  • WSUS on Windows Server 2012 R2 appears to be badly broken

    Left hand, meet right hand.

    Thanks to Cliff Hogan, who’s awake while we all sleep.

    InfoWorld Woody on Windows

    UPDATE: Following on a tip from Rod Trent, over at WindowsITPro, Microsoft has reported on the issue and marked it closed:

    [Resolved] Service Restored
    (Started on 5/3/2016 8:53:00 PM UTC)
    5/4/2016 8:19:08 AM (UTC)
    Final Status: Engineers identified that the Intune service was unable to synchronize with recently deployed Microsoft updates. Engineers deployed a fix to the affected updates, which resolved the issue. User Impact: There was no end-user impact; impact was limited to administrators only. Affected administrators may have been not receiving recently published updates through Microsoft Update or Windows Update. Scope of Impact: Many customers appeared to be impacted by this event. For those customers affected, this issue potentially affected any administrator attempting to access or use the affected feature. No customer reports of the issue were identified during this event. Incident Start Time: Tuesday, May 3, 2016, at 9:53 PM UTC Incident End Time: Wednesday, May 4, 2016, at 7:45 AM UTC Preliminary Root Cause: An issue has occurred that prevented update synchronization. Please consider this service notification the final update on the event.
    I count that as a 10-hour WSUS disruption.
    It’d be interesting to know if the source of the problem was ESD encryption.