Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Exchange's most annoying and confusing error message
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.
ITPro Today
February 18, 2014
6 Min Read
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 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 -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 } | 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 -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 -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 -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 until you remove the following objects:Mailbox: Kim AkersArchive: Tony Redmond (the primary mailbox is in database DB2To 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
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
