The release of Microsoft Exchange Server 2013 Cumulative Update 6 (CU6 – build 995.29) comes as the summer vacation period winds down. Still, attention might still be more focused on the pressing matters of vacation, cold beer, and ice cream and not on having to upgrade email servers. But when you come to deal with CU6, you’ll find that (at first glance and with the caveat of non-exhaustive testing) it seems to be a docile upgrade with no bite for the unwary administrator. In fact, it creates even less of a splash than its CU5 predecessor.
That being said, it’s also fair to remark that every cumulative update has its own quirks that only come to light after the update is exposed to the full light of widespread deployment. CU5 has its own, like some transport backpressure issues, slow EMS responses when Get- commands are executed, a Hybrid Configuration Wizard problem after an Office 365 update, a slightly unnerving issue that causes mailbox databases to dismount unexcitingly, and so on. You might not encounter these bugs but others have. The point is that all software has bugs. Each update fixes many, and CU6 fixes the ones listed about, but can introduce its own, which underlines the need for careful testing before deployment. And yes, an Active Directory schema update is needed.
CU6 contains no new functionality slipped under the covers (at least, nothing immediately noticeable). Just a set of fixes that smooth and even out the rough edges of various bits of Exchange, updates that address esoteric and wonderful issues like “AutodiscoverSelfTestProbe fails when external URL is not set for EWS virtual directory in Exchange Server 2013” and “Topology service cannot find the OWA service" when you perform an eDiscovery search in Exchange Server 2013.” I’m certainly glad that these bugs are fixed. More seriously, fixing a compliance issue like the one (KB2977279) that caused voicemail messages to be journaled when they were supposed not to be is a welcome update.
But then we come to public folders and discover that this is where the real action occurs in CU6. The first issue to be addressed is the calamitous problem that emerged when the modern public folder architecture didn’t scale past the point of a moderately impressive demo environment. Much discussion ensued, especially at MEC, and the product group swore to do better. In June, the developers announced that scalability would be much improved in CU6. The work to effect the improvement appeared in Exchange Online (Office 365) in July. Full details of what has been done in CU6 is available in this EHLO post.
A ten-fold increase in the number of public folders that can be supported in an infrastructure will satisfy most, but not all, of those who want to migrate their old-style public folders to Exchange 2013, but it’s a good start. In fact, it’s the first step along the path to allow the new architecture to be able to support millions of public folders. Cynics will point to the fact that the old architecture is able to support millions of folders already, but then again, the old style didn’t just happen overnight and it takes time to accumulate vast quantities of public folders.
Of course, it’s difficult to test public folders at large scale unless you take the time and trouble to build a test harness that creates thousands of folders across a set of public folder mailboxes, populates the new folders with some content, and then directs user traffic to exercise the new architecture. No doubt Microsoft has such a test harness and so we shall have to wait and see how some real-life migrations progress before a true vote of confidence can be given.
Another change on the public folder front is to close the security gap that allows mail-enabled public folders to accept inbound messages from any external sender. Microsoft fixed this bug for Office 365 in July but didn’t tell anyone first, which then caused some problems when email sent to public folders generated unexpected NDRs. Oh well, you can’t make an omelette without breaking some eggs.
One thing that isn’t in CU6 is any exposure of other public folder types (like those that contain shared calendars) in Outlook Web App. Apparently this request, which was well voiced at MEC, is being worked on but the code is not yet ready.
As you prepare to deploy CU6, remember that Microsoft only tests and supports upgrades from the last two updates (N-2). The servicing model for Exchange 2013 states that a CU is supported for three months following the release of the next CU. It is therefore unreasonable that Microsoft would test upgrades from every CU that has been released because everything before CU4 is unsupported.
In other words, although it might be possible to upgrade a server running CU2 to CU6 without incident, no guarantee is given that this will be the case. CU4 is an exception because of its designation as a service pack (SP1). Service packs are supported for twelve months after the arrival of the next service pack. In practical terms, this means that if you are running CU1, CU2, or CU3, you might have an issue if you attempt to upgrade direct to CU6, something that will turn up in testing. Microsoft’s advice is to go direct to CU6 because it is, like all other cumulative updates, a complete version of Exchange 2013 and if a problem is found, they would prefer to resolve it against CU6.
KB2961810 contains the full set of fixes included in CU6. If you’re running Exchange 2010, you should also check out KB2961522 for the details of Exchange 2010 SP3 RU7. Exchange 2007 users need KB2936861 to learn about Exchange 2007 SP3 RU14, which deals with a recent DST change (trivia question: how many roll-up updates will Exchange 2007 eventually accumulate?).
Quarterly updates have now settled into a well-worn cadence. The wary treat all updates with suspicion until tested. You are so advised.
Follow Tony @12Knocksinna
