Autodiscover: Some quick methods to get it working

The Autodiscover service is a required service for Outlook-Exchange connectivity since Outlook 2007 and Exchange 2007 but for whatever reason, in some Exchange environments this still hasn’t been implemented correctly.

In some part, this was due to the fact that you could still get basic Outlook-Exchange connectivity by using some legacy Exchange 2003 RPC over HTTP dialog in Outlook. This (unsupported) method now no longer works in Outlook 2016, Outlook 2019 and Outlook for Office 365 due to the removal of this legacy dialog since Outlook doesn’t support Exchange 2003 anymore since Outlook 2013.

Unfortunately, this leaves up-to-date Outlook users disconnected when Autodiscover hasn’t been provisioned correctly by your company.

This guide contains some reasonably quick and easy and some less elegant methods for end-users but also for Exchange administrators to get your Outlook connected to Exchange again. All discussed solutions are fully supported configurations by Microsoft and do not require any changes to Exchange or the need for a new SSL Certificate.

• Starting point configuration
• End-user-level solutions
  • Method 1: Local XML Redirect
  • Method 2: Local XML (obtained full file) 
• Administrator-level solutions
  • Method 1: CNAME DNS Record
  • Method 2: SRV DNS Record
  • Method 3: XML Redirect on root domain
• More administrator information
  • Firewall exceptions
  • Configuring external URLs
  • Autodiscover documentation

Starting point configuration

This guide assumes that the following is already configured and running within the Exchange environment;

• Outlook Anywhere has already been published to the Internet.
• Outlook Web App (OWA) has already been published to the Internet.
• OWA is published to the URL: https://mail.company.com/owa
  (of course, you must replace this with your own OWA URL)

This guide is targeted towards end-users and administrators of Small and Medium Business organizations (SMB).

Note:
As all the methods discussed are fully supported by Microsoft, they can also be applied to larger corporate environments but for such installations it is best to follow the Preferred Architecture guidelines from the Exchange Team and use a dedicated Autodiscover subdomain with its name on the SSL certificate instead of a redirect.

End-user-level solutions

Although the actual solution really needs to be performed at server-level by your administrator, we’ll first discuss the end-user or Outlook level solutions since, well… the main topic of this website is Outlook and you probably came here because you couldn’t connect to your Exchange mailbox.

Both solutions that are being discussed in this section can be applied by end-users to get Autodiscover working for your email account so that you can make a fully supported connection to your Exchange mailbox within Outlook. No server-level changes are needed.

Method 1 is the preferred end-user-level method so please try that first. When the first solution works for you, you do not need to apply the second method. However, you might want to point out the Administrator-level solutions to your administrator so you’ll never have to perform these steps again.

Method 1: Local XML redirect

Step 1: Check the default autodiscover URL
For this method, we’ll first check whether Autodiscover for your email domain has been published to an alternative URL. To do this, logon to OWA from outside your corporate network and then type the following URL (of course substituting the first part with your own OWA domain);

https://mail.company.com/autodiscover/autodiscover.xml

If this works, then you should see a website looking like this with ErrorCode 600 and Invalid Request;

Getting an error is actually a good thing this time.

Step 2: Create a local XML redirect file
When it looks like that, create a new file in Notepad and copy and paste the following text into it;

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <Account>
      <AccountType>email</AccountType>
      <Action>redirectUrl</Action>
      <RedirectUrl>https://mail.company.com/autodiscover/autodiscover.xml</RedirectUrl>
    </Account>
  </Response>
</Autodiscover>

Make sure you edit the RedirectURL to the Autodiscover URL of your company.

Save the file as autodiscover.xml to a convenient location such as C:\Autodiscover\autodiscover.xml. It is important that you change the file extension from txt to xml.

Step 3: Add an autodiscover reference to your Registry
Now, open the Registry Editor and add the following value name and value;

• Key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover
• Value name: company.com
• Value type: REG_SZ
• Value: C:\Autodiscover\autodiscover.xml

The “Value name” should match the domain part of your email address and the “Value” should point to the location of your autodiscover.xml file that you created in Step 2.

Adding an Autodiscover Local XML reference in the Registry.

Step 4: Open Outlook and configure your account
Now open Outlook and add your account via Auto Account Setup by only supplying your name, email address and password. When you’ve done everything correctly and the Exchange server has otherwise been properly configured, your account will be configured in Outlook automatically.

During this AutoConfiguration process, you’ll get a redirect warning and may need to supply your credentials twice (depending on your company’s firewall configuration) but you only have to do this once and can set it to never bother you again.

AutoConfiguration Autodiscover redirect prompt.

Method 2: Local XML (obtained full file)

When the Autodiscover URL did not return any results for you, the above redirect method will not work and you’ll need an XML-file which contains all the Exchange settings.

When you also connect internally to Exchange, take a look in this (hidden) folder;
C:\Users\%username%\AppData\Local\Microsoft\Outlook

Here you’ll find a (hidden) XML file that starts with a long string (GUID) and ends with - Autodiscover.xml. Copy this to the C:\Autodiscover\ folder and rename the file itself to autodiscover.xml.

Once you’ve created your copy of this XML file, perform Step 3 and Step 4 from the Local XML Redirect method described above.

If it still doesn’t work now, you won’t be able to get it to work without the assistance of your Administrator.

Note:
If you can connect successfully now, it may still stop functioning in the future when your Exchange administrator makes an infrastructural change that affects your mailbox. In that case, you’ll need make a new copy of the autodiscover.xml file after connecting locally once to make sure it includes all the new settings.

Location of the hidden cached Autodiscover.XML file.

