Mailbox Anchoring in Exchange
With the latest Cumulative Updates for Exchange server 2013 and 2016 Microsoft has made a change to “Mailbox Anchoring”. What does this mean? Why did they do it? How will it affect me? Read on, and I shall attempt to explain.
What is Mailbox Anchoring?
Mailbox Anchoring is the process of connecting your session to the server that is currently hosting your mailbox. This is the standard behavior for client protocols like OWA. In other words, when you launch OWA your session is directed to the Exchange server that hosts your mailbox, no matter what Exchange server you were connected to by your load balancer.
That sounds simple enough, so what changed?
In the newest CU for Exchange 2013 (CU11) and Exchange 2016 (CU1 – due out in early 2016) Microsoft has added mailbox anchoring to the Exchange Management Shell (EMS) connection process. In other words, when you launch EMS your session is directed to the Exchange server that hosts your mailbox, no matter what Exchange server or client you launch EMS from.
That sounds simple too, so why the change?
The short answer is to ensure that administrators are always running commands on the newest version of Exchange. With the release of Exchange 2016, it is now possible to have Exchange 2013 and Exchange 2016 servers in the same load balanced pool. That means an EMS connection to Exchange during an upgrade could end up running on either version. Presumably the newest code is going to “know” how to interact with older code, but not necessarily vice-versa. This changes means that when an administrator deploys a new version of Exchange, he/she can move their own mailbox to that server and know they are running EMS against the newest version of the code.
I’m sensing a “but” coming…
BUT… this also mean that if the Exchange server hosting your administrator’s mailbox is down, you won’t be able to launch EMS to fix it. Microsoft assumes that your mailboxes should be hosted on databases that are part of a DAG so if one server does go down, your mailbox will be available on another server in that DAG. Unfortunately, in the real world, that is not allow how Exchange is deployed.
Backup a second, you said "administrator's mailbox"?
Yeah, I did. I know historically the guidance has been that Exchange administrators should not have mailboxes attached to their admin accounts. I guess that guidance has changed.
To be fair, if your administrator account does not have a mailbox this still works by using one of the arbitration mailboxes. Specifically the "SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c" arbitration mailbox is used, but that is not terribly important to our discussion here today. What's important is the guidance from Microsoft assumes that administrators have mailboxes attached to their admin accounts.
Back to your regularly scheduled blog post.
So what do I do if the server hosting my mailbox is down?
The good news is there is a way forward. You don’t actually need EMS to manage Exchange. You can actually load all the Exchange PowerShell cmdlets from a regular PowerShell session on any Exchange server, and work from there. You can log onto any Exchange server as a local admin and run the following command in PowerShell
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapInOnce again, it seems like there is a “but” looming…
BUT… doing so completely skips RBAC. That means ANYONE with just local admin rights on an Exchange server can do this and be able to run ANY Exchange commands they want. Don’t believe me? Try it out. Create a new account with no Exchange permissions at all, then give it local admin rights on a single Exchange server. Log in with that account and run the above command in PowerShell. Once that completes, run Get-Command and you’ll see every Exchange cmdlet listed. You’ll even see cmdlets listed that an Exchange Organization Administrator won’t see.
Got it, now sum up for me
In order to that administrators always run Exchange PowerShell commands on the newest version of Exchange in their environment, Microsoft has made a change to EMS that will force it to connect to the Exchange server hosting the administrator’s mailbox. This is great, unless that server is down. If the administrator’s mailbox is not online, the work around is to load the Exchange PowerShell snap in into normal PowerShell. Doing so will allow you to manage Exchange, but in the wrong hands this can be used to grant administrator’s access to cmdlets they should not be able to run.