PowerShell does not reflect the correct server for Mailboxes

By preparing tasks for a customer’s Enterprise Vault  I had to figure out on which Mailbox Database and on which Exchange server a user mailbox is located. However, the easiest way to figure this out is to use PowerShell.

For this case, I had to hit the following command to the Exchange Management console:

 

As we can see in the example on the picture below, the Mailbox should be located on the Exchange Server xxxx005

However, if we go now to the Exchange ECP and we check there the DAG databases is shows another result:

Honestly, this is confusing. To which output we need to believe now? Well from the logical point of view to the ECP output.

If we go back to the PowerShell output, we see that the Mailbox is located on the 16db03xxxx Mailbox database. This database is a DAG member and has multiple copies on several Exchange Servers. However, as we can see in the ECP, the active Database is running on the Exchange Server xxxx006.

 

By investigating on the Microsoft Technet, I have fond the following answer from the Microsoft Exchange Team:

“We got notified from customers, that the powershell commandlet get-mailbox in Exchange 2010 (see http://technet.microsoft.com/en-us/library/bb123685(v=exchg.141).aspx) and in Exchange 2013 (see http://technet.microsoft.com/en-us/library/bb123685(v=exchg.150).aspx) do not always return the correct ServerName  or ServerLegacyDn for the given mailbox. Those customers often rely for their backups or customized mailbox processes on the information, on which server a given mailbox is currently located.

We told our customers, that their findings are indeed true and  that these attributes, which are returned via get-mailbox are written only at special events, like at creation time of the mailbox or after a move mailbox has taken place. On a DAG the mailbox database can be owned by any of the possible owners of that database. Changing the possible owner of that database is considered to be a circumstance of making sure, that this database is healthy. At any time the smooth switch to a different owner is much more important than the update of all the properties of the mailboxes on that database. The update of the ServerName property with a mailbox comes with a certain performance penalty. Our product group decided therefore not to take that penalty for Database moves to a different possible owner.”

 

Well, good to know, but is there a solution or workaround for this problem? – I would say yes!

To get the right output from the Exchange Management Shell we can use the following command:

Or as an alternative

If Displayname is too ambiguous, you may use Identity or PrimarySMTPAddress instead.

As example here a possible output:

 

 

 

Photo by NeONBRAND on Unsplash

 

Leave a Reply

Your email address will not be published. Required fields are marked *