The first cumulative update for Exchange 2013 (CU1), or to give the software its official title, "Exchange Server 2013 RTM Cumulative Update 1", has arrived and is available for immediate download. The new release can be installed using a “build to build” (B2B) upgrade if you already have Exchange 2013 RTM in place. Otherwise you can simply install Exchange 2013 CU1 and use it as your starting point for Exchange 2013. An Active Directory schema update is required to support Exchange 2013 CU1. This is a different version to the schema update released with Exchange 2010 SP3. Those who track these things can use Michael B. Smith's PowerShell one-liner to fetch the value of the rangeUpper property from the ms-Exch-Schema-Version-Pt attribute in AD (the answer is 15254). The formal build number is 620.29.
Apart from marking the debut of Microsoft’s new method for updating Exchange, CU1 is required to interoperate with Exchange 2010 (SP3) and Exchange 2007 (SP3 RU10). Thankfully, one of the final barriers to deployment is now released, unless of course you’re still running Exchange 2003 or an even earlier version, in which case you have to figure out your path forward. Maybe it will be via a first step to Exchange 2010, or maybe you’ll go “all in” and embrace the cloud. Office 365 or other hosting platforms do look like attractive options when considering a double-barreled migration.
As the EHLO article points out, those deploying CU1 to coexist alongside legacy versions of Exchange need to pay attention to the details of deployment. Three in particular deserve some mention - the introduction of a new Offline Address Book, a change in the way that mailbox quotas are calculated and reported, and the change in the Client Access Server role and how to deploy the CAS so that it handles connections properly for your organization.
CU1 includes literally hundreds if not thousands of bug fixes. However, all software has bugs and it is not at all surprising that many bugs are fixed in a product as complex as Exchange 2013 over the six-month period since the RTM version appeared. Looking back into the past (a habit I have been accused of in the past), I recall being part of a team that reviewed a list of well over a thousand bugs that were eventually fixed in ALL-IN-1 2.4 (1989). Although ALL-IN-1 was also an email server, the world of complexity that Exchange has to handle is much deeper than we coped with some 24 years ago. Clients are more sophisticated, functionality is radically increased, security is so much better, and the ways that we deal with information more diverse. Developing new features and capabilities means that new code must be written. And when new code is written, new bugs pop up.
In addition, when discussing bugs or overall software quality for such a large and complex product as Exchange 2013 is, it is important to understand that the set of reported bugs varies enormously. At one end of the scale you have bugs like a minor spelling error in some text in documentation or an-screen prompt or a “strange” translation in one of the many local language versions of Outlook Web App (OWA). At the other, a bug could be a problem that causes a major piece of functionality to fail. Given that both OWA and the Exchange Administration Center sport new user interfaces in Exchange 2013, some fit-and-finish problems were to be expected; the CU1 version of EAC is more refined, so plenty of work has been done to address the UI flaws.
I also noted a reduction in the “chatter” of the Managed Availability probe messages generated and sent by the health mailboxes that are created in every mailbox database. On an essentially inactive mailbox server running Exchange 2013 RTM, new transaction logs are generated every minute. When the same server is upgraded to use CU1, transaction logs are generated every 15 minutes as “log roll” kicks in to force replication within a DAG. Although it is obviously important that any system designed to monitor server health should measure how the server is performing on a regular basis, it is equally important that Managed Availability does not impose an undue strain on the server. I think that the developers have reached a better balance in CU1 than in RTM. We shall see how this story evolves.
OWA is faster in CU1, which is welcome. Regretfully, the functionality available in OWA has not matched its new turn of speed as several notable omissions still remain. S/MIME support is rumored to be “coming”, but I cannot understand why the moveable reading pane is still absent as this has been a feature of both Outlook and OWA for many years. No doubt good reasons exist for its absence, but it is a pity as the feature is really quite useful. In passing, I’m not sure I agree with Paul Thurrott’s assertion that Exchange 2013 includes “a gorgeous and useful new version of the Outlook Web App that even supports multi-touch interfaces“ (a true case of beauty being in the eye of the beholder). Yes, OWA boasts a new interface that supports touch and offline access, but I consider the new interface to be functional rather than gorgeous and some work still needs to be done to bring it up to the same level of functionality offered by Exchange 2010 SP1 onward.
Obviously it is good that Exchange 2013 CU1 is now available. However, a nagging feeling persists that this is the software that MIcrosoft should have released at RTM instead of shipping the "good-to-go" version that appeared. Of course, seeking perfection in software is a fool's errand and the Exchange group could not have held back their product while other Microsoft teams participated in the "Office Wave 15" last October. As politicans say "we are where we are"; instead of getting bent out of shape about the sad state of Exchange 2013 RTM, we should accept that CU1 now represents the state of the art and view it as the foundation for Exchange 2013 deployments.
Like any new software, you should view CU1 with caution until you have had a chance to deploy and test the software in a reasonable test environment. It’s likely that production Exchange 2013 deployments will need some other shoes to fall before roll-outs commence. ISVs need the time to validate their products against CU1 and test against various co-existence scenarios and this will delay matters a tad. Quite how long that particular piece of string is remains to be seen. To give a consultant’s answer: “it depends.”
Follow Tony @12Knocksinna
