/ microsoft

Already Breaking a Promise?

So Windows 10 went live a few days ago - telemetry is showing a VERY high success rate in updates with over 60 million PCs upgraded. This is good! There are a few (noisy) exceptions: I myself got the dreaded "Something Happened" error on PC #12. But, as a source informed me, less than 1% error rates is REALLY good. Now, businesses are starting to pay attention - actually it'd be great if they would pay more attention but that's another blog :) But now there is scuttle about Microsoft breaking application compatibility promises.

"If it runs on 7, it runs on 10." Period. This isn't just the apps like Office and Adobe that you open all the time - it's the OS itself. After all, one of the main things I've been talking about is that if EVERYONE runs the exact same code, then application compatibility will be easier. Enormous advocacy is in flight around the servicing model for Windows 10:

Servicing Chain

By the time an update gets to the businesses running Windows 10, some "hundreds of MEEEELION" PCs should have validated that all is well. That's why MSFT says that if you are in an enterprise deployment, and 95% of all enterprise deployments should be in Current Branch for Business (CBfB), you can only delay a patch twice then you have to take it. In doing all of the above, MSFT, in theory, can say: we guarantee a patch won't break anything.

Then this happened:

This is bad

Windows has been RTM for six days now, and a patch has already been released that broke systems. The above patch, a faulty driver, regressed an earlier issue that basically caused touch screens to highlight words instead of register tactile touching. So what happened? Did MSFT break a promise?


Two things are at play here:

  1. This is a driver. Drivers are released via Update Services just like patches but these are not bits that came from MSFT. Splitting hairs? Probably, but it is the responsibility of BOTH Microsoft and the vendor to make sure regressions don't happen. Everyone relax - it's day six of a brand new world and they've got some kinks to work out.
  2. Remember the patch chain above? Before a patch makes it to businesses, "Hundreds of Millions of Users" will have tested a patch. Guess what? It isn't there yet! Hundreds of millions of people have yet to deploy Windows 10. 60 million is pretty good though! But guess what else? Just because MSFT says that all PCs (95% of them) should be on Current Branch for Business so they get patches quickly does NOT mean you are absolved from testing said patches in your enterprise. I posit the following:

When a patch is released to CBfB, it is incumbent upon all organizations to deploy the patch into their labs before releasing them to their general population. Sound familiar? It should - because MSFT says that organizations should deploy Windows 10 to labs first to test application compatibility. Those labs should NOT then be torn down. As most organizations have typically done, you still should test ALL patches (even though there are now far fewer) in your lab before releasing them. That way, if an issue does happen, call 1-800-MICROSOFT and tell them that something is up and they will help fix it - BEFORE you roll something bad out to your general population.

Bottom line? It's a whole new world for servicing. The offending driver above? Yep, that's bad. But here's the great thing - it was caught in Consumer branch before it landed with organizations in CBfB. The process worked. And it will work even better when hundreds of millions of PCs are field testing compatibility before a patch lands in the enterprise. And the ISVs get their drivers together. And enterprises get their labs deployed. Etc. :)