Database copies fail to display after upgrading to Exchange 2010 Service Pack 1
Recently some customers have experienced an issue where database copies do not display when using the Exchange Management Console after upgrading to Exchange 2010 Service Pack 1. When attempting to view database copies using the Exchange Management Shell no issue is displayed.
Database copies can be viewed in two locations.
The first location is under Organization Configuration –> Mailbox –> Database Management. In this view when an administrator selects a database from the list, the Database Copies displayed in the bottom portion of the display are missing ALL or SOME copies for a given database. Here is an example of a 4 node DAG with a database replicated to all 4 members:
All Database Copies Missing:
Some Database Copies Missing:
Expected output showing all database copies:
The second location is under Server Configuration –> Mailbox. By selecting a server with the mailbox role you can view the individual database copies assigned to that server. Here is an example of database copies missing from the server:
Whether all database copies are missing <or> some database copies are missing the Exchange Management Shell command Get-MailboxDatabaseCopyStatus always returns accurate information. Here is a copy of Get-MailboxDatabaseCopyStatus *:
When any Exchange role is installed on the server (with exception of Edge transport) the hostname of the server is written into the Exchange configuration container within Active Directory. In this case the server name was established with a lower case. It was established in the container with a lower case because the hostname of the server, which was established during setup, was established with a lower case name (or a portion of the name lowercase).
In reference customers running HOSTNAME <or> reviewing the full computer name in server management showed that all or a portion of the name was lower case.
The Exchange Management Console code incorrectly compares case when comparing a database copy against a server name. This causes the console to not display all the valid database copies.
Let’s step through an example.
In this example there is a four node DAG. The server names are as follows:
Dag-1
dag-2
DAG-3
DAG-4
You can verify these server names by running get-databaseavailabilitygroup –identity <DAGName> | fl name,servers
[PS] D:\>Get-DatabaseAvailabilityGroup -Identity DAG | fl name,servers
Name : DAG
Servers : {DAG-4, DAG-3, dag-2, Dag-1}
When looking in the management console, and selecting any database replicated to all four members, the only copies that will be displayed are on nodes DAG-4 and DAG-3.
When the Exchange Management Console draws the database copies pane, it compares the host server name of a database copy to the server name of a database copy status. This comparison is case sensitive. Let’s take a look at a database copy that fails to display when viewing the copies for DAG-1.
(Get-MailboxDatabase –identity <NAME>).databasecopies | fl hostservername
[PS] D:\>(Get-MailboxDatabase DAG-DB0).databasecopies | fl hostservername
HostServerName : Dag-1
HostServerName : DAG-3
HostServerName : DAG-4
HostServerName : dag-2
(Get-MailboxDatabaseCopyStatus <NAME>\<Server>).mailboxserver
[PS] D:\>(Get-MailboxDatabaseCopyStatus DAG-DB0\DAG-1).mailboxServer
DAG-1
In this case DAG-1 != Dag-1 and therefore the copy does not display in the management console.
Let’s take a look at a copy that does display.
(Get-MailboxDatabase –identity <NAME>).databasecopies | fl hostservername
[PS] D:\>(Get-MailboxDatabase DAG-DB0).databasecopies | fl hostservername
HostServerName : Dag-1
HostServerName : DAG-3
HostServerName : DAG-4
HostServerName : dag-2
(Get-MailboxDatabaseCopyStatus <NAME>\<Server>).mailboxserver
[PS] D:\>(Get-MailboxDatabaseCopyStatus DAG-DB0\DAG-4).mailboxServer
DAG-4
In this case DAG-4 == DAG-4 and therefore the copy does display in the management console.
Unfortunately at this time we can only recommend that database copies for missing servers be managed using the Exchange Management Shell. It is not recommended to attempt to modify the active directory at this time to overcome this issue.
At this time we are filing the necessary bugs to get this permanently corrected without modifying server names. I will update this blog as this process progresses.
=======================================
Update 10/10/2010
This issue is currently scheduled to be corrected in Exchange 2010 SP1 Rollup Update 3.
=======================================
Comments
Anonymous
January 01, 2003
@WorkingHardinIT: Yes it has and this fix is included. TIMMCMICAnonymous
January 01, 2003
@Shafiq...
You should open a support case.
TIMMCMICAnonymous
January 01, 2003
@Gulab You should ensure that your clients know how to review copy status using the Exchange Management Shell. TIMMCMICAnonymous
January 01, 2003
@Erwin: The update I posted to the blog post on 10/10/2010 shows we expect the fix to be included in Exchange 2010 SP1 RU3. TIMMCMICAnonymous
October 05, 2010
The comment has been removedAnonymous
December 29, 2010
I face exactly the same problem. Are there any news about fixing this ?Anonymous
March 08, 2011
Heads up people, E2K10SP1 Rollup 3 has been released today see the ExchangeTeam Blog at msexchangeteam.com/.../458566.aspx andAnonymous
September 21, 2014
Hi all,
Do you have any idea why this things happen even my Exchange server is Exchange 2010 SP2?