One of the most common problems plaguing Exchange Server 2007 clustered mailbox databases is where a failover or cluster move succeeds, yet the database fails to mount on the new cluster node. As perplexing as this issue is, it usually stems from one of two fixable problems.
1. Insufficient permissions
If you’re running a clustered mailbox server on
If you can’t mount the database manually either, that could also be a permissions issue. It’s possible that the account you’ve logged in with also lacks the permissions necessary to mount the database.
To resolve the problem, first make sure that the service account is a member of either the Exchange Server Administrators (servername) group or the Exchange Organization Administrators group. Also, the cluster service account must be a member of the local administrators group on each cluster node.
After correctly setting the permissions, all the cluster nodes must be rebooted in a specific order. First, take your clustered mailbox server offline. Shut down the passive node, then the active node. Next, boot the active node, then the passive node. Finally, bring the clustered mailbox server back online.
2. Lost log files
A large number of lost log files may also be the reason behind a mailbox database mount failure. Exchange Server 2007 uses an auto-mount dial setting to determine how many log files it can afford to lose during a failover situation. The options are:
- Lossless – You cannot lose any log files.
- Good availability – You can lose up to three log files during a failover.
- Best availability – You can lose up to six log files during a failover.
To check the auto-database mount dial’s current setting, open the Exchange Management Console (EMC) and navigate to Server Configuration ->Mailbox. Select your clustered mailbox server, then click the Properties link in the Actions pane. This will display the server’s properties sheet. The auto-database mount dial is found on the properties sheet’s Clustered Mailbox Server tab.
If you suspect that you’ve lost an excessive number of log files, you should use the Get-StorageGroupCopyStatus cmdlet to determine the current state of your CCR cluster. If you’ve lost more logs than the auto-database mount dial allows, you can force a database mount with the Restore-StorageGroupCopy cmdlet.
The Restore-StorageGroupCopy cmdlet overrides the database mount dial settings. You can also use this cmdlet in conjunction with the –WhatIf parameter. Using this parameter shows you how the cmdlet affects the storage group without actually executing the cmdlet.
The Restore-StorageGroupCopy cmdlet does not actually mount the database, but removes the restrictions that prevented the database from mounting. After the cmdlet completes, you’ll need to mount the database using either the EMC or the Mount-Database cmdlet.
If the lost log files were already committed to the database on the previously active node, then the database copy on that server node must be reseeded.
To reseed the now passive cluster node, use the Suspend-StorageGroupCopy cmdlet. This cmdlet halts the storage group copy process. Next, rename the *.log, *.chk and *.edb files. Finally, restore the database backup, then restart the storage group copy process using the Resume-StorageGroupCopy cmdlet. This will force all the logs that have accumulated since the time of the backup to be copied to the passive node.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in October 2011