Odd seeding behavior for an Exchange 2010 database copy

I run a virtual Exchange 2010 environment on my HP Elitebook 8530w laptop (8GB memory, SSD for the VM files). Usually things run along without a hitch but sometimes the USB connection to the SSD experiences a mild panic attack that causes it to disconnect from Windows. At that point the VMs go away and I start swearing, which is what happened today.

After I reconnected the SSD and rebooted all of the servers, I noticed that one of the Windows 2008 R2 servers was a sick puppy that wasn’t willing to do much except go into recovery mode. No problem, I’ll revert to a snapshot and all will be well as the databases on this server are replicated within a DAG. VMware duly loaded the most recent snapshot and booted the server. Some minor messing then occurred to reconnect the server back into the domain because it had lost synchronization. Windows needed to be reactivated too as it thought that a hardware change had occurred.

After all that, Exchange 2010 came back online and I noticed that the copy of the database on the server couldn’t synchronize with the active copy as Exchange had determined that there was too much of a divergence between the two copies for it to be able to fix things up. This was very logical because I use circular logging for these databases (to save space) and the transaction logs that would be necessary to correct the divergence were long recycled. Time to reseed the database copy, which I did with the Update-MailboxDatabaseCopy cmdlet (see screen shot).

Using Update-MailboxDatabaseCopy to reseed a database

No problems were recorded and the new database copy came online and was reported to be healthy. At least it was from EMS. On the other hand, EMC disdainfully refused to acknowledge the existence of any copy – active or passive – for the database, leaving a void where I expected to see some information.

Where have my database copies gone?

Interestingly, this only occurred for EMC running on the same server that I ran Update-MailboxDatabaseCopy. EMC was quite happy to list details of the database copies on all the other servers. I restarted EMC and the copies reappeared, so I concluded that this was a minor glitch in Active Manager on that server or the way that EMC fetches and displays information about copies. In either case, all is well and I’m up and running again as normal.

– Tony

You can learn much more about the Update-MailboxDatabaseCopy cmdlet and all of the other operations required to keep a DAG in good health in my Microsoft Exchange Server 2010 Inside Out book.


About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Exchange, Exchange 2010 and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.