Thursday, 29 September 2016

Don't Forget to Bounce the Autodiscover Application Pool

This has been widely documented but I feel the need to share my experience.

The Scenario

Mailboxes are moved from Exchange 2010 to Exchange 2013 or 2016.
Users are prompted to restart Outlook.
Outlook fails to reconfigure the profile and it doesn't connect to the mailbox on the new server.
Test E-mail AutoConfiguration fails:



The Gist

When you finish moving mailboxes from Exchange 2010 to 2013 or 2016, don't forget to restart the Autodiscover application pool on your new 2013/2016 CAS servers:

Restart-WebAppPool MSExchangeAutodiscoverAppPool

Exchange 2016 is an all-in-one server which combines all roles, but it shows as Mailbox server when doing a Get-ExchangeServer command, so you will have to bounce the pool on every Exchange 2016 server.



The Reason

It doesn't happen too often, but when it does then it can be inconvenient. I just finished moving some mailboxes from Exchange 2010 to Exchange 2016, only to be called because users' Outlook failed to connect to their mailbox.

My initial thoughts were that Outlook is not up to date and it fails to connect via MAPI-HTTP (enabled by default in Exchange 2016), or there may be a proxy (mis)configuration. It even crossed my mind that there may be a dodgy HOSTS file entry that overrides DNS settings.

None of these proved to be the case. Instead, the issue lies in the fact that the Autodiscover application on the Exchange 2013/2016 server caches configuration information. After a mailbox is moved, the application still thinks that the mailbox is on the old server. Therefore it will proxy the connection to the old Exchange 2010 server, which then bounces it back to Exchange 2016. They will be ping-ponging Outlook profile reconfiguration autodiscover requests until the Autodiscover application cache expires and the information is refreshed. The workaround is documented at https://support.microsoft.com/en-au/kb/3097392 and it seems to suggest that the timeout can be up to 12 hours. Recycling the application pool will refresh the cache and Outlook will connect successfully.

Therefore do yourself a favor and recycle the app pool when the moves are complete. It will improve your sleep (think supporting users in different time zones).

Even better, before you start moving mailboxes, configure the pool to recycle on a schedule, say every 5 or 10 minutes, for then you don't have to watch the progress. The steps are documented at https://technet.microsoft.com/en-us/library/cc733120(v=ws.10).aspx and it boils down to the following:


Happy moving!

8 comments:

  1. will there be any disruption when this is restarted?

    ReplyDelete
    Replies
    1. I just bounced this on 4 CAS servers hosting 1000 mailboxes. No disruption whatsoever.

      Delete
  2. Thank you! Only wish i'd found this article 3 weeks ago :-(

    ReplyDelete
  3. OH MY HEAVENS! Thank you SO MUCH! I've literally been going insane for the past two days trying to figure out why this was such a sporadic problem! AIEEEEEE!!! Thank you again, hoisting a beer in your general direction later on today! 😉

    ReplyDelete
  4. What is the difference between recycle and doing a stop and restart of the pool? Recycling is set to every 10 minutes but I still get a user or two here and there that cannot connect using Outlook after being moved to 2016. Would I possibly have better luck restarting the pool rather than recycling it?

    ReplyDelete
  5. All I can say is thank you for this...I was ready to lose my mind...checking and double checking

    ReplyDelete
  6. What a life saver! Thanks for this article!!

    ReplyDelete
  7. If your company uses Salesforce and is actively looking for great developers, then you definitely need to know about all the possibilities for hiring and finding the best candidates for your company. And this resource Diese Internetseite will give you excellent introductory information that you can use to the maximum benefit for yourself.

    ReplyDelete