I applied the Windows 8.1 update a few weeks ago and had some issues with my machine. Windows was fine, but I lost my SQL Server service. A few others, including some of the SQLServerCentral community also had issues, but their fixes didn't work for me. It was OK, because the problems gave me a chance to use PoSh to solve a real problem. I'll be blogging  about that in the next week.

However the 8.1 update has caused lots of issues, and Microsoft is acknowledging these problems. That's good, but the process gives me pause, and to a large extent, I think this makes more and more people suspect about all of Microsoft's patching processes. I bet there are companies that feel justified in waiting for SP1 for SQL Server 2014 before upgrading, even though there is a chance that the patch will cause problems itself.

This is one reason I've been hesitant to remain current with Cumulative Updates (CUs). Microsoft doesn't stand behind them, with the text on each CU page that users should only apply the patch if they are experiencing specific problems. Otherwise users are told to wait for the next Service Pack, which seem to be coming less and less.

Any patch can cause issues, and I certainly don't like the idea of automatic updates always being applied because if there are issues, they can become much more widespread than controlled updates. There is also the issue of vendor responsiveness. Microsoft has pushed out patches that caused issues, and while they've been responsive, I don't want to have all of my desktops, or all of my SQL Servers, down because of a bad patch.

I don't know how we patch in a more effective manner, but I do know that I want to have some control over updates as an end user, and I also want ways to remove patches. Moving to the app model of always applying patches over patches, and never rolling back seems to be a step in the wrong direction.