Autodiscover Popup Outlook 2016fasrreport

Disable Autodiscover Outlook 2016
Outlook 2016 Autodiscover Fix

This was days ago, and even now when I try to setup the account again I have found absolutely no Autodiscover activity in the logs. In contrast, MS Outlook and the Outlook iOS/Android app request the settings (also originating from a MS server, not the device) every time an account is being setup. Cached URL in the Outlook profile (new for Outlook 2010 version 14.0.7140.5001 and later versions) Direct Connect to Office 365 (new for Outlook 2016 version 16.0.6741.2017 and later versions) By default, Outlook will try one or more of these methods if it is unable to reach Autodiscover. Test environment with Exchange 2013 servers, 1 mbx server, 1 cas server. Autodiscover configured. This environment is mainly for learning/testing purposes. Lets say I have 3 users. User1 user2 user3 I am logged in as user1, using my Outlook 2010 client to connect to the Exchange 2013 on-premises servers, with the use of Autodiscover. I have setup a test domainname with SSL configured and autodiscover enabled. And added a mailbox. Outlook Office 365 Version 2002 (Build 8) This is currently the most recent version I click in Outlook: File Add account I get a popup window and I type the emailaddress of the mailbox.

There’s a fairly common issue that occurs with mobile devices connecting to Exchange Server or Exchange Online for mailbox access.

Before we go further though, I just want to point out two other potential causes of this issue that you should check first, as they’re simpler solutions:

User principal names (UPNs) for user accounts should match primary SMTP addresses. If they don’t, then some mobile devices will fail to setup with Autodiscover.
Some Android devices need the username (UPN/email) to be entered as “username”, for example “alex.heyne@exchangeserverpro.net”

Assuming neither of the above suggestions fixed your problem, you may be having issues due to Autodiscover and root domain lookups. When the mobile device begins the Autodiscover process, it will often fail and prompt the user to manually configure their device settings.

When clients use Autodiscover to locate server configuration details, the first attempt is usually to try the root domain for the user’s email address, e.g. a user of alex.heyne@exchangeserverpro.net will mean an Autodiscover attempt is sent to https://exchangeserverpro.net/Autodiscover/Autodiscover.xml. You can see this behavior by running the ActiveSync Autodiscover test using the Remote Connectivity Analyzer.

The root domain lookup makes absolutely no sense to me, since no customer I’ve ever dealt with has their root domain resolving in DNS to their Exchange server where the Autodiscover service is available. But that’s the behavior, so we need to deal with it.

Now, most clients will handle that root domain lookup failure gracefully, and (just like the Remote Connectivity Analyzer does) move on to the next Autodiscover method. As long as the Autodiscover CNAME or SRV record is implemented (or both), the client will successfully connect to Autodiscover and the device or application is configured correctly.

But, for a random assortment of devices and applications, the root domain failure is interpreted as a complete Autodiscover failure, and the user is prompted to manually configure server details. This can occur when the root domain resolves to a web server (which is normally where it resolves to) that has HTTPS enabled and listening, but has an SSL certificate installed that doesn’t match the root domain name that the device is trying to connect to. This is very common when shared hosting is used to host multiple websites for different domains.

In the example above, a device connecting over HTTPS to “contoso.com” will see a certificate of “sr100283.webhostingcircus.com”, and the HTTPS connection will not be successful. To fix this situation, some changes on the web server are required.

Enable SSL for the website. This will involve adding an SSL certificate, which you may need to purchase if the web host can’t arrange it for you. Depending on the web host this may involve an extra cost and potentially a static IP, although most good web hosts these days will let you enable SSL at no additional cost. Some even use Lets Encrypt to provide free SSL for customers. Another alternative is to use Cloudflare to get free SSL for your website (this doesn’t require you to move the website itself to a different server).
On the web server, configure a redirect for all requests to the /Autodiscover virtual directory to be redirected to the autodiscover.contoso.com instead (where “contoso.com” is your domain name). Configuring the redirect itself will depend on the type of web server your site is running on. Some web hosts provide a control panel to allow you to configure redirects yourself.

When the SSL and redirect are in place, Autodiscover lookups to the root domain will not fail the HTTPS connection, and will be redirected to your Exchange server instead.

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.

End-user-level solutions
Administrator-level solutions
More administrator information

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;

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:Autodiscoverautodiscover.xml. It is important that you change the file extension from txt to xml.

Tip!
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.

Download: autodiscover.zip

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_USERSOFTWAREMicrosoftOffice16.0OutlookAutoDiscover
Value name: company.com
Value type: REG_SZ
Value: C:Autodiscoverautodiscover.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.

Tip!
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.

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%AppDataLocalMicrosoftOutlook

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.

Note:
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

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.

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

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

Important!
It has to be published to the root domain; company.com. Publishing it to www.company.com 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

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

Disable Autodiscover Outlook 2016

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.

Outlook 2016 Autodiscover Fix

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)
Publishing Exchange Server 2013 using TMG – Exchange Team Blog(also applies to ISA and UAG)