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.
So how to overcome this "by design", if You need the Server name, where the mailbox is currently really located ?
The current proposal for a solution is to use "get-mailboxstatistics <mailboxID> | fl Displayname, ServerName" or "get-mailbox | get-mailboxstatistics |fl Displayname, ServerName". If Displayname is too ambiguous, you may use Identity or PrimarySMTPAddress instead.
old stuff but good to remember
Also to add if we can check the value of the attribute "homemdb" on the mailbox it will be the dn of the database where the mailbox is residing.