Image may be NSFW.
Clik here to view.
Autodiscover is one of the best components of the tie-in between Exchange and Outlook, since it provides for an automatic way for Outlook clients to discover their initial configuration, or to reconfigure their connectivity to a user’s mailbox when changes are made on the back end system. However, that same great automatic functionality may leave users in a lurch when it fails, and help desk staff may not be sure what needs to be done. When Autodiscover doesn’t work, it also limits how flexible admins can be when they need to make changes.
Clients can make Autodiscover queries in a variety of ways. To troubleshoot Autodiscover, it is very useful to understand how the process works. Let’s look at that first.
Domain joined machines with access to Active Directory
If a user is logged onto a domain joined machine with domain credentials, and the machine is on the internal network (directly, or via VPN or Direct Access) Outlook can find an Autodiscover endpoint using an SCP lookup. SCPs (Service Connection Points) are records maintained by Active Directory in the CN=Configuration container. These records are created in AD when you install the CAS role on an Exchange server and can be modified using the Exchange Management Shell, particularly when using the command Set-ClientAccessServer –AutodiscoverServiceInternalUri https://fqdn/ autodiscover/autodiscover.xml. Clients can make an authenticated connection to a domain controller to look up an SCP. You can view the SCPs for Autodiscover using ADSIEDIT.MSC or LDP.EXE. Browse to the Configuration container, and look for CN=<CAS_SERVER>,CN=Autodiscover,CN=Protocols,CN=<CAS_SERVER>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<ORG>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=example,DC=com. Invalid records should be corrected or removed.
Remember the key points here…connectivity to AD, SCP records in the CN=Configuration container, and a URL set during the configuration of the CAS server or a later modification.
Non-domain joined machines, or domain joined machines without access to Active Directory
Whether you are on a machine in workgroup mode, or are remote to the internal network and cannot make a connection to Active Directory, you won’t be able to query a DC for an SCP record. As a result, Autodiscover has to follow a process to find Autodiscover information. It uses a series of DNS queries to find a likely candidate that can provide Autodiscover information. If it can resolve a particular DNS record, it will then query the host for Autodiscover information. Here’s the order that a client will follow to query DNS, using example.com as their domain.
- HTTPS root domain query for an A or CNAME record for “example.com.” If it resolves this, it then attempts to make a connection to https://example.com/autodiscover/autodiscover.xml.
- HTTPS AutoDiscover domain query for an A or CNAME record for “autodiscover.example.com.” If it resolves this, it then attempts to make a connection to https://autodiscover.example.com/autodiscover/autodiscover.xml.
- HTTP redirect method where a request is made to http://autodiscover.example.com and a 301 or a 302 response should redirect to the proper Autodiscover endpoint. This method is useful when you have more domains than you want to include in a certificate.
- SRV record query where a DNS query for an SRV record is made. The SRV record should be in the format _autodiscover._tcp.example.com, resolving to the FQDN of the Autodiscover endpoint.
I’ve never met anyone that has Autodiscover listening on the root domain, but nevertheless, that is the first query that is attempted. I’ve also never seen anyone use HTTP redirect or SRV records either, opting instead to use autodiscover.example.com and either publish the HTTPS connection through a reverse web publishing service like TMG, or just allowing connectivity to that directly. When you use SRV records, Outlook will prompt the user for permission to continue if that is the only way the Autodiscover endpoint can be located, so I don’t recommend it either.
Certificates
Notice that Autodiscover lookups use HTTPS. This is the next place that things can go really wrong for clients. If the certificate securing the session is not trusted, or the CRL or OCSP cannot be reached to validate the certificate, clients will throw an error that the certificate is not trusted. You want to make sure that your certificate securing your Exchange servers is issued by a public Certificate Authority that has very good ubiquity, that clients can make outbound Internet connections to the CRL or OCSP endpoint, and that the certificate common name or SAN includes the FQDN for your Autodiscover endpoint. Wildcard certificates are a good choice here if you have only a single domain, but can be costly if you have multiple SMTP domains you want to secure. You may instead get a UCC certificate with as many SANs as you need, e.g. Autodiscover.example.com, Autodiscover.example.net, Autodiscover.example.org, etc.
What to do when not all SCPs are reachable
While it is not supported to put firewalls between Exchange servers, no one ever said you couldn’t put them between clients and servers. Or perhaps you have a larger enterprise with several business units, and not all trust one another will full and unfettered access. If you have clients that do not have Exchange CAS servers in their site, you’re not exactly following recommended practices, but it does happen. If they cannot reach all CAS servers, you may want to forgo SCP lookups for certain machines. To do that, you can disable SCP lookups using a GPO or by editing the registry.
- Outlook 2007 users can add a key HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\Autodiscover
- Outlook 2010 users can add a key HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\Autodiscover
- Outlook 2013 users can add a key HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\Autodiscover
and tailor their clients experience as desired. Where a 1 wil turn off a method, and a 0 will leave it enabled, here’s the options you can set. In this example, SCP is disabled but all others are enabled.
“ExcludeScpLookup”=dword:00000001
”ExcludeHttpsRootDomain”=dword:00000000
“ExcludeHttpsAutoDiscoverDomain”=dword:00000000
“ExcludeHttpRedirect”=dword:00000000
“ExcludeSrvRecord”=dword:00000000
If you want to set this through a GPO, download the appropriate ADM file for your version of Outlook from Microsoft.
Outlook 2010:
Outlook 2007:
Internal and External URLs
CAS servers will publish information into Active Directory for SCP lookups based on the internal URL specified when they are set up or configured in the EMC. They won’t put anything into DNS automatically for the external URL, but will listen for inbound connections to that URL on the default website, which much have an SSL certificate bound to the site with the proper CN or SAN values. There are times when you might have a CAS only servicing internal or only servicing external clients, so there is nothing that will warn you if you are missing one or the other of the URLs. If clients can connect from either the internal or the external network, but not both, you should check to ensure the CAS server(s) are configured to listen for both. Use the Exchange Management Shell to configure the Autodiscover URI using an FQDN that can be resolved appropriately internally and externally.
Set-ClientAccessServer –AutodiscoverServiceInternalUri https://fqdn/ autodiscover/autodiscover.xml –AutodiscoverServiceExternalUri https://externalfqdn/Autodiscover/Autodiscover.xml
If you are using a split DNS, the internal and external URI may be the same, but should still be set for both.
The best tool for the job
If you need to test Autodiscover, the best tool for the job is the Remote Connectivity Analyzer at http://testexchangeconnectivity.com. Run the Outlook Autodiscover test, and when you get the results, make sure you choose to expand all. Remember you will see some failures even if the test ultimately succeeds, but if it fails you want to drill in on the final results. The response codes will tell you if there is a permissions issue, or if the mailbox does not exist, or if certificate validation failed. From the outside, it’s a great way to see just what is going on.
Now that you know a little more about Autodiscover and how Outlook clients connect to the service, you’re in a better position to troubleshoot when things go wrong.
The post Troubleshooting Autodiscover Lookups appeared first on Email management, storage and security for business email admins.