CU | EighTwOne (821)

As most of you probably know, last week was TechEd North America. The sessions on Exchange 2013 did disclose some changes for Cumulative Update 2 (CU2), which – according to the announced CU cadence – should arrive somewhere in the summer, most likely July. For those who didn’t follow my Live Tweeting from the event, here’s a quick summary of the announced or probable changes for CU2.

Restoration of 100 DB Limit
Exchange 2013 CU2 Enterprise Edition will bump the limit for the number of database per server from 50 to 100. The initial limit to 50 for Exchange 2013 RTM (and CU1) is said to be chosen due to performance reasons, but many customers complained they want to host more databases per server. For CU2, Microsoft made changes which enable increasing this limit to 100 again. Perhaps the customers complaining transitioned from or are currently running Exchange 2010, and are facing having to introduce additional servers to host an equal number of databases. In such cases, be advised that regardless of this increased limit, Exchange 2010 and 2013 are not directly comparable and you should utilize the Exchange 2013 Server Role Requirements Calculator to size your Exchange 2013 environment (an update will follow as soon as CU2 becomes available). An important side note to keep in mind with all this is that adding (or removing) databases in Exchange 2013 requires a restart of the Information Store service, so you might prefer maximizing the number of databases from the start, not when required to, so you’ll avoid having to shut down services or having to move mailboxes around to comply with your SLAs.

DAG Management Service
The to be introduced MSExchangeDAGMgmt service will offload the Replication service by hosting the Replication Service MonitoringComponent, providing information on health status, logging events in the same location MSExchangeRepl used to, i.e. Application Eventlog using the same Crimson channel, but still using MSExchangeRepl as source.

DAG Witness Server in Azure (possibly!)
When you’re an Azure subscriber, a feature possibly included in CU2 will allow your DAG Witness Server to be located in Azure. This allows for example customers with 2 physical datacenters to utilize automatic site fail-over, as automatic site fail-over normally requires a 3rd well connected datacenter for hosting the Witness Server. From an Azure perspective, the Witness Server will be single File Server on Azure IaaS VM or two File Servers using persistent VMs with XStore shared storage. Note that extending Active Directory permissions to the Public Cloud is required for this option.

Responder Throttling per Group
Responders are part of Exchange 2013′s Managed Availability, and define if and how to act on generated alerts, e.g. restart a service or take a Mailbox server out of service. In CU2, several responders will be throttled per group, e.g. DAG, instead of per server.

ARR Support
Not CU2 related, but it was announced that support for ARR, which stands for IIS Application Request Routing, is coming for Exchange 2013. With the discontinuation of TMG, customers are looking for alternatives to publish their Exchange 2013 (or Lync web services) and ARR is one of them, often used because it utilizes IIS and is free despite it lacking some of TMG’s features. A clue for this could lie in one of the features announced for Windows Server 2012 R2, which will contain a Web Application Proxy, which basically will be an HTTP reverse proxy aimed at publishing corporate resources for access from the public network.

Few days ago, the Exchange Team published their intentions for Exchange 2013 regarding update schemes (or as Microsoft calls it, servicing). While the article describes the policy with a Q&A section at the bottom, there are still some grey areas. In this blog, I’d like emphasize on some elements and point out those grey areas.

As you probably read before, with Exchange 2013 the Rollup packages will be replaced by Cumulative Updates (CU), a name change probably inspired by Lync’s Cumulative Update packages. But it’s more than just a name change and admins or people involved managing releases should become familiar with the new policy as it will have some features that you don’t want to get surprised by.

One of the major changes in my opinion is that there will be one team working on the product; code bases for on-premises Exchange and Exchange Online (Office 365) will brought up to par. A small change is that Microsoft will first implement – or dogfood – the Cumulative Update in their Office 365 environment after while it will be made available for on-premises or hybrid deployments. While this may improve the quality of the Cumulative Update, not all kinds of deployments will be tested so it’s no warranty. However, looking at the current situation with Office 365, it may put stress on Microsoft procedures as there are already big variations between the various regions regarding Exchange Online implementations as well as Exchange Online and the on-premises version.

It’s the intention Cumulative Updates will be released on a quarterly basis. Each Cumulative Update will consist of a full installation set, so for example you can install Exchange 2013 Cumulative Update 2 straightaway whereas with Rollups you had to implement the Service Pack level prior to applying the related Rollup. So, this is a big convenience when for example installing greenfield scenarios or adding systems.

However, unlike Rollups you can’t uninstall a Cumulative Update once it has been installed. This could worry people, looking back at the qualify of some past Rollups which were pulled, rereleased and in some rare cases pulled and rereleased again. But since Microsoft will now implement Cumulative Updates first, bad Cumulative Updates will become Microsoft’s problem first, not yours as it seemed to few people with some of those Rollups.

Security updates will become Cumulative Update bound, meaning they are to be installed on a specific Cumulative Update. However, there can be two supported Cumulative Update “active” at a time, so I assume security updates can be installed on both (unless Microsoft will be making two versions of each security update). The next Cumulative Update will include security updates released since the previous Cumulative Update was released. However, it might be that security updates won’t make it in the a cumulative update because of the freeze period, the period before releasing the Cumulative Update when no more updates will be added, and one needs to wait for the Cumulative Update to be released or install the security update, wait for the Cumulative Update, install the Cumulative update and reinstall the security update, in which case you might prefer waiting for the Cumulative Update. Some might rushing (security) updates won’t harm you, but remember KB2624899 fixing the IE9/MMC issue, the initial EX2010SP2RU5 which caused DAG issues or KB2750149 which broke the WS2012 Fail-over Cluster snap-in and required KB2803748 to fix the issue. Yes, Microsoft will implement Cumulative Updates first but this will also raise the expectations set on Microsoft’s internal Quality Control enormously. They don’t want to end up in a situation releasing a faulty Cumulative Update to public, since it will be impossible to uninstall. Then again, nobody said Cumulative Updates would make the best practice of testing and accepting updates before implementing them in production environments obsolete.

A major change is that Cumulative Updates will be supported for 3 months after the next Cumulative Update is released. Because Cumulative Updates are to be released quarterly, this sets the support-window of a Cumulative Update (or plain, non-Cumulative Update) to 6 months. This may seem long, but I know a lot of companies will have an issue with this window because their test and acceptance periods easily transcends half a year, especially if schema updates are involved (yes, Cumulative Updates can require schema updates). And don’t forget about cases where customers adopted a building block model where they will need to test that Cumulative Update against their Operating System building block with all the additional components, like Anti-Virus, Backup agents or Management software involved.

Finally, an odd element in this scheme are the Service Packs of which Microsoft said they will be getting released. But where in the past only Service Packs could embed Active Directory schema updates, that’s also something a Cumulative Update might require, making Service Packs effectively an Über Cumulative Update.

Feel free to share your thoughts in the comments below.