Configuring Exchange 2019 Autodiscover for internal and external access

The Autodiscover service in Exchange 2019 makes email setup for end users easier by minimizing the number of steps that a user must take to configure the client. Clients that connect via Exchange Web Services (or EWS) typically connect to the EWS endpoint URL via Autodiscover. With that said, Autodiscover can also provide information to clients that connect using other protocols. When configured correctly, Autodiscover can be used by clients to connect to Exchange 2019 from inside or outside of corporate firewalls. Autodiscover also supports multiforest configurations as well.

Although previous versions of Exchange offered Autodiscover services through the Client Access Server, beginning with Exchange 2016, and continued with Exchange 2019, there is no longer a separate Client Access Server. The mailbox server now provides Client Access services. As such, the mailbox server also provides Autodiscover services.

When Exchange 2019 is installed, it creates a virtual directory called Autodiscover under the default web site in Internet Information Services (IIS). Active Directory then stores the authoritative URLs and provides them to domain-joined computers. The Client Access services that run on the Mailbox server provide authentication services as well as proxy services for internal client connection as well as clients connecting externally. The Outlook client can then connect to Exchange using only the user name and password.

Autodiscover and Active Directory

Information about user mailboxes, as well as configuration information for the Exchange organization, is stored in Active Directory. Before installing Exchange 2019 in an AD forest, the AD forest and any domains within the forest that will contain Exchange users must first be prepared. Essentially, what preparation of the AD forest and domain does is it adds Exchange attributes and Exchange information to the Active Directory schema.

During installation, Exchange 2019 automatically creates a virtual directory called Autodiscover in IIS on the server. This is the Client Access services web site that clients connect to. It allows Outlook to automatically discover the necessary Exchange mailbox settings so that end-users don’t have to remember technical things such as server names, ports, and protocols. The user can simply provide a username and password, and Outlook does the rest.

When the Autodiscover virtual directory is created, an SCP object is also created in Active Directory. The SCP object in AD stores the authoritative URLs for the Autodiscover service and provides them to domain-joined computers. The SCP object points to the Exchange server and provides additional Autodiscover information to clients trying to connect to Exchange.

The SCP object locates the Autodiscover server or endpoint that’s appropriate for the user trying to connect. It provides an easy way for domain-joined mail clients to look up Autodiscover servers.

There are two types of SCP objects for the Autodiscover service that Exchange publishes. They include SCP pointers and SCP URLs.

SCP pointers contain information that points to specific LDAP servers that are then used to locate Autodiscover SCP objects in the user’s Active Directory domain. SCP URLs contain Autodiscover URLs for Autodiscover endpoints.

The Autodiscover service URL in Exchange 2019 will be either of the values below:

  • https://youremaildomain/autodiscover/autodiscover.xml
  • https://autodiscover.youremaildomain/autodiscover/autodiscover.xml

The URL used will depend on whether the Autodiscover service is configured on a separate site or not.

When a client that uses Exchange Web Services launches the first time, it configures itself using the Autodiscover service.

Autodiscover in DNS

In earlier versions of Exchange (E2K10), there were numerous namespace requirements for Autodiscover that need to be met in order to provide site resilience. These requirements included:

  • Primary AND Secondary datacenter IP namespaces
  • Primary AND Secondary Outlook Web App failback namespaces
  • a Transport namespace for SMTP
  • Primary AND Secondary datacenter RPC Client Access namespaces

Exchange Server 2019 reduces the number of required namespaces from five down to two because Exchange 2019 does not require RPC Client Access namespaces. The Client Access services now proxy connection requests to whatever Mailbox server is hosting the active Mailbox database for the mailbox being connected to. Unlike some earlier versions of Exchange, Exchange 2019 allows a Mailbox server in one AD site to proxy a session to another mailbox server in a different Active Directory site, eliminating the requirement that a unique namespace be set up for each datacenter. In addition, Exchange 2019 does not require failback namespaces in DAG activation situations.

Once considered a pain to set up, Autodiscover setup is now rather simple, because all it requires is a CNAME record in the public DNS for the email domain.

When deploying Exchange Server 2019, you should create an Autodiscover CNAME record in DNS for the email domain that you intend to use. The CNAME record should point to the external access domain that was configured for Exchange. For example, if you configured the external access domain in Exchange to be, the CNAME in public DNS for Autodiscover should point to

As you can see in the screenshot above, I’ve created an Exchange organization that services the email domain. To ensure Autodiscover works properly for the email domain, I’ve created a CNAME record in public DNS that points to my external access domain, which is The “A record” points to the public IP address of my Exchange 2019 server.

Outlook and Autodiscover

