Exchange's most annoying and confusing error message

The task of composing good error messages that make sense when displayed to end users (or Exchange administrators in this case) is probably not something that developers like doing. It's certainly less exciting than creating a new feature. And so we end up with candidates for Exchange's worse and most annoying error message. I propose the one shown by EAC (Exchange 2013) and EMC (Exchange 2010) when you attempt to delete a mailbox database that still has something it in. It's good that Exchange checks to stop you doing something silly, but boy that error message takes some reading...

Coding error messages and making sure that the errors are generated in the right place and at the right time is probably well down the list of “things I want to do at work” for software developers. I was never happy to spend time composing error messages and inserting them into code and I can’t imagine that the Exchange developers are too enthusiastic about the task either.

Which brings me to a debate about the error message displayed by Exchange 2010 and Exchange 2013 when you attempt to delete a mailbox database where a lingering vestige of something useful exists. Like an arbitration mailbox, for instance, or a public folder mailbox (Exchange 2013), or even an archive mailbox that is linked to a mailbox stored in another database.

Quite correctly, Exchange validates that it is OK to delete a database and won’t let you do it if something useful remains in situ, like an arbitration mailbox. You have to take action (remove or move the object to another database) and generally clear the decks for action before Exchange will proceed and no amount of fervent execution of the Remove-MailboxDatabase cmdlet will cause Exchange to budge. Which is nice.

To inform you that something needs to be done, both EAC and EMS output what has to be a candidate for the longest and most complex error message of all time. I don’t have a problem with the language as all the tenses seem to be correct, words spelt correctly, and the sentences don’t run on into each other. I just think that the set of things to be checked is excessive and that the error message is both cluttered and confusing. The list is:

  • Run Get-Mailbox –Database <DB> to get a list of the mailboxes that still remain in the database. Reading further on in the error text (wouldn't it be better to have the suggested action with the potential problem?), the direction is to disable the mailbox using the Disable-Mailbox cmdlet, which removes the Active Directory attributes that links a user account with the mailbox. It would be nice if advice was given to move the mailboxes as an alternate course of action. Preserving data rather than removing it is usually best until you're quite sure that the information is no longer required.
  • Run Get-MailboxPlan to get a list of all of the mailbox plans in the database. This is rather a silly piece of the error message because the on-premises version of Exchange don’t have mailbox plans and the Set-MailboxPlan cmdlet isn't available. The text belongs to its cloud cousin and is a good example of error text being reused in an unintelligent way. It's nice that Exchange 2013 uses a single code base for its on-premises and cloud variants but surely an old-fashioned IF-THEN-ELSE clause could be used to determine what variant is in use before deciding what error to output. 
  • Run Get-Mailbox –Database <DB> -Archive to get a list of any archive mailboxes that exist in the database. As Paul Cunningham pointed out some time ago, this command is not particularly helpful because it doesn't locate archive mailboxes connected to primary mailboxes in other databases (looks like a bug to me). Instead, you can run Get-Mailbox | Where-Object {$_.ArchiveDatabase -eq <DB>} | Format-List Name, which will locate any archives in the target database (however, because ArchiveDatabase is not a filterable property, the command is much slower, especially when large number of mailboxes have to be scanned).  If any archive mailboxes are found you’ll have to do something with them. The advice given is to disable the archive mailbox but you might like to move it too.
  • Run Get-Mailbox –Database <DB> -PublicFolder to get a list of any public folder mailboxes (Exchange 2013 only) in the database. Once again, you’ll have to move the public folder mailboxes to another database before continuing. The error message again advises that you can run Disable-Mailbox to disable any public folder mailbox that you might find, but you’d be well advised to check that the mailbox doesn’t contain any public folders first. Moving again seems a better option.
  • Run Get-Mailbox –Database <DB> -Arbitration to get a list of any arbitration mailboxes in the database. These are things like discovery search mailboxes and the mailboxes used for moderation. And you’ll clearly want to keep them around, so the advice provided is to move them using the New-MoveRequest cmdlet. On the other hand, if this is the last server in the organization and you’re on the countdown path to remove Exchange completely, you can run Disable-Mailbox –Identity <Mbx> -Arbitration –DisableLastArbitrationMailboxAllowed.

In summary, an administrator who simply wants to remove a mailbox database is confronted with directions about lots of things to check (some of which don’t exist in the on-premises world) and some incomplete advice about what they should do if they find that something is lingering in the database. It’s not a satisfactory situation.

What’s worse is that no indication is provided as to what object is causing Exchange to object. The administration is expected to follow the laundry list of instructions until they eventually hit the jackpot and find something to disable/move/delete. But even then, another offending object might be lurking in the depths that will prevent Exchange removing the database and cause a further round of checking to ensue.

And the silly thing is that Exchange knows the identity of the problematic objects. It just keeps that information to itself so that administrators can be sent on an orgy of PowerShell checking. Try running Remove-MailboxDatabase in verbose mode and you’ll see that the name of the object that causes Exchange to decline to remove the database is clearly shown (as in the case of the mailbox belonging to Kim Akers below).

The question therefore is why EMC or EAC can’t tell administrators exactly where the problem lies. And while they’re at it, perhaps the instructions given to rectify the situation might be cleaned up and rationalized? Something like:

You can't delete mailbox database <DB> until you remove the following objects:

Mailbox: Kim Akers
Archive: Tony Redmond (the primary mailbox is in database DB2

To solve the problem, you can either delete or move the mailboxes. Use EAC to do this or run the Disable-Mailbox (to remove) or New-MoveRequest (to move) the mailboxes.

As an interesting article about minimizing unreproducible bugs on the Google Testing Blog (thanks to Michael B. Smith) makes the point:

"Any error with impact to the user should be reported to the user with instructions for how to proceed. The information shown to the user, combined with data available to an engineer, should be enough to determine what went wrong."

It would be nice if Exchange was more informative when things go wrong with database deletion. I think I've made a good case for this error message to be my particular hate in Exchange. Maybe you have another candidate for the worst error message in Exchange?

Follow Tony @12Knocksinna

Discuss this Blog Entry 2

on Mar 17, 2014

It's kind of Microsoft to respond to this post with one of their own ( that tells us all the ways that pesky mailboxes of different types might get in the way of stopping you deleting a database. At least they then admit that "the experience here is not ideal and the relevant team is aware." Perhaps they might even now consider fixing the bug in Exchange 2013 CU5...

on Jun 12, 2016

I am in ABSOLUTE agreement with you. What exactly is wrong with the engineers at Microsoft anyway? You have to have an excellent suite of error sub-routines in order to conduct proper testing, and those routines must have been available now for MANY years. Exchange has always been the worse nightmare to install and fix. Now Exchange 2016 is even WORSE! It does not install correctly, and if it finds an issue with the FQDN or DNS to IP address problems, instead of helping you fix those issues, OR JUST FIXING IT AUTOMATICALLY, it just dies and doesn't function. Wow...with Windows 10, Exchange 2016 is one of the worse products MS has produced to date. Does anyone know of a MANUAL or FORCED way to get this version off of our servers? We are just going back to Exchange 2007, which works fine.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.


Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×