Six years ago Exchange took a bold step forward in product servicing. With Exchange Server 2007 we shifted to a cumulative model to deliver customer rollup updates (RU’s) instead of a traditional hotfix model. A primary benefit to customers was a simplified delivery mechanism where many updates could be delivered in a single package. Tracking and installing multiple individual packages was no longer required. Delivering a smaller update package more frequently also allowed customers to introduce changes in a controlled fashion more quickly. This servicing model has served many customers well but not all. A challenge for some customers has been that the rollup update model has not delivered security fixes separately, requiring customers to install additional fixes when applying a security fix.
At the same time, the way customers use Exchange has encountered an equally dramatic shift. Many customers have moved their messaging environments entirely to the cloud and an increasing number are deploying hybrid environments with mailboxes split between on-premises and the cloud, functioning as a single Exchange Organization.
Considering all of these points, the Exchange team is announcing a new servicing approach for the Exchange Server 2013 and later. The new model attempts to take the best of what we’ve been delivering, address challenges where possible and recognize the shift in how customers deploy Exchange.
Today we are announcing that routine product updates to Exchange Server 2013 (and later) will be distributed via quarterly Cumulative Updates (CU’s). Each quarterly CU package will be released as a full refresh of the Exchange product and will be installed as a build to build upgrade. Build to build upgrade is already familiar to Exchange customers as this is the mechanism used to deploy Service Packs in previous Exchange versions. The version of Exchange shipped to on-premises customers in each CU will be the same version we use to host Exchange Online on Office 365. Security updates will be delivered via independent packages that can be applied to a previously released Cumulative Update package or installed during the upgrade to the current Cumulative Update package.
The primary benefits to customers with this approach include:
- Predictable release cadence – CU’s will be delivered on a pre-determined schedule four times a year allowing customers to plan their deployments more deliberately. Lync and SharePoint also release CU’s at a regular cadence.
- Dedicated security releases – Independent security releases will allow customers to quickly install an update with confidence knowing that only the fixes which address a particular problem will be included. In the event there are multiple security releases required for a particular CU, all fixes will be delivered in a single package simplifying the deployment of multiple security fixes.
- Datacenter scale validation – On-Premises and Hybrid customers will be able to deploy CU’s knowing that the same code is already deployed in the Exchange Online service and has been validated against millions of mailboxes in the world’s largest and most demanding Exchange installation.
- Improved support for hybrid deployments – System requirements will be better aligned because the on-premises server and datacenter servers will be running identical code.
- More rapid changes to language resources – In the RU model, language modifications to releases were limited to Service Pack releases. With the CU model, updates to language resources will be available in each release.
Of course moving to the CU model changes some things that users of Rollup Updates have become accustomed to:
- Larger update packages – Every update will be a full release of the product and as such will be a larger package than with previous update mechanisms.
- Loss of server customization during upgrade – Similar to Service Pack installation, the CU model will not preserve web.config, registry changes or other custom configuration applied to servers. This does not represent a change in guidance from previous Exchange versions.
- Installation failure recovery – In the unlikely event installing a CU fails and is unrecoverable, re-installation of the server will be necessary. No loss of mailbox or queue data should occur even in the unlikely event of an installation failure.
The added benefit of a CU being validated in O365 prior to release to the general public does not replace the need for customers to complete due diligence in their own environments. This is especially true when 3rd party or custom developed applications have been integrated into a messaging system. The Exchange team continues to provide guidance that all customers test upgrades in a representative lab environment prior to deploying into their production environment.
The Exchange team is excited to deliver what we believe is an enhanced model of servicing to our Exchange Server 2013 (and later) customers. The Exchange team is targeting a release date of 2013 Q1 for the first CU package. Below you will find answers to what we believe are some of the most commonly asked questions regarding the introduction of CU’s.
Q: Will CU’s contain product fixes only or will new features be included as well?
A: CU’s will be used to deliver fixes for on-premises and online customer reported issues as well as items identified by the Exchange team. Feature changes due to customer requested design changes may also be included which could add or modify existing functionality.
Q: Will there continue to be Service Pack releases?
A: Similar to previous releases, it is anticipated that periodic Service Pack updates may be provided.
Q: Will AD schema changes be included in CU’s?
A: AD schema updates may be included in a CU if required to support a change in functionality. AD Schema updates for Exchange are additive and always backwards compatible with previous releases and versions.
Q: Will there be multiple security updates released for a given CU?
A: 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.
Q: If I am installing the most recent CU available, will I need to apply security updates to that release.
A: Not necessarily. When we release a CU it will contain all security updates currently available. Only if a security update is made available after the release of the CU, will it be necessary to apply an additional security update on top of a CU. Security updates will clearly indicate which CU they are intended to be used with.
Q: Will the server version be updated during the install of a CU?
A: Yes, this also addresses some customer feedback.
Q: How long is a CU supported?
A: 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.
Q: How do I recover from a failed installation of a CU?
A: Exchange Server 2013 (and later) include high availability options to prevent the loss of data or functionality due to the upgrade of a single server. Furthermore, Exchange Setup is engineered to be executed, repeatedly if necessary, until a server installation or upgrade is completed. The actual steps used to recover from a fa iled CU upgrade will vary based upon the point at which the failure occurs and customer configuration. Existing mechanisms used to recover from a failed service pack installation will be applicable and may include use of SETUP /m:RecoverServer or installing a new server object and reseeding or reattaching existing DB’s.
Q: How will CU’s be made available?
A: CU’s for Exchange 2013 and Exchange 2016 will be published on the Microsoft Download Center. Security updates for a CU will be made available on Microsoft Update and the Microsoft Download Center. CU’s for Exchange 2019 and later will be available on Volume Licensing Service Center (VLSC).
Q: In a Database Availability Group configuration do all servers need to be at the same CU revision?
A: Customers should plan their deployments such that all servers in a Database Availability Group are running the same CU revision for the version of the product they are using. During a CU upgrade, it is supported for individual servers in the Database Availability Group to be deployed with different CU versions. This is expected to be a temporary condition until all servers have been upgraded.
Q: Do all servers in a Client Access Array need to be at the same CU revision?
A: Similar to Database Availability Groups, co-existence of multiple CU revisions in a single array is supported during the upgrade process.
Microsoft
