NonExistentMailboxException can simply mean that the mailbox in an inconsistent state

Here’s an issue that’s actually very easy to investigate and fix, but might get you puzzled if you are not looking in the right place. The symptoms were that several users were suddenly unable to get free/busy information, configure OOO, get MailTips, etc. Autodiscover was failing with 401 error; trying to display OOO settings resulted in the familiar “Your Automatic reply settings cannot be displayed because the server is currently unavailable. Try again later.” error; fetching free/busy info resulted in “No information. No free/busy information could be retrieved. Your server location could not be determined. Contact your administrator.”

Pretty standard Autodiscover/EWS issue you might say. But to make things a bit more interesting, the following error was thrown by OWA when trying to access the mailbox:

So OWA gives NonExistentMailboxException, charming. Yet the mailbox is up and running in Outlook. Luckily, PowerShell comes to the resque: any action against the affected objects resulted in the following warning:

WARNING: The object bla bla has been corrupted or isn’t compatible with Microsoft support requirements, and it’s in an inconsistent state. The following validation errors happened:
WARNING: Cannot calculate value of property “CountryOrRegion”: “Cannot parse a Country/Region from the ISO-3166 2-letter country/region code “AP”, country/region code “0” and friendly name “Hong Kong”.”.

Well, once you know what the actual problem is, the issue is very easy to fix – you just have to make sure that the relevant attributes are configured as expected. In this particular case, the Country related attributes (c, co, CountryCode) needed to be updated as per the ISO 3166-2 recommendations.

Still, it would be nice if we had somewhat better feedback, such as proper error message in OWA or some sort of visual clue in the EAC. Granted, once you switch to PowerShell, you are bound to find the issue – even listing the object will give you the warning. Get-User, Get-Recipient, Get-Mailbox, anything else you try will set you on the right track. One more reason to stick to PowerShell I guess 🙂

This entry was posted in Exchange Online, Office 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *