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!

Think Load Balancing Before You Ditch Your Exchange DAG Administrative Access Point

With Exchange 2013 SP1, Microsoft introduced an alternative to the traditional failover cluster on which DAGs are based: no virtual IP, no Cluster Name Object, no worries. For
details see https://technet.microsoft.com/en-AU/library/dd979799(v=exchg.150).aspx.

Backup is the most quoted reason why you may still want to have an administrative access point. Backup software needs an always-on resource to connect to in order to back up
Exchange. And that is, conveniently, the cluster administrative access point. However backup software vendors are catching up with the times and they don't really need a
cluster resource anymore.

So why would you still want to have one? Well, think of inbound SMTP load balancing, and, implicitly, High Availability (HA).

Have you ever tried to load-balance SMTP? If so then you've probably encountered some or all of the following:

• In the Exchange transport logs, all SMTP traffic appears to be coming from a single IP address - that of the load balancer. How do you tell the "real" source without looking at the e-mail headers?
• You have a number of internal devices that need to send unauthenticated e-mail to any recipient, including external ones. Think open relay with restricted access. But if all traffic seems to come from the load balancer, then the only way to allow your multifunction device to scan a document to an external mailbox is to authorise the load balancer as approved source of unauthenticated SMTP traffic. Or you need to send e-mail alerts to an external party as par of your support agreement. Suddenly you have a security problem and a career challenge (you'll cause your organization's servers to be blacklisted in no time and you'll need to explain that to your manager).
• Enable source routing on the load balancer. Bingo, your Exchange server sees the real source. Open relay issue solved. But hey, that will result in asymmetrical routing. Not ideal and usually difficult to diagnose if issues arise. So by solving one problem you introduced another one...

Most of these, and some other aspects, are documented in Paul Cunningham's blog at http://exchangeserverpro.com/issues-with-load-balancing-smtp-traffic/.

The alternative: hang on to your cluster administrative point. The benefits:

• You can send SMTP traffic from internal sources straight to the DAG administrative access point, bypassing the load balancer. No open relay issues, no transport log analysis issues.
• No asymmetrical routing issues.
• Multi-role servers are becoming the norm. In fact, with Exchange 2016, it is the only option. Therefore as long as you have at least one online DAG member, you'll also have implicitly a Hub Transport server too to accept SMTP traffic which will be reachable via the - guess what - thine good olde DAG administrative access point. Therefore service is maintained even if individual DAG members fail.

The solution has one obvious drawback: all inbound SMTP traffic will be processed without any load balancing, by a single Exchange server, the one which holds the name and IP address of the DAG
administrative access point.

As at the time of this post I am yet to see an Exchange infrastructure whith such a heavy inbound SMTP traffic that load balancing (not to be confused with HA) would be a necessity. Therefore the only drawback that I can spot is so insignificant that it can be safely discounted in most environments.

Having said that, I learned to "never say never". If you know of any circumstances where this workaround would not work then please drop me a comment.

Cheers,
Zoltan