Now that we have had a chance to digest the ramifications of the new cumulative update strategy for Exchange 2013 as laid out by Microsoft, it’s a good time to speculate how things will work in a practical sense.
Three points deserve some debate. The first is the cadence for updates. Three months is an eminently sensible period for “the service” (the name Microsoft uses for Office 365). The nature of cloud services and the competitive imperative to stay fresh means that new features “light up” on a frequent basis. I have no problem with Exchange Online and the other Office 365 products being updated every thirteen weeks, but I wonder whether the IT staff responsible for running on-premises Exchange servers will be quite so happy to be forced to maintain the same pace. After all, no other company has the same technical resources as Microsoft, and no other company has invested so heavily in standardization and automation within their datacenters, two of the basic principles that facilitate frequent updates.
Having a new cumulative update delivered every three months is unlikely to be welcomed. Being forced to update because the support policy dictates that only the two most recent updates are covered. The exact text in Microsoft’s statement is “A CU will be supported for a period of three (3) months after the release date of the next CU”. Three plus three equals a short six month period during which you had better deploy if you don’t want to be met with the stock answer of “deploy the current update” anytime you report a problem to Microsoft support.
So that’s two out of three issues that are pressing on my mind. The last is the effect that the new Microsoft-dictated schedule will have on ISVs. Exchange is not an island and few Exchange servers function without some form of non-Microsoft software that helps to keep the show running. Simple stuff like backup software, for instance. System administrators tend to like ISVs to verify their code against shipping software, which means that ISVs can only really begin to validate their products after Microsoft has shipped a new cumulative update. Of course, the magical mystery three-month clock has started at that point and you can bet your bottom dollar (or currency of choice) that it will take ISVs at least a couple of weeks before they make absolutely sure that their code runs well with Exchange 2013 CUx. So now we have maybe ten weeks to deploy, maybe less if one of the ISVs runs into some trouble with an API or other component. In short, it’s a bit of a mess.
The other thing to remember is that no one signed up for a frenetic update schedule when they committed to buy and install Exchange. No one. No customer. No ISV. No partner. No one. Microsoft has taken it upon themselves to impose a schedule that makes perfect sense for their Office 365 service while leaving everyone else gasping on the ground. It must be a new way of generating customer loyalty through exertion. You know… “the more software installs you do, the happier you’ll be with Exchange”.
Don’t get me wrong. There are some good things in Microsoft’s new update strategy such as the ability to deploy the latest CU in a one-time operation to install Exchange rather than having to deploy the latest service pack and then the latest update as happens with Exchange 2010. But the pain caused by the three-month cadence is too much and I think that Microsoft has to figure out a better approach.
No one will object if they continue to light up new features for Exchange Online every three months – but that’s a highly optimized and standardized massively scalable multi-tenant environment that is unique and totally unlike any customer on-premises infrastructure. You cannot fit a square peg into a round hole and you can’t force unnatural update practices onto Exchange administrators. Over to you, Microsoft – come back and tell us when you’ve figured out how to make on-premises customers happy. And by the way, three months should not figure in your new answer.
Follow Tony @12Knocksinna