Error 500 when downloading/accessing OAB in Exchange 2016

We’ve just finished migrating all of our users from a legacy AD forest with Exchange 2010 into a whole new AD forest with Exchange 2016.

During the initial deployment of Exchange 2016 a new mailbox store was created, the existing system mailboxes were migrated (mailbox move) to the new store and the default Exchange 2016 store was deleted. We think our OAB broke at this point.

The behavior we were seeing was Outlook clients perpetually saying “Updating Address Book”, slow performance in Outlook where previously there wasn’t, delayed e-mail coming into mailboxes.

If users went into “C:\Users\%username%\AppData\Local\Microsoft\Outlook\Offline Address Books” they either had nothing or a old copy from our previous Exchange 2010 deployment. If they closed Outlook, purged the contents of “Offline Address Books” they would never be re-created because the OAB would never download from Exchange.

I’m assuming you’ve got everything else configured correctly on your end at this point. Things like Internal/External URLs, SSL certificates, yadda.

First thing first was to check if the OAB was on Exchange (I’ve redacted some information with *’s):

The lines that mattered here to me were:

  • Guid
  • LastTouchedTime

As you can see this OAB has never been touched which means to me it’s never been updated or created.

Using the GUID I checked to see what IIS had to say about the OAB:

  • https://mail.mydomain.com/OAB/28a57cb5-b2c8-442a-81f3-a48a05f9ab7b/oab.xml

Loading this URL prompted me for a login, good so far, entered my domain credentials and got this error:

After this I manually checked each of our Exchange servers (we have 3) to see if they all gave the exact same Error 500. They did:

  • https://server-01.mydomain.com/OAB/28a57cb5-b2c8-442a-81f3-a48a05f9ab7b/oab.xml
  • https://server-02.mydomain.com/OAB/28a57cb5-b2c8-442a-81f3-a48a05f9ab7b/oab.xml
  • https://server-03.mydomain.com/OAB/28a57cb5-b2c8-442a-81f3-a48a05f9ab7b/oab.xml

During my Googling for this I found this blog post: http://unified.swiatelski.com/2011/02/exchange-2010-cannot-download-offline.html

The permissions were incorrect on our web.config file so I tried the suggested fix in the blog post. It didn’t work.

I then went through this document: https://technet.microsoft.com/en-us/library/gg247612%28v=exchg.150%29.aspx and made all of the tweaks needed to match those recommendations. I couldn’t find a Exchange 2016 specific document but there weren’t many tweaks to be made and they all made sense to me.

This did not resolve the issue either.

Next up was a Outlook Web Services health check using this PowerShell command:

Ok. Error 500. We know this already.

On my local system I ran this command in Command Prompt:

After digging around the file system of our Exchange servers I was unable to find a folder called 28a57cb5-b2c8-442a-81f3-a48a05f9ab7b in the following locations:

  • C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB
  • C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\oab

This confirmed for me that the OAB wasn’t even being generated.

We then tried manually updating the OAB. The command succeeded but no OAB was generated.

We think what happened is the moving of the System Mailboxes way back at the beginning of our Exchange 2016 deployment broke the association of which system mailbox generates the OAB.

Running this command confirmed that there was no mailbox assigned to generate the OAB:

To fix the problem we did the following:

Enabled Global Distribution of the OAB (since we have 3 Exchange Servers why let one of them have all the fun?):

Then we created a new system mailbox dedicated to the purpose of generating the OAB and manually regenerated the OAB. We put the account in the same Domain as Exchange instead of where the users are:

It took all of 30 seconds and then the OAB URLs started working again and displaying a properly formatted XML file. Outlook clients automatically started downloading the OAB with no issues.

Checking our OAB:

The LastTouchedTime was now set. I’ll be checking again tomorrow to make sure the LastTouchedTime changes based on the Schedule.

Re-running this command confirmed there was now an account set to generate the OAB:

Re-running the OutlookWebServices test shows a successful OAB check:

Finally the event viewer on our Exchange server should also show Event ID 17001 and 17002 for the MSExchange Mailbox Assistants Provider showing the start and completion of the OAB generation:

 

References:

Leave a Reply

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