Late last week, Simon Sharwood at The Register dropped a bombshell. Where many of us had been fretting and complaining about the complete lack of information about Windows 10's four cumulative updates, Sharwood prompted an official response about stealthy patches from Microsoft, the first I've ever seen. Here's what a Microsoft spokesperson said:
As we have done in the past, we post KB articles relevant to most updates which we'll deliver with Windows as a service. Depending on the significance of the update and if it is bringing new functionality to Windows customers, we may choose to do additional promotion of new features as we deploy them.
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:
Fact is we never know in detail what any update to an OS does and that goes for Windows, Linux, OSX ... you name it. And it wouldn't be all that informative if the developers described in laborious detail exactly what code they changed and why. For one thing you don't know the code before it was changed. It's proprietary so how would it help if you knew MS had tweaked the RV2 control block so that it stays aligned with TCB12? … But can the "tech" media admit their total ignorance in this area? No, they need to write something. So they skim the surface (it's all they can do) and come to conclusion based on whether the kernel was changed in some totally unknown fashion or what they authors called the update.
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:
Moving forward, we will provide ANS information directly to Premier customers and current organizations involved in our security programs, and will no longer make this information broadly available through a blog post and Web page… For customers without a Premier support contract, we recommend taking advantage of myBulletins, which enables customers to tailor security bulletin information based on only those applications running in their environment.
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:
To many a sys admin, the current communication levels in the knowledge base articles that document the contents of the cumulative Windows 10 updates are not complete enough, and we cannot determine if a released update has fixed a bug that we noted. Instead we have to rely on the community word of mouth "Gee, did that fix that issue for you?" which is not a good way to handle communication or patch management.
It would be more appropriate to include information on what non security items were fixed in each release so we can assure ourselves that what bugs we are seeing are being resolved and we no longer need to report these issues. It will also be an enticement to install updates as we will know exactly what was fixed in each patch.
While consumers have less options to opt out of updates, Enterprises still have the ability with WSUS to fully control when updates get installed on machines. Thus having timely and actionable information from the vendor is key to getting patches installed quickly. If we have to rely on word of mouth reports of included fixes in patches and then wait for sufficient community affirmation of these resolutions, it will delay our installation of updates.
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."