Many Office 365 customers find that Outlook won’t connect to a hosted Exchange server for one reason or another. I’ve encountered this issue in my own Office 365 dealings, but found solutions to
Use these techniques to ensure Outlook connects to your hosted Exchange server.
Verify your DNS records
Outlook relies on the auto-discover service to connect to Office 365. In turn, the auto-discover service relies on a domain name system (DNS) service locator (SRV) record named _autodiscover._tcp.<your domain>. This record must exist in order for the auto-discover service to work properly. Additionally, your auto-discover record should use the following information:
Record type: SRV
Port number: 443
Practice patience with your DNS record
If you’ve already checked your DNS records and Outlook still won’t connect to Office 365 it could be because you simply haven’t waited long enough. DNS records need time to propagate.
If the service record has not propagated, Outlook will not connect to Office 365. The DNS record should propagate in 24 hours or less, but I’ve heard of the process taking up to 72 hours.
Check the DNS resolver cache
If you migrated from an on-premises Exchange Server deployment to Office 365, you may need to check the DNS resolver cache on your users’ workstations. Windows caches the results of each DNS query so that the operating system doesn’t have to perform a new DNS lookup each time it needs to access a resource. It’s possible that after the migration, the clients have a cached DNS entry for the auto-discover service that points to an on-premises server that no longer exists.
If the DNS resolver cache is the problem, the connectivity issue should go away on its own because Windows periodically refreshes cache entries. If you don’t want to wait around to see if the problem goes away on its own, you can manually flush the DNS resolver cache. To do so, open a command prompt window and enter the IPCONFIG /FlushDNS command.
Temporary Outlook passwords fail
Outlook/Office 365 connectivity problems can also be traced back to passwords. I’ve read reports that if a user is assigned a temporary password, Outlook will refuse to connect to Office 365 until the user selects a permanent password.
The Outlook profile must be deleted
When a user connects Outlook to their Exchange mailbox for the first time, Outlook creates a profile. This profile contains information that’s necessary for Outlook to make subsequent connections.
In an on-premises Exchange Server environment, mailbox moves are not a big deal. The auto-discover service tells Outlook that the user’s mailbox has moved and Outlook updates the user’s profile to point to the new location. This process normally occurs without any intervention.
However, when an organization migrates from an on-premises deployment to cloud-based Office 365, Outlook gets confused. There is a documented bug that prevents Outlook from connecting to the user’s mailbox after it moves to Office 365. You must delete the user’s profile to solve this problem.
The exact technique depends on which operating system the user’s desktop runs and which version of Outlook he uses . If your users run Outlook 2010 on Windows 7, close Outlook, then open the Control Panel. Click on the Control Panel’s User Accounts link, then the Mail link. Next, click the Show Profiles button. Windows displays a list of Outlook profiles that are stored on the PC. Select the appropriate profile and click Remove.
A new profile is automatically created when you start Outlook. When Outlook connects to Office 365, the user’s mailbox may initially appear empty. That’s because the user’s profile contains an offline cache. This cache contains a copy of all mailbox items so that users can access mailbox items even if they’re not connected to a mailbox server.
When you delete the user’s profile, you also delete the offline cache. Depending on the size of the user’s mailbox, it may take a while to rebuild the cache. That’s why the mailbox may either appear empty or only show a subset of its contents.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in December 2011