The Good and the Not So Good of Exchange 2013 Cumulative Updates

After Microsoft released Exchange Server 2013 Cumulative Update 2 this week I found myself contemplating how the new servicing model for Exchange is going so far.

The ability to do “build to build” upgrades seems like a good thing to me so far. As I do the planning to update an Exchange 2010 organization from SP2 to SP3 + UR1 the ability for Exchange 2013 servers to be upgraded in one step to the latest build is certainly more appealing. Though we don’t know yet if a service pack for Exchange 2013 will come along and disrupt that.

The process for installing Exchange 2013 cumulative updates is a little more complex than updating Exchange 2010. However this is a good thing in my view, because it is due to new features in Exchange 2013 for managing servers in and out of maintenance.

On the other hand, there is a bit of an information gap appearing in the releases of the cumulative updates.

To put that in context, when assessing an Exchange update I usually ask three questions:

  1. Is it required to keep us within the supported versions
  2. Does it add a feature that is desirable to us
  3. Does it fix a problem we’re experiencing

On the matter of support, the new servicing model makes clear what is required to stay within the supported versions.

In the new Exchange servicing model customers will continue to receive assistance from Microsoft Support for the lifecycle of the Exchange server product – a customer is not required to be at the most current CU to receive assistance. There are two scenarios that we would like to clarify though:

  1. If during the course of a support incident it is determined that the solution is available in a published CU (e.g., CU2), the customer will be required to install the update that contains the fix. We will not be building a new fix to run on top of a CU published earlier (e.g., CU1).
  2. If during the course of a support incident it is determined that you have discovered a new problem for which we confirm a fix is required, that fix will be published in a future CU that you can then install to correct the problem reported.

On the matter of new features, the Exchange team blog posts usually do a good job of explaining new features as they are released in updates, or with longer, dedicated articles shortly after.

Which just leaves bug fixes. With Exchange 2010 some of got used to seeing a list of significant bug fixes being included in the blog post as well as the associated KB article (examples here and here).

The blog posts and KB articles for Exchange 2013 cumulative updates have not included similar lists so far. Which is odd when some important bugs are being fixed, such as KB2835562 (You can’t disable Outlook Web App access for users in on-premises Exchange Server) which is fixed in CU2.

Hopefully Microsoft can find a way to include those lists of bug fixes in the published information for Exchange 2013 cumulative updates. In the meantime, if you’d like to try and keep track of these types of updates you can subscribe to the Exchange 2013 RSS feed (from this list of product feeds). On the day of a cumulative update release there tends to be a bunch of KB article updates/releases for the included bug fixes.

What do you think of the new servicing model for Exchange 2013 so far?

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter and Google+.

Comments

  1. Rick Leib, CISSP says:

    So far Exchange 2013 CU1 coexisting with 2010 has not been for the feint of heart. We have experienced several issues around Outlook Authentication (NTLM failing to work externally) and several issues where an Exchange 2013 MB/CAS server configuration caused users on 2010 to experience authentication, and usability issues.

    Overall it’s worth the pain, but there are still a few items that are not well documented and takes patient users to tolerate the overall migration.

    BTW: Autodiscover has several problems still while Co-Existing.

  2. On-premise 2013 deployment with just a few IT testers.

    Successfully tested all ExRCA requirements last week.

    Decided to apply CU2 last Thursday night.

    Friday morning no iPhones could sync. Checked:

    Get-ActiveSyncVirtualDirectory | fl identity,InternalUrl,ExternalUrl

    …and discovered my external URls for ActiveSync had disappeared! Very strange…cross-referenced the CU2 update time and noticed the SAME time-stamp for the date modified on the virtual directory is the SAME as Server App log events listing:

    “‘HttpEvent’ ID 15301 – 4 of them:

    SSL Certificate Settings created by an admin process for endpoint : 0.0.0.0:444 .
    SSL Certificate Settings deleted for endpoint : 0.0.0.0:444 .
    SSL Certificate Settings created by an admin process for endpoint : 0.0.0.0:444 .
    SSL Certificate Settings deleted for endpoint : 0.0.0.0:444 .

    Not sure if relevant. Considering opening a support call to figure out what happened to the vir dir settings.

    Re-added by Set-ActiveSyncVirtualDirectory -ExternalUrl etc etc and ExRCA works again.

    Anyone else seen this type of strange event??? Never seen virtual directory settings dissapear!

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.