How stealthy patches could bring down all of Windows 10
I've been waiting, patiently, hoping that Microsoft would either clarify or contradict that statement. (Actually, I was assuming that someone with a "We listen to customers" pin on their hoodie would take notice and start screaming.) Alas, at this point, that appears to be Microsoft's final say.
It's too bad, really. With the exception of unexplained monitoring (detailed meticulously by Peter Bright at Ars Technica) and the inability to block patches, Windows 10 seems to be evolving as a genuinely user-friendly product. While Win10 doesn't work right for everybody yet, and we'll undoubtedly see discarded mounds of Cumulative Updates before things stabilize, it's been obvious from the first Insider Preview that we're working with a new regime, and a newer, much more open environment.
Then we get a ringer like this new policy statement, tucked away in a Register blog.
I was reminded of a comment posted last week on my blog about the new face of Service Packs. RCW2345 writes:
What RCW2345 writes is, in large part, true: It wouldn't be informative if the folks writing the Win10 patches told us they're "tweaking the RV2 control block so that it stays aligned with TCB12." (He's right about ignorance, too, at least in my case.) What we need is a simple, definitive statement as to what each Cumulative Update is doing -- or trying to do. That's what we've had in the past, in the Knowledge Base articles, give or take a standard deviation or two. Why will the descriptions disappear in Windows 10
I could cite a hundred examples – big and small -- over the past few years, where brief descriptions in patch KB articles have helped people nail problems in Microsoft patches.
Here's a simple example. On May 12 of this year, Microsoft released two font driver patches, KB 3057110 and KB 3045171. Shortly afterward, many people reported that their machines wouldn't work right with certain font packages. Golden Software, in particular, heard the scream for help and isolated the problem to these two patches. By May 13, they had posted warnings on their website, telling customers to uninstall KB 3057110 and KB 3045171. Uninstall the security patches, and the problems went away.
A week later, Microsoft updated its Knowledge Base article, admitting to the error. On May 21, Microsoft released a fix. The fact that Microsoft told us that KB 3057110 worked with fonts helped the folks at Golden Software to narrow down the possible sources of problems. Customers benefited because Microsoft described the patch beforehand; it took Microsoft nine days to fix it, but those closer to the customers got a workaround out quickly.
If Microsoft hadn't notified us that the font handler changed (and if the problems hadn't appeared on a Patch Tuesday), Golden Software would've had a much harder time figuring out what went wrong. Zeroing in on a fix would've been even more difficult.
I could recite a dozen more examples from this year -- KB 3087916 (spurious "An ActionScript error has occurred" in IE11), KB 3022345 (the sfc /scannow "file corruption" error fixed last week in KB 3080149), KB 3037580 (Security Patching pools stopped), KB 3002657 and KB 3033929 (Cisco AnyConnect VPN broken), and so on. In each of those cases, the presence of a simple description attached to a patch number made it much easier to track down which patch was causing the problem and get fix advice out to customers.
Imagine if all of those had been bundled with miscellaneous patches and feature updates in another undescribed Cumulative Update. Those adept enough to use the Win10 patch uninstaller KB 3073930 (which has its own problems) might be able to negate the effects of a bad patch -- drive a wooden stake through its heart, as it were -- but if we don't have descriptions of the patches and they come out in one undifferentiated mess, mitigating Microsoft's mistakes won't be easy.
That's a problem for individual users. But it's even worse for admins. I can't envision how it's supposed to work.
Security patches, presumably, go out to everybody, in all branches, simultaneously. It then gets pushed onto all Windows 10 Home machines, and all Windows 10 Pro machines that aren't attached to an update server. There's no description of the security patch -- at least that's the implication of the Register's article. It goes into the Windows Update for Business hopper and/or the Windows Server Update Services queue. Admins, apparently, have to test the patch for deployment without a description of what it's supposed to do.
I don't get it.
About a year ago, Microsoft started dismantling its patching Advance Notification Service, ANS. The official announcement said:
And, of course, when the Security Bulletins have no content, organizations that can't afford Premiere Support get cut back to nothing. Zip.
Windows patching guru Susan Bradley has posted a feature suggestion on Microsoft's User Voice blog. Her observation:
I would only add that Windows cognoscenti -- not only admins -- are getting punched in the gut, as are tech support crews, both hardware and software, which have to work with Microsoft patches. So are family tech gurus, office Windows experts, and nearly about everyone beyond the "I give up, sock it to me Microsoft" class of Windows 10 users.
Will admins stand up in force and refuse to work with Windows 10, until Microsoft opens up a bit Hard to say, but one thing's for sure: Secrecy in patching doesn't work any better than secrecy in development.
And if a company's admins refuse to support Windows 10, where does that leave Microsoft
Do yourself a favor. Hop over to the User Voice blog and vote for "coherent KB articles for Windows 10 updates and not rambling lists of files that were changed."