Exchange mailbox anchoring runs into stormy waters

It's nice to be wise all the time. I wish I was wise even 50% of the time. And when it comes to mailbox anchoring, I was just dead wrong. But I wasn't the only one as the collective wisdom of the Exchange engineering group made a bad call here too. The new approach worked wonderfully except when introduced to the acid test of customer deployments. It's another example where stuff that is just right for the cloud falters on-premises. But Microsoft has done the right thing and reversed course. Better that than trying to force something through that would just cause disruption and pain...

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=” 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

Discuss this Blog Entry 1

on Jun 2, 2016

Hybrid environment with 2 Exchange 2013 servers–Multi Role and Office 365. The last update I did was from CU3 to CU7. First server went without a hitch. Second server–not so much. It failed due to the issue of 2 connectors being configured as Hub Transports. Got them switched over to Frontend Transports and the CU7 update installed fine. Getting ready to go from CU7 to CU12. I have 2 connectors that are still configured as Hub Transports–even after the CU7 update. One is labeled as a Client Proxy and the other is labeled as Default . The same goes for the second Exchange Server–same 2 connectors. I did not do the original configuration these servers so I’m not sure if those are default connectors of custom connectors.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.


Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×