Servicing Exchange 2013

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 product. 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 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 customer’s 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 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 includes 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 failed 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 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.

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.

Brent Alinger

Comments (30)
  1. Good to know that the server version will be updated during CU install

  2. Since each CU is a new build, can customers install Exchange 2013 from the latest CU? Will it be necessary to install Exchange 2013 RTM and then upgrade to latest CU?

  3. @Jeff, customers may go directly to the latest CU at any time.  There is no need to deploy RTM and then upgrade to a later  CU.

  4. Though is states Service Pack updates may be provided, this would definitely relieve some of the burden of getting new installs up-to-date if all we need to do is install the latest CU.  Awesome to think of the possible time savings.  I would definitely welcome CU's over SP's if that is a possibility.

    With a new install, would an EA customer be able to apply their product key to any CU?

    If interim security updates become available would they need to be removed before installing the "next" CU?

  5. @Todd, a customer will be able to enter a product key for a server installed to the latest CU the same as they do today when installing an RTM or a Service Pack build.

    Any official security patches released for a CU will NOT need to be uninstalled to move to the next CU.

    Thanks for the feedback on SP vs. CU.

  6. says:

    Another great move, as stated in the article, this will help plan the deployments of CU ahead of time.

  7. Devin L. Ganger says:

    So taking this, and putting it together with some of the information from MEC, does this mean that CAS and MB roles (if separate) no longer have to have the updates applied in a specific order?

  8. Sunder says:

    Automatic Updates can cause the CU's to get installed on its own. I think Manual Update can help administrators to plan for a downtime and then apply the CU's. Just to be in a safer side. In case if it fails.


  9. Peter Vassiliou says:

    I do not welcome this change because that way customers will always have to much thoroughly test everything before deploying a patch. I do not understand why there is no uninstall option!

    The track record of Microsoft isn't good, as far as Update Rollups concerns, and there should definitely be an option to uninstall CUs.

    I can see a future where most customers do not update, or update very infrequently.

    You should reconsider!

  10. mike says:

    Service Pack 3 for Exchange 2010…

  11. Will exchange 2013 CU use synthetic oil?

    there been a lot of rumors about that….

  12. How is this good for us? says:

    You say CUs will be full product releases and may contain schema changes, which are essentially the same as a service pack today. Installing service packs is a pain comared to RUs today, not to mention unlike RUs SPs require 3rd party vendor validation like you claim CUs will. So how is a CU not like a SP???

    All I hear is we get the privelage of being forced to deploy CUs (essentially SPs) every 6 months at a minimum, preferably every 3 months, because the currently installed CU won't be supported 3 months after the next CU. This is all just so you can drop the existing deployment cycle/methodology for on-premesis customers in lieu of the quarterly one you set up for Exchange online.

    Thanks but no thanks when it comes to applying the equivalent of a SP every 3 months and all that goes with a major SP update.

    Clearly your on-premesis customers are becoming less and less a priority compared to your online cloud solution, to the point where it seems sometime in the not too distant future we will be forced to move to your cloud solution or switch to another on-premesis solution.

  13. justin says:

    So every quarter a client will be required to refresh his entire environment and reapply all customizations or be unsupported?

    Are you trying to force people to the cloud by making on premise impossible to support from a cost standpoint?  Patching isn't free…

  14. Anonymous says:

    I think the lack of support every 6 months is ridiculous to be honest. It requires Exchange administrators to make major modifications to the Exchange environment every 6 months which is a lot to ask.  Especially given that all customizations will need to be re-applied.

    With Microsoft's track record in the lack of quality around Exchange patches, there really needs to be an uninstall option here.  Either that or fix the testing process to catch whatever issues that keep slipping best your quality assurance process.

    I do like the fact that new installs can go right to the latest CU though.  That'll help speed up deployment new servers.  It's just the ongoing operations that concerns me.

  15. Security Guy says:

    I do very much like the ability to decouple security from non-security fixes.  Can we expect the same kind of servicing for Exchange 2010 also?

  16. Bruce Anderson says:

    "Datacenter scale validation" – If we are to accept that statement, does this mean the on-premise product is going to have the exact same limits and published scaling guidance as Exchange On-line?? Currently, you may have the largest exchange deployment, but I would take exception to the statements around the "most demanding" statement. There are numerous configuration choices that are officially supported for on-premise, that are prohibited in Exchange on-line. Outlook 2003 comes to mind, as well as about a dozen others. And by giving businesses a supported "choice" those who support it often suffer the consequences of that choice.

  17. Quantity over Quality? says:

    Microsoft has had a very poor record of delivering CU's over the course of the last year, with many of them in 2012 being recalled and rereleased. In some instances, even the rereleased versions were still flawed and also recalled after causing multiple client impacting issues. Focusing on QA testing is much more important than trying to deliver quicker updates. How will support for CU's be handled when the previous release is recalled? It is an almost certainty that this will be the case especially as Microsoft tries to deliver more instead of delivering better quality. Quality is better than Quantity.

  18. pete says:

    Why did Microsoft even bother with releasing Exchange 2013 for on-premise installation?  It's obvious they want us to put all our data in the cloud and just pay continual subscription fees.  Hence the lack of effort on producing a good on-premise solution.

  19. Sven J says:

    This must be a early April joke.. in the light of latest CU's.. a quarterly scheduled exchange reinstallation.. unbelivable..

  20. Mark says:

    Hmm… It will be interesting to see how this works out. To be fair, track record for Exchange service packs is not nearly as bad as RUs recently, and CUs are really mini service packs being full builds and all. There are questions if the quality will be on the level it needs to be with quarterly releases. And I agree with another comment saying that running in Office 365 does not necessarily ensure great results for us… I hope this is in addition to testing that service packs get today. I do not know but would be surprised if you ran Exchange 2007 in the same organization in the cloud with all the supported clients that are supported in the enterprise.

  21. Rob Helm says:

    Are vendors of third-party extensions on board? That is, are the vendors of products for backup, antimalware/antispam, content management, and other Exchange support functions going to be testing and updating their products against specific CUs? Or will that work have to be done by each customer?

  22. susan says:

    How will the support windows be communicated?  Since these CUs will not be on MU but must be manually downloaded?

  23. Charles Derber says:

    Second Last CAQ

    Can you elaborate little more on this – This is expected to be a temporary condition until all servers have been upgraded.

  24. sam says:

    Looks like opening door to setup and installation issues  than ever.

  25. Charles Derber #, Expectation is to have all DAG members running on same CU. But, not all servers can be upgraded at once. Hence, you may have DAG members on different CU versions till the upgrade is done on each server. That's meant to be temporary condition.

  26. Some Consultant out there says:

    While i see praises and disappointment from IT community here, I am surprised why MSFT is not responding to the customers who are not happy about this update mechanism.

  27. sam says:

    There are numerous hours and hours , everytime trying ot fix failed RU or SP Upgrade.

    many time servers were rebuilt or recovered. With this approach it Appears these issue are going to me more

    prominent with every CU.

    It is too Risky for Setup like HA , Environments with large number of servers ,

    there is no way people are gonig to rebuild their servers , bcs BuildtoBuildupgrade failed. It appears Exchange Team is not considering any of these pain points before making decision.

  28. DavidJCarr says:

    Very interesting. I think it is a good idea if it can be implemented well. I think the timeframe chosen should give them to get it done and I would prefer if Microsoft delays it if it is not ready rather than rush it out to meet the date.

  29. David says:

    Please use an internationally recognisable date format in your examples. 3/1 6/1 and 9/1 really are confusing to Europeans.

  30. says:

    Sorry Exchange team, but I do have to agree with most of the comments here : How can you release an update every 3 months where I have to install my whole environmetn again ? Th is so stupid ! These "updates" will :

    1. Completele deinstall my Exchaneg system

    2. Then reinstall it with the new CU

    Did you ever take into account how much time that will cost ? And this should really reduce the TCO ? Thats just rediculous, sorry, and I also see that you just want to push everybody in the cloud, which a lot of enterprises, especially in europe, just refusing because of legal requirements…Microsoft is an american company and when the next "patriot act" will be released, then all mailboxes must be scanned..a lot of german customers will not go into your cloud and if you continue with these stupid ideas, I also think that a lot of customers will pass Microsoft prodcuts…

    It started with this STUPID "Exchange Admin Center" ! Why did you take away the logical and well structured MMC ? Your article is just pffff why you did that. You are really DESTROYING Exchange ! I am with Exchange since version 5.5 and what I see right now is just garbage, and it really hurts…please dont continue like that and HEAR to your customers !!

    At the moment all of my customers just refuse Exchaneg 2013 and stay on Exchange 2010 since its the most friendly system at the moment…


Comments are closed.