Exchange ServerName Points To Wrong Or Decommissioned Server


This post was promoted from the draft bin to production after a customer visit a couple of weeks ago.  When onsite we were looking at how the environment was configured.  The admins had written a series of scripts to determine the environment state which was excellent to see!  One thing that they had assumed though was that the ServerName attribute on a mailbox was where the database was currently mounted.  In this customer’s case they had 12 mailbox servers in the DAG and this data led them to believe that mailboxes were evenly balanced across all of the servers.

Let’s see what is going on, and what caused the issue.

 

Starting Configuration

In this lab we have Exchange 2010 SP3 RU5 servers.  A single Database Availability Group (DAG) exists which has three members  CONSEA-MB1, CONSEA-MB2 and CONDAL-MB1

No database copies are mounted on mailbox server CONSEA-MB1 apart from DB01:

Exchange DAG Lab - 3 Mailbox Servers With 3 Copies Of Database

Just to ensure that there are no MMC refresh issues, PowerShell shows the same:

Checking Mailbox DatabaseCopyStatus In PowerShell

Since only DB01 is mounted and active on server CONSEA-MB1, then we should expect to see the same number of mailboxes returned if we check both – no?

Get-Mailbox –Server CONSEA-MB1

Get-Mailbox –Database DB01

Let’s run both commands, and pipe to Measure-Object since that makes it easy to count.

Comparing Mailboxe Count Differences For -Server & -Database

Are the numbers the same?  Well, not so much…

In this case we are only off by one, but this is a tiny test lab and not representative of reasonable production environment.

What is causing this?

 

Floating Like A Butterfly, Fixed Like AD

The ServerName attribute is written to AD when the mailbox is created or moved into that database.  Which name is used?  The server which was hosting the active mailbox copy at that time.  The ServerName attribute is held in AD and is stamped on the user object.  We can see this on the below test mailbox:

ServerName Property Stored In AD as msExchHomeServerName

The ServerName value is not updated when the database is activated on another server.  If it were, then that would add considerable overhead to AD replication.  That would make the grumpy triangle people even more grumpy, and we don’t want that!

Even *IF* this value was updated and replicated by AD, the other issue is replication latency.  AD may take hours to replicate between AD sites.  This is far too slow for certain Exchange database tasks such as updating log generation values which is why we use the cluster database to ensure fast guaranteed updates for critical database information.

 

To illustrate, let’s activate DB01 on a different server, in this case CONSEA-MB2.  In the below screen shot you will see that DB01 was moved from CONSEA-MB1 to CONSEA-MB2.  Then we check to make sure that there are no other active databases on server CONSEA-MB1.  Finally we re-run the Get-Mailbox –Server cmdlet to see how many mailboxes are stamped with a ServerName attribute of CONSEA-MB1, and if that value has changed from the initial result of 30.

Does Moving Active Database Copies Change -Server Mailbox Count??

Has the count changed from the initial value of 30?

No it has not.  This shows that the attribute is not updated when a *-over event occurs in a DAG.

 

Moving Mailbox To Different Database

In the below example we shall move mailbox Test-100 from database DB01 to DB02.  The initial ServerName value is CONSEA-MB1.  DB02 is currently mounted on server CONDAl-MB1.  This is indicated in the red box below.   Note that once the move request completes, the ServerName value is updated with the name of the mailbox server which hosted the active copy of the database at that point –> CONDAL-MB1.

Moving Mailbox To Different Database Changes ServerName

Again, we see in the below example that activating another copy of the mailbox does not change the ServerName value.  Initially it was mounted on CONDAL-MB1, then moved to CONSEA-MB2.

Same Behaviour for DB02 - ServerName Does Not Update In DAG

 

 

ServerName Takeaway

In a DAG environment, the ServerName attribute becomes less useful as there are typically multiple copies of a given mailbox database which can seamlessly transition between multiple servers.  The ServerName attribute is not updated in AD when the *-over event occurs.

The ServerName value is stamped based on where the database was mounted when the mailbox was created or last moved.  It is possible to get it to update by running:

Set-Mailbox <user> –Database samedatabasename

Updated ServerName Attribute After Running Set-Mailbox

Note that we are setting the  same database to the user.  In the lower line the ServerName field has now been updated.

When determining how many databases are actually running off a given mailbox server in a DAG, it is necessary to see what databases are currently mounted on each mailbox server and then enumerate the mailboxes from there.  This could look something like the below one-liner:

 $(Get-MailboxServer | Get-MailboxDatabaseCopyStatus | Where-Object {$_.Status –eq “Mounted”} | Sort-Object) | ForEach-Object { Write-Host $_.DatabaseName (Get-Mailbox –Database $_.Databasename –ResultSize Unlimited).Count }

 

Please note that the above is one line, and it may wrap.

 

Cheers,

Rhoderick

Comments (4)

  1. Just in time… as always…
    Many thanks for sharing Rhoderick

  2. Groovy – glad it helped out Feras!

    Cheers,
    Rhoderick

  3. anonymouscommenter says:

    Thanks Rhoderick. Just yesterday I was staring at get-mailbox returns trying to figure out why over half of my users mailboxes were reporting back a server that had been decommed last year!

  4. anonymouscommenter says:

    Hi Rhoderick,
    I have a question regarding an upgrade from sbs 2011 to 2012 r2 standard and exchange 2013; the problem i’m facing is that the incorrect server is configured to the web based management console. It points to my sbs server instead of the new exchange server.
    Can you tell me how to change this?

Skip to main content