Exchange mailbox anchoring runs into stormy waters

When Microsoft announced that Exchange 2013 CU11 and Exchange 2016 CU1 would implement “mailbox anchoring”, a new way of connecting Exchange Management Shell (EMS – or PowerShell if you like) sessions to Exchange servers, I weighed in with some thoughts on the topic and outlined why I thought the new approach was a good idea.

Sure, there were a few obvious issues that needed to be worked out, like the need to move arbitration mailboxes to a server running the latest version of Exchange and the potential for poor EMS performance over extended links. But overall I thought the change made sense.

How wrong I was. And as it turns out, how wrong Microsoft was to implement a change that makes perfect sense in the centralized highly regimented world of Exchange Online in its on-premises software. Just how bad things turned out can be gauged by problems reported in the TechNet forums by people who attempted to deploy Exchange 2013 CU11.

A more succinct assessment can be found in this January 6 post by MVP Andrew Higginbotham, who should know what he’s talking about as he works on the support coalface for DELL. I’ve heard Microsoft personnel say that “they’ve heard of Andrew’s blog”. I bet that they have. It might have been the tipping point for them to take action.

To be fair to Microsoft, they have fessed up to the problem and reversed course. Exchange 2013 CU12 will now revert to the previous mechanism and Exchange 2016 CU1 will do likewise. Even if it is flawed in some respects, the old mechanism worked for years and it’s wise to go back to square one to figure out how mailbox anchoring can be implemented for on-premises servers.

As Ross Smith IV points out in the EHLO blog announcing the reversal in strategy, you can use the new method of mailbox anchoring by specifying a server FQDN as the target for remote PowerShell to connect. That’s probably easier than another suggested approach, which is to be specific about the version of Exchange that must be running on a server within a load balanced namespace. Passing a version number like “ExchClientVer=15.0.225.0” is so easy to a) remember and b) type.  The other two methods Microsoft suggests are to use session affinity for remote PowerShell sessions or to remove servers running old versions of Exchange from the load balanced pool. I’m all in favor of decommissioning old servers, but it can be hard to do this at times.

Overall, I think it best to specify a server as the target for remote PowerShell sessions. That is, as long as the target server is running the most recent version of Exchange, which is what you want to happen. Remember, newer servers know about old stuff whereas old servers lose their mind and know nothing of how a newer version of Exchange operates.

Good as the news of the reversal is, the question might be asked how such a change managed to pass all of Microsoft’s testing that’s designed to mimic the environments that Exchange might meet in the hands of customers. There’s no good answer to this question because it’s likely that mailbox anchoring passed all tests with flying colors, if only because it is genuinely hard to recreate the many varied ways that Exchange is deployed and operated in the field.

Complex software like Exchange is always exposed to the potential that a change which seems to make sense in the design phase is proven to be shakier when exposed to the pressures of production. Testing is supposed to catch the problem before customers see it but didn’t in this case. We live in a flawed world.

As for me, I guess I should have listened to the curmudgeons who poured scorn on mailbox anchoring after the EHLO post appeared. MVPs like Jeff Guillet, Michael B. Smith, and Ed Crowley predicted problems and were proven right. They’ll say that I should listen to them more carefully in the future. Perhaps I should.

Follow Tony @12Knocksinna