What’s going on at Microsoft?

A few really bad Windows patches have recently dented users’ confidence in the software giant’s ability to deliver updates that actually fix problems instead of creating new ones, and that’s a serious perception issue that Microsoft needs to address urgently.
The most recent example - the KB3004394 patch pushed via Windows Update a few days ago - was quite a doozy.
Somehow, making Windows check for updates to root certificates daily instead of once a week (this is a good thing) meant drivers for Nvidia and AMD graphics cards couldn’t be installed, the Windows Defender anti-malware solution didn’t start and the User Access Control feature went haywire.
On affected machines, KB3004394 even stopped further Windows Updates from installing. To fix that, Microsoft had to release a patch for the KB3004394 patch and ask users to manually install it.
You have to wonder what testing - if any - Microsoft did for the patch on Windows 7 Service Pack 1 and Windows Server 2008 R2SP1. It’s simply inexcusable for so many problems to have occurred, costing users time, money and agony to fix.
It’s not the first troublesome patch, either. There have been others that, in some cases, have actually killed users’ systems.
It’s a critical problem for Microsoft to address because much is at stake. Already some commentators are suggesting users should turn off automatic updates for Windows, and even going so far as calling the recent faulty patch "malware or badware".
That’s understandable given how much pain the bad patch caused, but turning off auto updates is bad advice.
Unless you fully understand what a patch does - and you most likely won’t - trying to figure out whether or not to manually install an update is not a sensible policy.
If you can test the patches on sacrificial systems with the hardware configurations deployed in your organisation, sure, do that. But keep in mind it may mean your users are vulnerable to exploits while the patch is being evaluated.
I don’t need to tell seasoned sysadmins how much additional headache an unplugged security hole can cause.
For mobile users out of reach of management systems and small to medium sized organisations without dedicated IT staff, turning off Windows Update is just not a clever thing to do.
In fairness, the window (no pun intended) for Microsoft to diagnose a flaw or bug, develop a patch, test it and to deploy an update has reduced massively over the past few years.
Attackers are more motivated than ever to discover security holes to exploit, as it's big business for them. There’s lots of pressure on Microsoft to issue patches sooner rather than later. Clearly, in some cases, the testing tools and procedures can’t keep up with the frenetic pace.
Furthermore, Microsoft also has to support multiple platforms, which adds time and complexity for developing and testing patches, with unexpected results: the same patch that caused problems with Windows 7 and Windows Server 2008 R2 Service Pack 1 worked just fine on Windows 8, 8.1, RT 8.1, Windows Server 2012 and Server 2012 R2.
This is unlike Apple, as an example, which quite calmly kills off older versions of OS X and iOS, and tells users they’re on their own if they continue to run those operating systems.
While patching Windows systems may at times be an inadvertent game of Russian Roulette, it’s still best to get the patches early and automatically in the vast majority of user scenarios.
Kvetch to Microsoft when things go wrong, and back up often and, ideally, before patching.
Things can and do go wrong occasionally, but in the grand scheme of things, that’s preferable to delaying applying fixes.
Ironically enough, I’m writing these last few lines on a spare system after applying an OS X patch which screwed up the networking on my main system. I'm still going to leave the automatic updates on though.
And now to fix that box.