If Autodiscover is properly configured, Outlook clients can authenticate to Active Directory with just a user’s credentials. It will automatically search for the Autodiscover SCP objects for the domain. Once it finds the Autodiscover service, the Outlook client will connect to the Client Access services on the first Mailbox server it finds. Outlook will then collect profile information in XML format. This information is required to connect to the mailbox.

In most cases, you’ll need to add a fully qualified domain name as your Autodiscover hostname in DNS. For example, if your email domain is, your Autodiscover hostname would be The Autodiscover hostname needs to point to the Exchange server that’s providing Autodiscover services (typically via a CNAME record that points to the configured external access domain). Clients accessing Exchange externally will locate the Autodiscover service on the Internet by referencing the primary SMTP domain address of the user’s email address.

Autodiscover can use one of four methods to configure an Outlook client:

  • Connect to
  • Connect to:
  • Autodiscover redirect URL:
  • Search for DNS SRV record

The first two methods above are typical for smaller organizations with a single SMTP namespace. The second two are typical in multiple-SMTP namespace scenarios.

Outlook uses the Autodiscover service to locate a new connection point. Autodiscover returns the following information to the Outlook client:

  • User display name
  • Internal and external connection settings
  • Mailbox server hosting the active copy of the user’s mailbox
  • URLs for various Outlook features (OAB, OWA, etc.)
  • Outlook Anywhere server settings

Obviously, you need to make sure that the correct internal and external URLs have been configured for the Exchange 2019 virtual directories before mail works. For example, you’ll need to configure the correct URLs for the OAB Virtual Directory, Exchange Web Services, Outlook Anywhere, and the MAPI Virtual Directory. Click here for instructions on configuring external URLs for the various Exchange 2019 services.

If the Exchange information for a user changes, the Outlook client will use the Autodiscover service to automatically reconfigure the user’s profile. This commonly occurs when a mailbox is moved. When this happens, Outlook contacts the Autodiscover service and automatically updates the user’s profile with the new mailbox location so that it can connect.

Autodiscover and certificates

When Exchange is installed, the installation process creates a self-signed certificate that’s signed by the Exchange server itself. This certificate is automatically installed on the server. However, best practice dictates that you use a public certificate from a trusted third party, especially if your users will be connecting to their mailboxes from outside the network, from non-domain joined machines.

To create a certificate, you first need to create a certificate request on the Exchange server. A certificate request, which is also referred to as a CSR, or certificate signing request, is used to obtain a certificate from a certification authority, or CA. Click here for more information on creating certificate requests.

You can use the Microsoft Remote Connectivity Analyzer tool to confirm that the Autodiscover service in Exchange 2019 is accessible and functioning as expected. To test Autodiscover with the tool, launch the tool and select the Outlook Connectivity test. The tool will then attempt to connect to Exchange, using Autodiscover. If it fails, there is likely an issue with the external URLs configured in Exchange. Reading the results provided by the tool should reveal clues regarding why connectivity failed.

Wrapping things up

This article provides the necessary information for understanding the Autodiscover service in Exchange 2019, for confirming the current Autodiscover functionality (using the Microsoft Remote Connectivity Analyzer Tool), and for configuring Autodiscover in DNS. To ensure that the Autodiscover service functions properly in your Exchange 2019 organization, you must have a properly-configured certificate installed on the Exchange server, and the Exchange server must be accessible externally, via an external access domain. The external access domain can be configured via the Exchange Admin Center.

Use the information presented in this article to properly configure both internal and external Autodiscover access for your end users.

Featured image: Shutterstock

Thomas Mitchell

I am a 25+ year veteran of the IT industry and a subject matter expert in multiple disciplines, including Microsoft Exchange, Active Directory, and Microsoft Azure. My in-depth knowledge of these and other disciplines allows me to not only design and implement solutions based on these technologies but to also teach them. I hold the Cloud Platform and Infrastructure MCSE, as well as several other certifications.

Published by
Thomas Mitchell

Recent Posts

Qumulo raises $125M for cloud data management across a hybrid setup

Qumulo is an up-and-coming data management solution focusing on managing files in a hybrid setup.…

1 day ago

Why SMBs need a standalone solution for Windows 10 patch management

Is patch management for the Windows PCs at your business driving you crazy? Maybe there's…

2 days ago

Microsoft Teams guest access: How to enable and manage it

Two of the main factors that affect the total cost of an organization’s Microsoft 365…

2 days ago

Samsung Galaxy Unpacked 2020: Everything you need to know

Samsung rolled out the all-new Galaxy Z Fold 2, Note 20, Note 20 Ultra handsets…

3 days ago

SAN vs. NAS: Detailed comparison of these two storage technologies

SAN and NAS provide dedicated storage for a group of users using completely different approaches…

3 days ago

Generation 1 virtual machines: Modernize them and bring them up to date

In many companies, Generation 1 virtual machines have been superseded by Gen 2 VMs. But…

3 days ago