Autodiscover: Some quick methods to get it working

Autodiscover.xml buttonThe 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

Configuration buttonThis 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:
    (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).

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

Outlook buttonAlthough 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

Autodiscover Local XML Redirect buttonStep 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);

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

Autodiscover XML - ErrorCode 600 - 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="">
  <Response xmlns="">

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.

You can also download the zip-file below. It contains an autodiscover.xml file that you can open in Notepad so that you can edit the RedirectURL. Save the file to the folder mentioned above. It also contains an autodiscover.reg file that you can use for the next step.


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:
  • 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.

To do this, you can also use the download from Step 2. It contains an autodiscover.reg file that you can open in Notepad so that you can edit the Value Name and the Value.

Note that in the reg-file the backslashes ( \ ) in the file-path are doubled but will show up as single backslashes within the Registry Editor.

The reg-file assumes that you are using Outlook 2016. When you are using Outlook 2013, change 16.0 into 15.0. Save the file and double click it to import it into the Registry.

AutoDiscover Local XML Registry
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
AutoConfiguration Autodiscover redirect prompt.

Method 2: Local XML (obtained full file)

Autodiscover Local XML buttonWhen 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;

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.

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.

Cached Autodiscover.XML file in user's Local AppData folder.
Location of the hidden cached Autodiscover.XML file.

Administrator-level solutions

Exchange buttonImplementing 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.

The only downside of the methods discussed below is that your users will get a redirect warning and may have to supply their credentials twice (depending on your firewall settings) but they only have to do this once and can set it to never bother them again.

This does not apply when you follow the Preferred Architecture with a dedicated autodiscover subdomain but this requires more elaborate reconfiguration and a new certificate.

Method 1: CNAME DNS Record

DNS CNAME buttonJust 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;

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:

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

DNS SRV buttonJust 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

Some DNS systems have separated the values for the SRV record and/or don’t require a . behind the domain name. When in doubt; Contact your ISP and ask them to implement the DNS change mentioned in the guide; Autodiscover service in Exchange Server.

In this guide they use a bit different SRV record notation and I haven’t come across a public DNS system yet which allows you to enter the data like that. Microsoft’s own DNS servers come close though but these are usually not being used for web based DNS management.

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

Autodiscover Server XML Redirect buttonIf 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:

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.

It has to be published to the root domain; Publishing it to will not work. Most website hosting company’s treat requests for with or without the www part in the same way so this usually isn’t a problem.

It does not matter whether it is published on a http or https website. As long as the root domain matches your email domain, Outlook will query the URL.

More administrator information

More Info buttonIt 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

Firewall buttonWhen 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

Exchange PowerShell buttonIf 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
  • Exchange Web Services (EWS)
    • Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalURL
  • Outlook Anywhere (RPC over HTTP)
    • Get-OutlookAnywhere | Set-OutlookAnywhere –ExternalHostname –ExternalClientsRequireSsl $true
  • MAPI over HTTP (Exchange 2013 SP1 or later)
    • Get-MapiVirtualDirectory | Set-MapiVirtualDirectory –ExternalURL
    • 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 email domain. You may need to set IIS Authentication Methods as well.

Autodiscover and other related documentation

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