Concerned About Exchange Server 2013 Cumulative Updates?

The Microsoft Exchange team has sent a ripple through the community with their post about the new approach to servicing Exchange Server 2013.

In short, instead of the current model of intermittently timed service packs and update rollups that we are familiar with for Exchange 2007 and 2010, Microsoft will be releasing cumulative updates for Exchange 2013 on a fixed quarterly schedule.

Some of the details have raised concerns with customers, so let’s go through the main points here.

• Predictable release cadence – this is important and I think will be welcome by most customers, knowing exactly when upcoming CUs will be released.
• Dedicated security releases – this is another win for customers, as recently we’ve seen the backlash when critical security updates are only available in an update rollup, which may also contain other feature or behaviour changes, forcing customers to deploy the full update to plug the security hole.
• Datacenter scale validation – though it is no guarantee of quality, there is certainly some assurance in knowing that the code you’re installing has already been deployed in Office 365.
• Improved support for hybrid deployments – this is becoming more important as more customers transition into hybrid scenarios with on-premise and Office 365.
• More rapid changes to language resources – our IT brothers and sisters in non-English speaking countries will likely appreciate this. I’m not across all the issues here but I understand there are sometimes translation bugs in the various admin and end-user interfaces, and having to wait for full service packs before they are fixed is not ideal.

Now let’s look at some of the downsides to shifting away from the update rollup model.

• Larger update packages – each cumulative update is a full standalone build of Exchange. Update rollups were much smaller, though I don’t see the larger size being an issue at this stage.
  
• Loss of server customization during upgrade – this is already the case with full service pack updates anyway. While inconvenient I think there is not much to complain about here. Customizations should be well documented anyway, and many can be automated to streamline the process of reapplying them.
• Installation failure recovery – experience will show whether this is a major concern or not. Update rollups are usually able to roll back seamlessly if they encounter an error. Whether the cumulative update failed installation recovery process becomes a burden or not, only time will tell.

Attempting to anticipate other concerns Microsoft answered a series of other questions in their post as well. The key points from those are:

• Cumulative updates will still include feature changes from time to time
• Cumulative updates may include schema changes
• Service packs may still be released (I’m not sure what would warrant a service pack under this model though)
• Cumulative updates will include all previous security updates as well, and clear guidance will be given as to any additional standalone security updates also apply
• Cumulative updates will not be distributed through Microsoft Update, but security updates will
• Cumulative updates will be supported for 6 months
• DAGs and CAS Arrays can exist in a state of multiple versions as you deploy the CU, but it is expected that you transition relatively quickly to a state where all DAG or CAS Array members are at the same version (my take on this is deploying across a DAG over several days is fine, several weeks probably not so fine)

Reading through the comments on Microsoft’s post there are some strong concerns from customers.

The release schedule combined with the support timeframe pushes customers to rapidly deploy updates. Given recent quality issues with update rollups, and the fact that CUs may contain feature and schema changes, this is a valid concern.

I believe much of this can be resolved procedurally with adequate testing, a well documented update process, and familiarity with rollback procedures. At the same time, Microsoft needs to rebuild their reputation when it comes to Exchange update quality.

Let’s be honest though, a lot of us do not have the time or resources to do thorough testing of updates before production deployment. However at a minimum I would encourage Exchange admins to train themselves on Exchange recovery and AD forest recovery procedures. Even if you only do it once or twice, you’ll feel much more confident deploying updates afterwards.

But do we really need to update every 3-6 months to stay supported? In episode 13 of the UC Architects podcast Microsoft’s Rick Kingslan explains that customers sometimes misinterpret what “supported” means. If you call Microsoft for support they may suggest, after exhausting other possibilities or because of a known bug, that you update to a supported version of the product, however they do not simply turn you away and refuse to support you.

IT professionals are at risk of being incrementally updated to death these days. Between hardware firmware updates, virtualization platform updates, operating system updates, application updates, and so on, some people no doubt feel like they are in a constant state of upgrade and never get to a stable environment.

That said, I think anyone paying attention to the world of Microsoft product development these days is already expecting to be doing more frequent updating of products anyway. Microsoft’s cloud services are iterating fast, and now that Office 365 and Exchange 2013 on-premises have re-united to the same code base they will be iterating together.

Here’s what a few other Exchange MVPs and bloggers also think about this new announcement.

• Thoughts on Exchange’s new cumulative update model
  
• Thoughts on the new Exchange 2013 servicing model
• Exchange 2013 Cumulative Updates and You

What do you think about the new way of servicing Exchange Server 2013?