Thoughts on Exchange’s new cumulative update model

Today’s announcement by Microsoft of a new approach to updates for Exchange is welcome in many respects. A new system of cumulative updates issued on a quarterly basis and applied to servers via Exchange’s B2B (build to build) installation program will be used to keep on-premises deployments updated at the same rate as the cloud-based Exchange Online. Some questions are inevitable about why Microsoft would move to this model. Here’s my take on what’s happening.

Cumulative updates are like the older roll-up update packages for Exchange 2007 and Exchange 2010 in that they deliver a cumulative set of bug fixes and enhancements that, when installed, bring a server up to date with the latest software. In addition, cumulative updates will be increasingly used to deliver new functionality in line with the way that features “light up” inside Exchange Online. The precedence of using cumulative updates to deliver new functionality and fixes has been set by Lync, and as Microsoft’s blog says, both Lync and SharePoint will use the new update model.

Over the last eighteen months, Exchange has had an unfortunate record with the quality of roll-up updates. Some of this has been due to problems introduced by third-party software components, as in the case of the WebReady document viewing modules that introduced a security vulnerability, some due to Microsoft’s own deficiencies as in the failure to communicate between engineering groups for the MMC/IE problem or the rush to issue a fix for the WebReady problem with unsigned code.

Microsoft is acutely aware of the issue caused by poor quality and the impact on Exchange’s reputation, which isn’t helped by some of the shortcomings that are painfully obvious in the Exchange 2013 RTM release.

Microsoft’s response breaks down into three actions. First, they have reintegrated the code libraries used to generate Exchange Online as used in Office 365 and the on-premises version of Exchange. Second, for Exchange 2013 onwards, they will issue regular cumulative updates for the on-premises version that match the slipstreaming of new features into Office 365. Third, the previously separate sustaining engineering team that was responsible for the production of roll-up updates and service packs has been merged with the mainline development group to form a single team that is now responsible for the development and maintenance of Exchange. All seem reasonable steps to take, although some will ask why they haven’t happened before.

The code base used to create Exchange Online and on-premises began to diverge from Exchange 2010 SP1 onward when a separate code branch was created for the software that runs in the Office 365 datacenters. Since then a gradual gap in functionality has grown between the two branches where new features appear in one platform and are exposed to customers before being available in the other. For example, the cmdlets to control where delegate-sent messages are stored is available in Exchange 2010 SP2 RU4 but not yet in Exchange Online. On the other hand, features exist in the datacenter that aren’t seen on-premises. If you doubt this, just look through the TechNet documentation for Exchange and observe the number of occasions where cmdlet parameters are “for Microsoft use only”.

Unifying the two branches makes eminent sense. In fact, it’s strange that such a divergence was allowed to happen. Obviously, it is easier to fix problems in one place rather than two; new features should appear consistently across the cloud and on-premises platforms (important in hybrid environments), and engineering effort can focus on driving quality rather than worrying about development for multiple delivery vehicles. This work has already started, so when Exchange Online is upgraded to use Exchange 2013, feature parity should exist from then on across the two platforms. It also means that it’s easier to make sure that the finer points of new features are fully covered, such as making sure that everything is localized.

Having to deliver updates that support hundreds of thousands of Exchange Online mailboxes and on-premises customers alike should increase product quality too. I cannot see how Microsoft would allow Exchange 2013 updates to be released to customers if they aren’t of sufficient quality to run without problems inside Office 365. Hopefully, Microsoft will seize the opportunity to test updates for a couple of weeks inside Office 365 before they are released to on-premises customers so that they can then say that the code now released has run without problems in the datacenters.

Of course, Office 365 does not resemble the operational environment of any on-premises customer, not least because of some of the integration that’s done on-premises to run Exchange alongside third-party or home-grown code. It’s also fair to say that some unique hybrid, co-existence, or migration scenarios will not be tested – that work still has to be done after an update is available and before any new code is introduced into a production environment. However, even with these caveats, the fact that code is tested inside Office 365 should give on-premises customers a higher degree of confidence that an update will in fact work and work well.