Administrator-level solutions

Implementing one of the following solutions is preferred and recommended over implementing any of the end-user level methods. End-users can then configure their account in Outlook simply by providing things they know and can remember;

• Name
• Email address
• Password

The methods below don’t require you to obtain a new certificate nor to reconfigure Exchange itself. In many cases, it doesn’t even require you to make changes to the corporate firewall but if you do, it is a similar exception to the ones you’ve already made to allow access to Outlook Web App (OWA), Exchange ActiveSync (OWA) and Outlook Anywhere (RPC over HTTP).

You can check your Outlook Connectivity and Autodiscover configuration settings for your Exchange environment by using the Microsoft Remote Connectivity Analyzer.

Method 1: CNAME DNS Record

Just like method 1 for end-users (Local XML Redirect), you first need to check whether the Autodiscover URL is already working for your environment by logging onto OWA first and then visiting;

https://mail.company.com/autodiscover/autodiscover.xml

When you get the Autodiscover XML with ErrorCode 600 returned, you’re good to go. If not, you may still need to make a firewall exception.

You can now make the Autodiscover service available by adding the following CNAME record to your external DNS. If you don’t know how to set a CNAME record, contact your ISP hosting your external domain name and they can do it for you.

• Name: autodiscover
• TTL: 3600
• RR Type: CNAME
• Value: mail.company.com

Check your Autodiscover service via the Microsoft Remote Connectivity Analyzer. When it is successful, also do the Outlook Connectivity test. When that fails, you may need to configure the proper external URLs in Exchange.

Method 2: SRV DNS Record

Just like the CNAME DNS Record method, check whether you get the Autodiscover XML with ErrorCode 600 returned. If not, make the proper firewall exception first.

Instead of making a CNAME record in your external DNS, you can also use an SRV record to make the Autodiscover service available. If you don’t know how to set an CNAME record, contact your ISP hosting your external domain name and they can do it for you.

• Name: _autodiscover._tcp
• TTL: 3600
• RR Type: SRV
• Value: 0 443 mail.company.com.

Check your Autodiscover service via the Microsoft Remote Connectivity Analyzer. When it is successful, also do the Outlook Connectivity test. When that fails, you may need to configure the proper external URLs in Exchange.

Method 3: XML redirect on root domain

If you can’t set the external DNS records for your company for some reason, you can instead place an XML Redirect file on the web server hosting your root domain.

To do this, perform the first 2 steps from the Local XML Redirect method.

Instead of storing the autodiscover.xml file to the local computer and adding a Registry value, place the file on the web server hosting your corporate website so that it is published on the following URL:

http://company.com/autodiscover/autodiscover.xml

Check your Autodiscover service via the Microsoft Remote Connectivity Analyzer. When it is successful, also do the Outlook Connectivity test. When that fails, you may need to configure the proper external URLs in Exchange.

More administrator information

It could be that you are still having difficulties to connect now or that the Microsoft Remote Connectivity Analyzer is still reporting issues for the Autodiscover and/or Outlook Anywhere configuration. This is usually due to not having the correct firewall exceptions or external URLs configured.

Firewall exceptions

When the Autodiscover URL mentioned above doesn’t return an XML schema, it is probably because the firewall has a restriction set for which virtual directories to allow. In that case, you’ll probably now only allow;

• /owa/*
• /rpc/*
• /mapi/* (when using Exchange 2013 SP1 or later)
• /oab/*
• /ews/*
• /Microsoft-Server-ActiveSync/*

If so, you also need to allow: /AutoDiscover/*. If any of the above virtual directories is missing as well, add those too.

Configuring external URLs

If it is still not working now, results from the Microsoft Remote Connectivity Analyzer will probably give you a good indication why. Usually it is due to not having the correct external URLs configured for the virtual directories of the following services;

• Offline Address Book (OAB)
  • Get-OabVirtualDirectory | Set-OabVirtualDirectory –ExternalURL https://mail.company.com/oab
• Exchange Web Services (EWS)
  • Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalURL https://mail.company.com/ews/exchange.asmx
• Outlook Anywhere (RPC over HTTP)
  • Get-OutlookAnywhere | Set-OutlookAnywhere –ExternalHostname mail.company.com –ExternalClientsRequireSsl $true
• MAPI over HTTP (Exchange 2013 SP1 or later)
  • Get-MapiVirtualDirectory | Set-MapiVirtualDirectory –ExternalURL https://mail.company.com/mapi
  • Set-OrganizationConfig -MapiHttpEnabled $true

Click on the service names for more information about how to obtain or adjust these configured URLs. The examples contain the values that are required for the company.com email domain. You may need to set IIS Authentication Methods as well.

Autodiscover and other related documentation

If you want to learn more about the Exchange Autodiscover service and how Outlook interacts with it, the following articles are a good starting point.

• Autodiscover for Exchange – Microsoft Docs
• Autodiscover service in Exchange Server – Microsoft Docs
• Outlook 2016 implementation of Autodiscover – Microsoft Support (also applies to Outlook 2019 and Outlook for Office 365)
• White Paper: Exchange 2007 Autodiscover Service – Microsoft Docs (still relevant for later Exchange versions)
• Recommendations for Deploying the Autodiscover Service – Microsoft Docs
• Outlook Anywhere – Microsoft Docs
• MAPI over HTTP – Microsoft Docs
• Outlook Connectivity with MAPI over HTTP – Exchange Team Blog
• Publishing Exchange Server 2013 using TMG – Exchange Team Blog (also applies to ISA and UAG)
• Unexpected Autodiscover behavior when you have registry settings under the \Autodiscover key – Microsoft Docs