Exchange 2013 CU5 - the totally unremarkable update (in a good way)

After a succession of traumas arising from problems in the four cumulative updates that Microsoft has released for Exchange 2013 to date, it comes as blessed relief to report that Cumulative Update 5 (CU5) appears to be totally unremarkable. Of course, time will tell whether as yet unknown bugs bubble to the surface, but the signs are that CU5 is a simple, easy-to-apply set of fixes. Exchange administrators around the world will roundly applaud the sheer ordinariness of the update. You can get CU5 from the Microsoft download center. See KB2936880 for a list of the fixes included in CU5.

I've been applying builds of CU5 to servers for the last several weeks and after an initial hiccup, each update has been smooth and uneventful. The hiccup was caused by a missing registry key (CERES_REGISTRY_PRODUCT_NAME). This key is associated with the Search Foundation and its absence causes Setup to fail. Apparently it's an issue that has been around since Exchange 2013 was first released and many examples are reported on the web. I had never encountered the problem before and it seems to be more common when servers are heavily loaded. In any case, the Exchange engineers fixed the problem in CU5 and it shouldn't raise its head again.

Released thirteen weeks after Exchange 2013 SP1, CU5 contains many other bug fixes because it is a clean-up, fit and finish update. Stuff that didn't make it into SP1 or bugs that showed their heads after SP1 was announced are fixed. One example is the fix described in KB2958430. In this case, administrators reported that "identity references" could not be translated with an "IdentityNotMappedException" when working with the Set-DatabaseAvailabilityGroup or the Add/Remove-DatabaseAvailabilityGroupMember cmdlets to build out a Database Availability Group (in EMS or through EAC). Essentially, Exchange didn't cope well when DAGs were deployed into disjoint namespaces and produces a Dr Watson dump when these cmdlets are run. You won't have seen this problem if your DNS domain name matches the primy DNS suffix assigned to servers. The bug was introduced in Exchange 2013 SP1 and has since caused some issues for those who have a need to maintain disjoint namespaces.

The biggest achitectural fix included in CU5 was revealed by Microsoft on May 13 when they posted information about changes to the way that Exchange provides Offline Address Book data to Outlook clients. The EHLO blog says that these changes are "improvements" but I think they are fixes for flaws in the new OAB generation and storage mechanisms introduced in Exchange 2013 in an attempt to address some known issues in the older implementation. The fixes make OAB generation and distribution more efficient in scenarios where multiple OAB arbitration mailboxes exist within an organization. However, multiple OAB arbitration mailboxes are typically only met in very large and complex deployments and the changes made in CU5 will have zero impact on most customers.

Those who have implemented multiple OAB arbitration mailboxes will enjoy the fact that all of their clients will have to download a complete OAB after the changes are applied. Remember, these are large deployments so they have large OABs too and the prospect of every client having to download several hundred megabytes of OAB data is not welcome, especially if it occurs on a Monday morning following a weekend update. Oh well, you cannot make an omelette without breaking eggs and you can't have OABs without downloads.

Despite some expectations to the contrary, CU5 contains nothing much to help modern public folders to scale up from the horribly inadequate limits revealed in March. These limits, together with the sheer manual nature of the work required to prepare for and then execute the migration is enough to give anyone heartburn. During a spirited "Experts Unplugged" session at the recent MEC, Microsoft promised that they were working hard to raise the limits to a point where Exchange would support 1 million public folders. Although I hear that some progress has been made, clearly that work is still not ready for prime time. Let's hope that it will appear in Exchange 2013 CU6. On the upside, CU5 does contain a fix to allow Autodiscover to reference legacy public folders when MAPI over HTTP is used.

One small point to keep an eye on: apparently a hyperactive Managed Availability probe that forces frequent restarts the shared cache service exists in CU5 and you might be concerned when you hear about it. However, the service that is restarted is currently unused by the product and the probe has been around for a while. It does nothing except chew up some CPU cycles unnecessarily. KB2971467 explains how to mitigate the pesky probe if you consider this necessary.

On a housekeeping note, I approve of the way that Setup now cleans up the many PowerShell scripts that it creates in the ExchangeSetupLogs folder to perform various operations when installing Exchange 2013. These files absolutely did not need to be kept after a successful installation and it's good that they are now removed. Noticing stuff like this simply proves that I have the capacity to pick up on the oddest thing while ignoring other stuff that's probably more important.

Remember that every cumulative update for Exchange 2013 is a full version of the product. You can apply it to a server to install Exchange 2013 from scratch or you can update any previous version of Exchange 2013 with CU5 to bring a server completely up-to-date.

The fact that CU5 contains only bug fixes and no new features is actually a pleasant change. CU5 does include a schema update and you still need to test the new code before you bring CU5 anywhere near a production server, but signs are that applying CU5 is easy and straightforward. I'm thankful that build 913.22 is so undramatic. I suspect others will be too.

Update: MVP Michael Van Horenbeeck points out that there are some useful updates to the Hybrid Configuration Wizard (HCW) included in CU5. Read all about this topic on his blog.

Update 2: In a note on the Facebook Exchange 2013 page, Microsoft's Brian Day said that CU5 brings back certificate-based authentication for Exchange ActiveSync. Apparently the documentation is still being worked on. Stay tuned!

Update 3: It appears that the bug requiring app pools to be recycled to allow ActiveSync connections after mailboxes are moved to Exchange 2013 is not fixed in CU5. No word yet whether the fix will be in CU6 or in a roll-up update for Exchange 2010.

Update 4: KB2958434 describes a fix for the issue that I detailed in my "Cherish your old databases" article. The approach that Microsoft has taken to mitigate the problem is to reduce the lifetime of the cookie that is cached by the CAS. In turn, this reduces the amount of time that you need to keep a database after all mailboxes are moved from it. However, it would be unreasonable to reduce the lifetime of the cookie to a point where you could remove the database immediately as this would impact performance (cached data is key to responsiveness). So you still have to cherish those old databases, but for less than you had to before.

Update 5: CU5 breaks OWA redirection from Exchange 2007 to Exchange 2013 if FBA is disabled on Exchange 2007. This is a curious bug that is a definite regression. The workaround is simple - enable FBA on both Exchange 2007 and 2013 (alternatively, point Exchange 2007 to the legacy namespace). Microsoft is aware of the issue and is working on a fix, or so I hear.

Follow Tony @12Knocksinna