Will Exchange 15 Require an AD Version Update?

My colleague, or perhaps co-conspirator, Tony Redmond recently wrote an interesting blog post about whether Microsoft should require an Active Directory(AD) upgrade for the next version of Microsoft Exchange Server(which, for brevity's sake, I'll call Exchange 15.)

Tony's basic argument is that the Exchange team is well justified if it chooses to require such an upgrade. He cites the age of Windows 2003 as a reason,along with the fact that removing support from Exchange for the Windows 2003 functional level would simplify the testing burden for the Exchangedevelopment team. I can't argue either of these facts: Windows 2003 is, in fact, ancient, and removing support for its version of AD would eliminate somedegree of compatibility testing that is now required. However, I disagree with the conclusion that Tony has reached. Here's why.

First, let's consider the typical customer who's running Windows 2003 AD. I think it would be fair to say that, for the most part, these customers are noton the cutting edge of IT. Accordingly, they're exactly the customers that Microsoft is most ardently pursuing for Office 365. Requiring customers toupgrade their internal AD infrastructure in order to migrate to Exchange 15 in Office 365 (or whatever it will be called after the Office 15 wave releases)is directly opposite to Microsoft's best interest.

Compare the choices available to the customer: Upgrade your AD infrastructure and migrate to Microsoft's cloud service (where the AD upgrade brings youminimal benefits, or else you would have done it sometime in the past 10 years) or don't upgrade your infrastructure and migrate to Google'sservice. That isn't a question Microsoft wants customers asking. Therefore, Microsoft should be working to provide the lowest-friction migration pathpossible.

It's true that there are some large enterprise customers (hello, US Navy, I am looking at you) who still make heavy use of Windows 2003. Most ofthese customers have their own upgrade cycles and requirements and are very unlikely to be in the initial wave of movement to Office 15, no matter whatMicrosoft would like. Requiring, or not requiring, an AD infrastructure upgrade isn't going to sway them one way or the other, so there's no advantage intrying to force them to upgrade their AD in order to deploy Office 15.

Tony's second argument is that eliminating the requirement for backward compatibility will ease the test burden on the Exchange team. Although it's truethat eliminating compatibility with Windows 2003 functional level forests would eliminate the requirement for some test coverage, modern testing of largeenterprise products such as Exchange is virtually always automated. Eliminating those tests just means running fewer CPU cycles-not a huge savings.

The burden in testing often comes from having to identify and then fix the bugs that you find. Here it's important to understand that the AD access code inExchange appears to be one of the most mature, best understood, and most robust components of the product; it hasn't undergone the extensive changes thatwe've seen in, for example, the Information Store or the Client Access server role. Obviously, I'm not privy to the detailed statistics on testrequirements and results for Exchange, but I would be willing to bet Tony a steak dinner that the number of flaws found in directory accessversion-over-version is already very small. That means that any savings realized from eliminating backward compatibility would likewise be very small.These savings from cutting Windows 2003 AD compatibility have to be balanced against the perception that Microsoft is making things easier for itself atthe expense of customers-a perception that, once taken root, can be hard to get rid of.

Now let me switch gears and make an argument for keeping compatibility. First off, Microsoft already has a rich reputation for requiring wholesale updatesfrom version to version. It's safe to assume that Exchange 15, like its predecessors, will require us to move mailboxes from one server to another insteadof supporting a direct in-place upgrade. That method is perfectly OK; after many hours spent troubleshooting in-place upgrades of various operating systemsand applications, I'm happy never to have to deal with that problem again. However, it's fair to argue that the rip-and-replace reputation is somethingthat Microsoft can do without, especially because that perception puts them at a competitive disadvantage against companies such as Google or even IBMLotus who impose no such requirement.

You might notice that above I began mentioning "Office 15" instead of just focusing on Exchange 15. It's certainly possible that some other Office15 product will force an AD version upgrade; it's hard for outsiders to tell how closely coordinated the various product teams at Microsoft really are. Inthis case, it appears that they are working together very closely to produce a unified set of server applications, but we shall see whether that appearancematches reality.

Of course, Microsoft hasn't announced any plans one way or another. In the past, decisions such as the move to an exclusively 64-bit world have been drivenby hard data gathered by the engineering, marketing, and customer experience (CXP) teams. I have no reason to think this decision is any different;perception and savings are important factors, but not necessarily the only, or even most important, ones. There are technical issues to consider, too.As Tony points out, Exchange 15 might require a schema update, in which case that update might require a functional level updatealso. I don't object to that; if there are valid technical reasons why an upgrade is required, then customers get to choose whether they want to accept theburden of an upgrade in exchange for the benefits of moving to Exchange 15. However, if there's no technical reason to require an AD version update, Ithink Microsoft would only be hurting itself to require one.

The good news is that we should know the answer to this question relatively soon as Microsoft releases more details of Exchange 15. Speaking of which:Early registration for the Microsoft Exchange Conference (MEC) closes May 18. Microsoft is promising to reveal a lot about Exchange 15 there, so I'm surethat by then-or shortly thereafter-we'll know Microsoft's intentions.