Because it’s been a while since Microsoft shipped Exchange 2013 CU9, today’s release of Exchange 2013 CU10 came as no surprise. After all, we have all become accustomed to the quarterly cadence of updates that are required to keep Exchange 2013 servers fully supportable, largely because the last few updates have been easily deployable and high quality.
The list of bugs fixed in CU10 is available online. There’s a lot of fit and finish fixes rather than “wow” problems in CU10, probably symptomatic of the growing maturity of the software three years after its original release. As is now the norm with cumulative updates, an Active Directory (/PrepareAD) update is required. To answer the inevitable question “why”, AD updates reflect things like new cmdlets and cmdlet parameters being introduced into the organization. In the case of CU10, the changes are to RBAC necessary for co-existence with Exchange 2016.
Which then brings us to the biggest news in CU10, because it lays the foundation for interoperability with Exchange 2016. You need to upgrade Exchange 2013 servers to CU10 before you can introduce Exchange 2016 into an organization. And if you have Exchange 2010 servers, they have to be upgraded to Exchange 2010 SP3 RU11, also released today. RU11 contains an important fix for the Information Store that prevents Store crashes when upgrading infrastructures from Lync Server to Skype for Business.
Exchange 2016 doesn’t support Exchange 2007 or earlier servers in an organization. This is what you’d expect as Microsoft has only ever supported interoperability with the previous two versions of Exchange.
Microsoft took the covers off Exchange 2016 at Ignite and the big story was all about the High Availability technology that was being transferred from Exchange Online to the on-premises version. Experience of beta builds since has shown that the code is more stable than is usually the case with the first release (RTM) of a new Exchange version. That could be because Exchange 2016 is very much like a service pack for Exchange 2013. In other words, Exchange 2016 is very much about evolutionary change rather than a brand new architecture.
That being said, some important differences need to be observed. For example, multi-role servers are now the only game in town and IP-less DAGs are the norm. But these are tweaks and reflect past changes (IP-less DAGs were introduced in Exchange 2013 SP1) or best practice (multi-role servers). Microsoft would very much like customers to base their Exchange 2016 deployments on their preferred architecture instead of exerting artistic license when laying out servers and other components. This is simply good sense. Think about it this way: using a proven recipe is a better way of baking bread than deciding to use a random combination of flour and water.
As you’d expect, there has been intense interest in Exchange 2016 at IT/DEV Connections this week. Many people came to find out whether they should deploy Exchange 2016. MVPs Jeff Guillet and Paul Robichaux did an excellent job in sessions to explain how to deploy and manage Exchange 2016. Now that CU10 is available and co-existence is possible, you can expect that Exchange 2016 will appear soon and deployments can begin.
Because Exchange 2016 is so like Exchange 2013, it seems logical to expect that deployments will happen faster than is the norm after a new version of Exchange appears. However, given the natural caution of on-premises administrators (who might have been bitten in the past) and the need to introduce Exchange 2016 in a managed fashion to IT infrastructures, I really don’t expect much to happen for a few months.
You can prepare for Exchange 2016 now by testing and then deploying Exchange 2013 CU10 and Exchange 2010 SP3 RU11. I’ll be interested in hearing early deployment stories. I honestly expect a better experience than we had with Exchange 2010 and Exchange 2013, but there’s no test like a real-life deployment to reveal lurking flaws. Let’s hope that few of those are encountered.
Follow Tony @12Knocksinna