By: Caio Ribeiro César
We have seen customers troubleshooting most of their “Outlook Connectivity issues” with network tools such as netmon, wireshark, fiddler. I personally love using these tools, but I was once told: “you need to know what you are looking for, before you trace”.
And after a while working in Service and Support, you realize it makes total sense. You need to know exactly what error you are expecting to get in a trace, before you collect data. If you collect data in the dark, it will be hard to identify the issue.
We have seen scenarios that simple answers could have resolved the issue before the incident was closed:
– Has anything changed in your infrastructure?
– What is the behavior inside vs. outside your local area network?
– Can all users reproduce this issue?
– Is your environment federated or not?
Since we have already discussed Outlook issues in Federated Environments, let’s go back to the basics: how Outlook connects to the cloud? Everything starts, but it doesn’t end with… Autodiscover.
And what is Autodiscover? In summary, a web application build by the Exchange team in the 2007 release (yes, +10 years ago) so the life of end users would be easier. This Web Application has one job: allow automatic configuration, providing access to Exchange Services:
– Exchange Server Information;
– Offline Address Book;
– Availability Service;
– Out of Office;
– Unified Messaging.
If you ask Exchange Administrators that worked with the 2003 releases, they will probably say that the best improvement was that the end user would only need to know the account (firstname.lastname@example.org) and password in order to pull out the Outlook Profile information.
There are some ways to get exactly what information is brought by Autodiscover (browsing the URL, running a testconnectivity.com, using Outlook), but let’s focus on the behavior for O365.
In Exchange Online (ExO), we only support organizations that have Autodiscover configured (it is rare, but we can get organizations that still try to manually set servers in Outlook, and this means that eventually the mailbox will be disconnected). Let’s compare how Autodiscover works in Office 365 vs. Local Environments
This picture can be old, but it is still good for understanding Autodiscover. For O365, we cannot communicate with the Active Directory Server, so the communication goes as it would for an external access – meaning it would rely on the DNS record.
For Office 365 (100% Cloud Environments), we have the following guidance for DNS records:
|Record type||Host||Points to||TTL|
|CNAME (Alias)||autodiscover||autodiscover.outlook.com||1 hour|
What about Hybrid Environments? For hybrid environments, the recommendation is: “Autodiscover DNS records – Configure the Autodiscover public DNS records for your existing SMTP domains to point to an on-premises Exchange 2013 Client Access server.”
For Hybrid Environments, why do we point Autodiscover to the CAS server?
A.: Both organizations (OnPrem and O365) share the same domain (contoso.com). Meaning you can only create a single DNS record for it (autodiscover.contoso.com), so only Exchange would be able to identify if a user is local or remote.
It will identify based on the parameter of the TargetAddress (we cover this in the rich mailbox move procedure). A mailbox can only reside in either ExO or Exchange OnPremises, so we will have either a Mailbox in ExO and Mail Enabled User (MEU) in Exchange OnPremises or vice-versa.
What if all mailboxes are already moved to the cloud? We can say this is a hybrid environment in terms of using Exchange to manage objects, but if all users are moved to the cloud, then per se it is not a hybrid environment for a mailbox perspective.
So, next time you get an Outlook Connectivity issue – walk before you run. Understand where the mailbox is located and what exactly you are looking for in the trace, or what weird behavior is happening.
If you are looking for information about Outlook Autod lookup process in a Hybrid environment, I highly recommend this post.