The seemingly simple task of deleting an Exchange Server database can sometimes be less than simple. I've seen...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
a number of situations in which Exchange Server appears to have trouble letting go of unwanted databases. So what do you do when you can't delete a database?
The most common cause for this problem is that Exchange Server won't allow you to delete a mailbox database if that database contains an existing user mailbox. Determine which mailboxes exist within the database and then move those mailboxes to a different database.
To get a list of the user mailboxes that exist within a database, enter the following command into the Exchange Management Shell, but replace <database name> with the actual mailbox database name:
Get-Mailbox –Database "<database name>"
If you determine that the database contains user mailboxes, you can issue a move request for those mailboxes by using this command:
Get-Mailbox –Database "<database name>" | New-MoveRequest –TargetDatabase "<destination database name>"
Exchange Server 2013 also makes use of public folder mailboxes. To remove a public folder mailbox, you'll use the same method as you do to remove user mailboxes, but you'll need to use the PublicFolder switch. For example, if you wanted to see a list of public folder mailboxes, you would use the following command:
Get-Mailbox – Database "<database name>" –PublicFolder
Similarly, use this command to move a public folder mailbox:
Get-Mailbox –Database "<Database Name>" –PublicFolder | New-MoveRequest –TargetDatabase "<target database name>"
Notice that I didn't have to use the PublicFolder switch in the New-MoveRequest cmdlet.
It's not just user mailboxes and public folder mailboxes that can be problematic. Archive mailboxes can also cause problems. Exchange Server tries to help you by showing an error message that actually lists the command used to view a list of archive databases. The command Microsoft provides is:
Get-Mailbox –Database DatabaseID –Archive
However, this command doesn't always work as it should. A workaround is to run the Get-Mailbox cmdlet and filter the output based on the ArchiveDatabase attribute. This means compiling a list of mailboxes where the archive database attribute matches the name of the database you're trying to delete.
As an example, imagine you need to delete a database called "DB1." If you wanted to see a list of all the archive mailboxes within the database, you could use a command like this:
Get-Mailbox | Where-ArchiveDatabase –eq "DB1"
Moving mailboxes after they've been identified
Identifying the archive mailboxes is only the first step in deleting an Exchange Server database. Once those mailboxes have been identified, they need to be moved.
Once again, this can be accomplished using a move request. The New-MoveRequest command can be appended to the command that was used to identify the archive mailboxes. The full command might look like this:
Get-Mailbox | Where-ArchiveDatabase –eq "<database name>" | New-MoveRequest –ArchiveOnly –ArchiveTargetDatabase "<target database name>"
Notice that this time the move request used the ArchiveTargetDatabase switch instead of the TargetDatabase switch. We also used the ArchiveOnly switch.
Once you remove the mailboxes from a database, you should be able to delete the database from the Exchange Administrative Center. However, because you are already in the Exchange Management Shell, it might be easier to remove the database using the command line:
Remove-MailboxDatabase –Identity "<mailbox database name>"
The key to being able to remove a mailbox database is to make sure there are no mailboxes in the database. Although this tip focuses on moving mailboxes to another server, you can delete the mailboxes using the Remove-Mailbox command.
About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.