Microsoft released the second servicing update for Exchange 2013 RTM (CU2) on July 9, 2013, some fourteen weeks after CU1 and in line with its goal to make service updates available on a quarterly basis (read this to be once during a quarter rather than on a strict quarter boundary).
The EHLO post announcing CU2 contains some interesting comments. Microsoft appears to have softened its previous stance on requiring customers to keep current with cumulative updates and now realize that customers cannot simply go and deploy updates on production servers without considerable testing, including the need to get updates from third-party software vendors for whatever products are in use that interact with Exchange. The post recognizes that some customers “require more time for testing” and promises that Microsoft will “continue to ship a Service Pack” that “acts as a logical milestone”. No word though as to when we might expect to see Exchange 2013 SP1.
On the other hand, Microsoft continue to emphasize with some logic that their servicing policy has advantages for customers who run hybrid environments as it allows them to keep their on-premises deployments updated with software that matches the version of Exchange Online running in their Office 365 datacenters. This is absolutely true, but not a reason to force on-premises customers to adopt an update cadence that didn’t match their needs. The subtle change in messaging that I see in the CU2 announcement is welcome and reflects the feedback that I know Microsoft has received from customers.
Some clarification is also offered about support of Exchange 2013. In a nutshell, if a customer reports a bug that is fixed in a later release to the software that they run, they must install the latest update before Microsoft will investigate a problem further. If a bug is discovered in an update, Microsoft will fix the problem and release the fix as part of the next cumulative update with the aim being to reduce the number of individual hot fixes released to customers. Put another way, given the regularity of the update release cycle customers should not have to wait long before they receive an update that contains fixes for any problems that they report. This clarification is welcome because it removes some pressure to install updates as quickly as possible.
As to CU2 itself, the upgrade is easy enough as long as you pay attention to putting DAG member servers into maintenance mode (consider using Michael van Horenbeeck’s script if you want to automate this operation) before attempting the update and make sure that the now-almost-expected Active Directory schema update is done. Some changes are also necessary to RBAC roles and definitions so you also have to prepare Active Directory (update the Exchange configuration) before you can install CU2. I was surprised to find that Setup forced me to reboot the server after running /PrepareSchema, but I guess Windows knows best. To make sure that I got the message, Setup also forced me to reboot all of the Exchange (multi-role) servers that I have upgraded to CU2 so far.
Some might worry about the number of schema updates required by Exchange over the last few years but I don’t because I think it a very good thing to have as many organizational and configuration settings in Active Directory as possible. However, we are still not at the stage where Exchange stores all its settings in a repository that survives updates and you can expect to have to apply changes to components such as Outlook Web App (OWA) pages after CU2 is installed.
For those who are interested in these things, the CU2 software version is 15.0.712.22 or just 712.22 when viewed through EAC (CU1 is 620.29). After the schema is extended, Michael Smith’s PowerShell one-liner reports the value of RangeUpper to be 15281. You can find the values for previous versions of Exchange here.
The functionality changes in CU2 range from bug fixes to changes based on experience of Exchange 2013 in real-life deployment (like increasing the maximum number of databases that can be mounted back to 100); managed availability probes and responders are also adjusted to make sure that they behave appropriately on production servers (see the EHLO post for details). Some engineering “rejigging” occurs in the area of high availability with the introduction of the Database Availability Group (DAG) management service, which seems to be an effort to remove the code that monitors and reports problems out of the replication service, leaving it to deal with the much higher priority workload involved in replicating transactions between mailbox servers within the DAG. There's probably more to this than meets the eye and I'll be certainly having a look into the new service in the coming weeks. In passing I’ll note that OWA seems faster and more responsive and has had its search functionality improved so that it’s easier for users to locate items that contain keyword hits.
Perhaps the most interesting change – and one that poses many interesting questions for the future – is the note at the end of the EHLO post that the Exchange product group is completing the work necessary to allow a Windows Azure server to host the witness server for a DAG. This is a small step and will probably not be a feature that receives extensive use, at least not in the early days until administrators gain confidence in the use of cloud components in high availability scenarios, but the really interesting thing is to speculate what other parts of Exchange might be moved to Azure over time (see my earlier report on this topic). Cue debates over your beverage of choice.
The normal health warning applies for CU2 – deploy and test first in a non-production environment to make sure that the software works with all of the quirks that exist in your deployment. Never deploy an update direct into production, unless of course you like living on the edge. Speaking of which, there’s still no sign of an Exchange 2013 edge server…
Follow Tony @12Knocksinna
