\u00a0<\/p>\n
As we can see in the example on the picture below, the Mailbox should be located on the Exchange Server xxxx005<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2018\/07\/AD084C49.png\")
<\/p>\n
However, if we go now to the Exchange ECP and we check there the DAG databases is shows another result:<\/p>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2018\/07\/8AF1F5B6.png\")
<\/p>\n
Honestly, this is confusing. To which output we need to believe now? Well from the logical point of view to the ECP output.<\/p>\n
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.<\/p>\n
\u00a0<\/p>\n
By investigating on the Microsoft Technet, I have fond the following answer from the Microsoft Exchange Team:<\/p>\n
\u201cWe 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\u00a0 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.<\/span><\/p>\n We told our customers, that their findings are indeed true and\u00a0 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.\u201d<\/span><\/p>\n \u00a0<\/p>\n Well, good to know, but is there a solution or workaround for this problem? \u2013 I would say yes!<\/p>\n To get the right output from the Exchange Management Shell we can use the following command:<\/p>\n Or as an alternative<\/p>\n If Displayname is too ambiguous, you may use Identity or PrimarySMTPAddress instead.<\/p>\n As example here a possible output:<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n \u00a0<\/p>\n Photo by\u00a0NeONBRAND<\/a>\u00a0on\u00a0Unsplash<\/a><\/p>\n \u00a0<\/p>\n","protected":false},"excerpt":{"rendered":" By preparing tasks for a customer\u2019s Enterprise Vault\u00a0 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: Get-Mailbox […]<\/p>\n","protected":false},"author":1,"featured_media":2236,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[1923,2,3],"tags":[],"class_list":["post-2235","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-microsoft-365","category-exchange","category-powershell"],"post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/2235","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2235"}],"version-history":[{"count":5,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/2235\/revisions"}],"predecessor-version":[{"id":5221,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/posts\/2235\/revisions\/5221"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=\/wp\/v2\/media\/2236"}],"wp:attachment":[{"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2235"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2235"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msb365.blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Get-MailboxStatistics
Get-Mailbox | Get-MailboxStatistics | select Displayname, Servername, *database*<\/pre>\n
![\"\"](\"https:\/\/msb365.abstergo.ch\/wp-content\/uploads\/2018\/07\/rffrh.png\")
<\/p>\n