The cadence of new feature release is becoming faster because that’s the way that the cloud works and Microsoft has to respond for Office 365 to remain competitive. New features have appeared in Exchange 2010 roll-up updates in the past so this is hardly news (think of the change to the way the Managed Folder Assistant processes calendar and task items in Exchange 2010 SP2 RU4). The big difference is that new features will appear in all updates rather than intermittently.

Which then begs the question as to what happens with service packs? The word is that Microsoft will continue to ship service packs for Exchange, if only to provide milestones for customers to incorporate into their planning for software refreshes. Service packs are likely to be collections of cumulative updates bundled with perhaps a documentation refresh and possibly some big new functionality or refresh of an existing feature. For example, Outlook Web App as delivered in Exchange 2013 isn’t the most functional client that Microsoft has ever built and it is in line for a major overhaul to add missing features like a movable reading pane and support for public folders and site mailboxes. An Active Directory schema update to support a new feature is another element that might warrant a service pack. Microsoft’s announcement says that an update might include an Active Directory schema change, but I can’t imagine that enterprise customers will welcome the prospect of frequent schema updates. Then again, perhaps those who run Active Directory have gotten over their fear of schema updates.

As to the third change, it makes a whole heap of sense to create a single integrated development group that owns the responsibility for development, maintenance, and support of Exchange for both on-premises and cloud platforms. I’m sure that the two previous teams worked closely together, but once you have multiple teams involved in any effort, there’s always a lingering suspicion that problems can arise at the join between the teams.

Will the changes drive additional quality and restore Exchange back to the point where it once was? Creating a common code base and driving a single release across cloud and on-premises is sensible and should help to eliminate issues that should never surface outside Microsoft. Making new features available to customers faster is good if you want the features. Others who are quite happy with the functionality of Exchange will worry about the impact of new features on administrators, help desk, and end users, so I guess your view of this change is driven by how you think new functionality should be introduced. I doubt that this change will improve quality, but I do think that the new integrated structure for Exchange will help.

Some worrisome issues are contemplated by the new strategy. Support is an obvious concern. Microsoft says:

“A CU will be supported for a period of three (3) months after the release date of the next CU. For example, if CU1 is released on 3/1 and CU2 is released on 6/1, CU1 support will end on 9/1.”

But few large on-premises deployments of Exchange have the capacity or capability to handle the testing and installation of new updates to Exchange four times a year. The fact that the support window closes just three months after the release of a new cumulative update seems to be too quick. It certainly encourages customers to keep Exchange updated, but perhaps it’s at the expense of introducing too heavy a load for some. A cynic or conspiracy theorist might speculate that this is simply a way for Microsoft to convince on-premises customers that now is the time to move to the cloud when these concerns simply go away. Sure, other concerns come into play when using a cloud platform, but that’s not important right now.

Another problem is that a cumulative update might overwrite customized elements within your deployment. It’s nice to have the opportunity to customize that OWA log-in screen again, but not so if you have to do it four times annually.

Finally, I’m not 100% clear on what happens with security updates. Microsoft says:

“The security updates released will be CU specific and will contain all of the fixes available at the time of release for a given CU in a single cumulative package. In the event that multiple releases have been made available for a given CU, only the most recent version of the security update package will be required to be installed and it will contain all previous fixes as well.”

Reassuring enough… but what happens when Windows finds a security hole and rushes a patch out. Will it be tested with the latest CU or the just-about-to-be-released CU? And what happens when a security hot fix interferes with a component in a CU in such a way that it stops some feature of Exchange working? I’m sure that Microsoft has an answer but it’s not clear yet to be what that answer might be.

Of course, nothing is certain when you deal with software and Microsoft will be judged on results, not grand plans. Exchange is suffering from a quality problem today. We shall soon have the chance to judge whether the new cumulative update model works when Microsoft issues the first update for Exchange 2013. It can’t come fast enough.

Follow Tony @12Knocksinna