This short article is intended to list the most common causes of problems with the Outlook connection to Exchange during migration. Connection problems often occur after a mailbox has been moved to a newer Exchange version. Outlook then often displays one of the following messages:
The Microsoft Exchange administrator has made a change that requires Outlook to be restarted.
This message can appear every time Outlook is started, a connection to the mailbox is then no longer possible:
The action cannot be completed. No connection to Microsoft Exchange is available. Outlook must be in the online module or connected to complete this process
This message appears when setting up new profiles; it is not possible to set up the profile:
Or simply this message from Outlook 2019:
Something didn't work out.
I would like to collect the most common causes in this article, I would be happy to receive further causes / problems by e-mail or as a comment and will then update this article.
Autodiscover and DNS
After the new Exchange servers have been installed and configured, the DNS entries for Autodiscover must point to the new Exchange servers. This often causes problems if a mailbox is moved to new Exchange servers but the Autodiscover DNS entries still point to the old servers. Here is an example that can occur when migrating from Exchange 2010 to Exchange 2016 (but also with other versions):
In this case, the HOST-A record autodiscover.frankysweblab.de points to the IP 192.168.200.14, which is the IP of the Exchange Server EX1 (red). In this case, EX2 is the Exchange Server with the newer version (blue):
The DNS entry for Autodiscover must therefore point to the new Exchange Server:
The same applies to the SRV records (if they exist):
SRV records must also point to the Exchange server with the newer version. In this example, the IP for HOST-A autodisocver.frankysweblab.de has been changed to 192.168.200.15 (IP of new Exchange Server) and the SRV record has been changed to the host autodiscover.frankysweblab.de. Autodiscover thus refers to the Exchange version to which the migration is to take place:
The external DNS entries also need to be considered here.
Outlook 2010 and MAPIoverHTTP
Outlook 2010 is still in use in many companies. With Exchange 2013, the MAPIoverHTTP protocol which replaces RPCoverHTTP. Even if RPCoverHTTP is still supported, there are usually problems with Outlook 2010 when MAPIoverHTTP is activated.
Outlook 2010 only supports MAPIoverHTTP with an update (KB2965295), this update requires Service Pack 2 for Office 2010. In order for MAPIoverHTTP to work with Outlook 2010, Service Pack 2 for Office and KB2965295 must be installed.
Here are the corresponding download links:
The updates should therefore be installed before moving the mailboxes so that Outlook 2010 can establish a connection to Exchange 2013/2016 with MAPIoverHTTP activated.
No special updates are required for Outlook 2013 and higher, but these should of course also be up to date.
Autodiscover redirects
Another problem is the autodiscover redirects of the Exchange server, which can also lead to connection problems with Outlook:
After the mailbox move is completed, Exchange Server 2013 or 2016 continues to proxy the autodiscover request to Exchange Server 2010. Exchange Server 2010 responds with a 302 redirect back to Exchange Server 2013 or 2016 (depending on the upgrade).
This problem is described in the following Microsoft article:
However, manually restarting the application pool is usually not a solution, especially if many mailboxes are moved over a longer period of time. A restart interval for the application pool can help here. A restart interval for the "MSExchangeAutodiscoverAppPool" can be defined in the IIS Manager:
With a restart interval of 5 minutes, a mailbox only remains disconnected for a maximum of 5 minutes and the application pool does not have to be restarted manually:
Once all mailboxes have been moved, this setting can be reversed.
Exchange URLs
Incorrectly configured URLs for the virtual directories in the Exchange server can also cause connection problems with Outlook. For example, typing errors in the URLs can lead to incorrect name triggering and thus disrupt the connection from Outlook to Exchange.
The configuration of the virtual directories is described here:
The host names in the URLs must be resolvable accordingly via DNS. The virtual directories can also be managed in the EAC:
The host name for Outlook Anywhere can be found here:
However, the URL for Autodiscover can only be managed via the Exchange Management Shell:
Get-ClientAccessService | fl name,autodiscover* Set-ClientAccessService -Identity EXCHANGE -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"
The URL can be adapted accordingly with the "Set-ClientAccessService" command.