Now that the dust has settled around Microsoft’s announcement that Exchange 2013 Service Pack 1 (SP1) is on the way in “early 2014” along with updates for the other server applications in the Office suite, it’s probably a good time to reflect on the changing nature of service packs.
Our expectation around service packs has accumulated over the years to a point where an almost inbuilt trigger fires annually to look for an update for Exchange. The cadence of a major release every three years interspersed with annual service packs allows Microsoft to code, test, and document new features that they can then reveal at the annual TechEd or Exchange Conference. And the pace allows customers the latitude for careful planning, testing, and deployment into production environments, including the inevitable need to integrate Exchange with custom code or third-party products. On the whole, life was good.
The demands of the service and competitive pressures have brought us the Exchange 2013 servicing model. Office 365 has an insatiable demand for new features and cannot depend on an annual release cycle. The memory span of a marketer is, after all, about twelve seconds and they couldn’t possibly be expected to sell Office 365 against Google if forced to wait so long for the new whizz-bang-wallop option. Press releases don’t write themselves – some basis of reality, however implausible, has to exist before a competitive release can be issued against the evil GOOG empire. It can be really hard to keep up with developments, especially if you follow several technologies.
The big thing to remember about the new servicing model is that a cumulative update is a completely new version of Exchange that can be installed on a server to bring it right up to date. Because cumulative updates appear every quarter, there’s a certain amount of “the train is leaving the station” feeling about how new features and bug fixes are incorporated into any particular update. It might be that every thirteen weeks or so Microsoft looks around to find what new features and fixes are available and incorporates whatever’s ready to form the new cumulative update. I don’t believe that this is what actually happens for a moment, but it’s one way of looking at the stream of cumulative updates that have appeared to date.
I think of a service pack as a cumulative update on steroids. All of the features that need extra time to develop, test, and document or are simply a large enough component not to want to slip into a quarterly update are brought together into a coherent whole.
For example, Exchange 2013 SP1 is slated to see the return of S/MIME support in Outlook Web App and the reappearance of an Edge server. You might not have missed these features but companies who depend on S/MIME to protect email communications have not been able to plan to move to Exchange 2013 until now. The Edge server is probably less important because an Exchange 2010 Edge server is perfectly happen to interoperate with Exchange 2013, but it seems untidy to be forced to mix and match software versions. And it seems like the Exchange 2013 Edge server will be different to its predecessor in some respects, all of which needed time to evolve and debug.
And then there’s support for Windows Server 2012 R2. Some companies have been waiting for Exchange to support the latest Windows before beginning their deployments for the very good reason that once you install Exchange onto a Windows server, you can never upgrade the operating system again (apart from bug fixes). Thus, it makes eminent sense to plan on the basis of deploying the latest version of the O/S whenever possible.
SP1 will include other new features and many bug fixes. It also includes an Active Directory schema update, once an operation dreaded by all concerned but now a hum-drum kind of thing that has happened in every cumulative update for Exchange 2013 issued to date. Schema updates are needed to add new Exchange objects or accommodate new cmdlets, RBAC definitions, and so on. No big worry.
All in all, Exchange 2013 SP1 seems like a large and more comprehensive cumulative update. As such, large organizations who don’t like applying frequent updates to their IT environments can plan their annual refresh based on SP1 and ignore all the cumulative updates that have gone before. And those who hold to the adage that you should never deploy a Microsoft server application until the first service pack appears can come down from the mountain and join the rest of us.
Microsoft says that "SP1 is essentially CU4". You can call it Exchange 2013 CU4 if you like. Indeed, the next quarterly release will be Exchange 2013 CU5 and not Exchange 2013 SP1 CU1. Forget that old roll-up update numbering scheme used with Exchange 2007 and Exchange 2010 because it simply doesn’t make sense in a world where the latest cumulative update represents the latest version of the product. If you hit a bug and want support, you'll be asked to install the latest version of Exchange 2013 whether it is SP1 or CU5. It's as simple as that.
In closing, I hope that Microsoft does not repeat the same mistake that happened with the Exchange 2013 “Release to Manufacturing” (RTM) software. That code was palpably unready for the stress of customer environments and was rushed out to meet the needs of the Office Wave 15 marketing campaign. The uneven quality and missing functionality in Exchange 2013 has only really been addressed with the release of Exchange 2013 CU3, thirteen months after RTM. Sad but true.
So, Microsoft, keep in mind that slow and steady makes customers happy – there’s no need to rush SP1 out the door. We can wait...
Follow Tony @12Knocksinna
