Tuesday’s EHLO post by Rob Whaley, a well-known Exchange guy who works on beta releases of the on-premises and cloud products, is all about how a remote PowerShell session connects to a mailbox on an Exchange server. Or, to use the term now popularized by the post, “mailbox anchoring”. I confess ignorance on the point as I was heretofore unaware of such a nautical reference in the context of Exchange.
In any case, it’s all to do with how Exchange connects an inbound client connection to the right mailbox. Most of the time, it’s a matter of connecting a user to their mailbox. Exchange does this by querying Active Directory to retrieve the GUID (a unique pointer) to the mailbox and then uses the GUID to query the Active Manager process to discover what server is hosting the active copy of the database that holds the mailbox. Active Manager is responsible for tracking database transitions within Database Availability Groups. Overall, the scheme works very well.
However, the problem that the Exchange development group sees is that the Exchange Management Shell (EMS) behaves differently. As the post explains, when you start EMS, a remote PowerShell session is initiated that connects to the local Exchange server or another available server within the organization. Typically, the connection doesn't stray too far and EMS end up being connected to a local server.
The change announced on Tuesday is that starting with Exchange 2013 CU11 (also released on Tuesday) and Exchange 2016 CU1 (due in early 2016), EMS sessions will use mailbox anchoring and follow the same logic as all other client protocols – MAPI, OWA, ECP, EWS, and so on.
Apart from rationalizing the situation so that all protocols use a common approach, the Exchange development group want to ensure that EMS sessions are directed to servers that run the highest available version of Exchange within the organization.
The logic here, which I think is reasonable, is that newer versions of Exchange feature upgraded cmdlets that EMS can use. The danger cited is that if you connect to an old version of Exchange and run a cmdlet, that code might not support all of the properties of objects that you want to manage – or even contain bugs. It’s a general rule that newer versions of EMS can manage older Exchange objects whereas old versions of EMS won’t know about new cmdlets, parameters, or objects.
Not many “regular” people run PowerShell as this is a domain where administrators and programmers hold sway. It’s reasonable to assume that these folk will have their mailboxes on servers running recent software as the usual case is that the IT department and other technical people test new versions.
It’s possible that administrators don’t have Exchange mailboxes. In these instances, EMS connects to the arbitration mailbox named SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c (that name simply trips off the tongue) and if that mailbox is unavailable, one of the other arbitration mailboxes is used. For this reason, Microsoft says that the arbitration mailboxes are located on a server running the most recent version of Exchange.
In effect, if you install Exchange 2016 into an existing Exchange 2013 or Exchange 2010 organization, Microsoft’s strong recommendation is to move the arbitration mailboxes and all the mailboxes belonging to anyone who uses EMS to a database hosted by an Exchange 2016 server. As noted above, this is something that you might do anyway, but now Microsoft is making the case that it is the way to ensure that EMS sessions created to manage the Exchange organization always run the most recent code.
The EHLO post contains details about how to move the arbitration mailboxes using EAC, but seeing this is all about PowerShell, you might like to use EMS and issue the command:
Get-Mailbox –Arbitration | New-MoveRequest –TargetDatabase ‘DB on New Server’
Just because the Exchange development group makes a change does not mean that everyone agrees with the new approach. This is true in this instance as a number of experienced MVPs have pointed out the problem that might now occur if the databases holding administrator mailboxes and the arbitration mailboxes are unavailable for some reason. Another comment is that EMS performance might not be sparkling if you are currently located away from the datacenter that hosts your mailbox. I guess this could be true, but most of the time PowerShell performance over an extended link is acceptable, especially if it's only a matter of running a few commands to check things out.
If a disaster happens and mailboxes are unavailable, Microsoft recommends that you should start a PowerShell session and add the Microsoft Exchange snap-in in order to be able to run the Exchange cmdlets using the same procedure as required if you want to manage Exchange 2013 servers that have only the CAS role installed (see the Exchange 2013 release notes) because EMS only runs on Exchange 2013 servers that support the mailbox role. The command to load the snap-in is innocuous:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
However, the problem that arises is that when you add the snap-in to a PowerShell session, no role-based access control (RBAC) validation is performed to restrict the user to the cmdlets and parameters they are allowed to run based on their membership of Exchange management role groups. This might not matter if the user is a member of the all-powerful Organization Management role group and can basically do anything within the organization, but it might cause a problem for someone who holds fewer permissions. It's another item to test in your disaster recovery plans.
Update 6 Jan 2015: Andrew Higginbotham, a well-known speaker at IT/DEV Connections and troubleshooter extraordinaire for Dell Support, has published a blog post describing some of the issues that he's encountered with customers who have deployed Exchange 2013 CU11 and run into some problems with mailbox anchoring.
In any case, hopefully you are never in the situation where administrative and arbitration mailboxes are inaccessible. If they are, perhaps you will have other problems to worry about than a lack of RBAC. And of course, if you use Exchange Online, don’t worry because you don’t get to vote on this kind of stuff as EMS sessions in the service already use mailbox anchoring.
Follow Tony @12Knocksinna
