[German]In today's blog post, I'll summarize two things that German blog reader Markus K. pointed out to me by mail. Possibly there are changes in driver updates via WSUS, at least there are and ambiguities. Once he suddenly appears on Dell systems password prompts to clients when a firmware is to be installed. But there are other oddities, such as missing reloading of drivers after an activation. And then there is the suspicion that Windows 10 gets the updates directly past WSUS, from the Microsoft update servers, no matter what the administrator has set in group policies.
Advertising
Unclear issues during driver updates via WSUS
Blog reader Markus manages driver and firmware updates in his environment via WSUS. If you want to update several hundred to thousand Windows clients centrally (e.g. via WSUS) with firmware updates, you don't need sudden BIOS queries for passwords. However, this is exactly what happened to Markus in his environment. Also, drivers should actually be installed automatically after a Windows 10 installation. In an email to me a few days ago, he described some oddities that plague him there:
I'm sorry to bring up the blog article Windows 10: Changes and strange behavior with driver updates via WSUS. Just in a nutshell, strange things happens:
- e.g. the 5 MB HP Inc. – Firmware – 2.53.0.0 update ends in a password prompt on the computer, which is probably rather impractical with a few thousand pieces (I go [not] times quickly to the computer). This seems to affect HP and Dell systems in particular, since we haven't seen such a behavior on Lenovo yet.
- until a while ago Windows also reloaded all drivers after activation, this doesn't happen anymore! (was probably on it because of the optional updates simply forgotten)
- at least under [Windows 10] 20H2 does "usoclient.exe StartScan" in the GUI and probably system-wide nothing more
I just want to quickly sketch the picture: If a university in lecture halls and PC rooms stands still, because one is asked for the BIOS password after a driver update. Well thought out looks different. It may be that this is great for "home", but in the company? At the moment, I'm not aware that you can control the behavior, but I'm happy to learn more.
He then wrote in his next mail that delivering the computers without a BIOS password is not an option in his environment. He states that a firmware update for the mentioned Dell and HP systems is to blame for this behavior, because rolling out firmware updates seems to work at Lenovo, while administrators are allowed to make a pilgrimage to the machine at Dell/HP. To this he wrote:
We can currently only "workaround" this for a few models by proactively updating the BIOS. However, this way is not a permanent solution, since new updates will surely come. On the other hand, you don't need to worry about the "Printernightmare" in such cases…
Apparently Dell and HP have improved. While writing this text, a third mail arrived:
With newer Bios versions you don't get stuck with a password request (prompt) anymore. Apparently the problem has been solved. It's just a small consolation when hundreds of computers can't boot anymore. The firmware also seems to be delivered with Windows 10 version 20H2 (I can't say anything about Windows 10 version 2004).
Are Windows 10 updates bypassing WSUS?
As part of the recent updates, Markus ran into some problems in his environment because his Windows 10 version 20H2 clients suddenly pulled updates even though they weren't approved for them in WSUS. Here is his story on this – perhaps someone has observed this as well. Markus writes in an initial email.
I'm a bit speechless right now, so just a screenshot from WSUS where KB5004945 lands on machines without approve:
Windows 10 updates without WSUS approval, click to enlarge
Advertising
In a follow-up email, besides the comment that first reports about printing problems after the PrintNightmare updates are coming in, then came the clarification regarding the Windows 10 version 20H2- clients.
I even checked again if "Do not allow update deferral policies to cause scans against Windows Update. " is set and yes, it is set. Even the access to manually check for updates is disabled:
I have the assumption that when upgrading from 1909 to 20H2, the last dynamic update from 21.06 (KB5003716) is reloaded. So the clients could have come to a state, which one has not released at all. If this is the case, it would be another classic case of "not thought about, badly done".
Later Markus suspected that the error was his and wrote:
The error was probably really mine, because apparently KB5003716 slipped through. After release all 1909 have got themselves this DU and have landed thus on state 21 June. Conclusion everything best double check and be careful. Sorry for the false alarm.
But was probably not a false alarm, because another mail says the following:
Unfortunately it was not your own fault! The clients should get the latest DU (dynamic update) directly from Microsoft.
To what one has the stuff then at the WSUS I ask myself. However, I find it unattractive, when clients come along with an unreleased CU via DUs. At least I now know about the circumstance and the fact that Microsoft does not care about WSUS.
I just posted it here unedited. Question: Are there similar experiences/observations from other admins?
