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:
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 mail.bluewidgets.com, the CNAME in public DNS for Autodiscover should point to mail.bluewidgets.com.
As you can see in the screenshot above, I’ve created an Exchange organization that services the testlab365.org email domain. To ensure Autodiscover works properly for the email domain, I’ve created a CNAME record in public DNS that points autodiscover.testlab365.org to my external access domain, which is mail.testlab365.org. The mail.testlab365.org “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 bluewidgets.com, your Autodiscover hostname would be autodiscover.bluewidgets.com. 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 https://bluewidgets.com/AutoDiscover/AutoDiscover.xml
- Connect to: https://autodiscover.bluewidgets.com/AutoDiscover/AutoDiscover.xml
- Autodiscover redirect URL: http://autodiscover.bluewidgets.com/autodiscover/autodiscover.xml
- 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
3 thoughts on “Configuring Exchange 2019 Autodiscover for internal and external access”
Thomas, I’ve scoured the internet for days on this and are hoping you can answer my questions below based on your expertise.
The root domain lookup for the autodiscover.xml file always fails since the host at domain.com and http://www.domain.com are typically pointed to a web server and not pointed to an Exchange server. The connectivity analyzer for ActiveSync is smart enough continue to check for the other connections; i.e. autodiscover.mail.domain.com and successfully find the Exchange server settings.
I think I’ve had some mobile clients see that as a hard fail and force the user to enter advanced settings like servername, domain, etc. I’ve also recently fixed our public dns settings. We had an A record for autodiscover.domain.com instead of the recommended CNAME record for autodiscover pointing to mail.domain.com.
Is the CNAME record actually what helps the client get past the root domain lookup failure for the autodiscover.xml file?
Is there any way to fix the failure at the root domain lookup for the autodiscover.xml file?
Does the failure even really matter to the client?
Looking forward to your response so I can stop dwelling on this.
That should have been autodiscover.domain.com.
I am fairly new into IT and i have this project on Exchange Server. Currently we use IMAP with our Public hosting and we need to change from that to exchange to utilize the sharefolder and other group email exchnage provides.
So far i have done a successful installation of MS exchange. currently, the Domain name is “internal.it.com” but public domain is “it.com”(as example). with the followings;
1. i have created accepted domain on EAC to resolve the internal.it.com to it.com. i also created a forward zone for “it.com” for external URL. so that staff can access it online.
2. I created A, Cname, Autodicover and MX records on the public cpanel with the “A” record pointing to the public IP address our ISP gave us.
3. Also i created an MX record on the DNS server in “it.com” Zone (not internal.it.com) pointing to the exchange server which i am not sure if its correct). i have a reservation it should in the internal.it.com Zone.
4. I have opened port 25,443 and all required ports in the exchange server (not the DC server) which i also want to clarify. that is, is the port to be opened in the DC or exchange server?
However for some reason i cannot explain, i can send email to other domain but gmail bounces back with an error of “The IP you’re using to send mail is not authorized to send email directly to our servers. Please use the SMTP relay at your service provider instead”. Also when the domain address i sent email to replies, it does not drop in the exchange but can receive the email on my mobile since it is configured with IMAP and i can also receive the email on any device i sue that is not on the domain.
Also all our emails from the public domain are not dropping into exchange.
So here are my questions and i would be glad if i can get this resolved.
1. Am i to insert the public IP address our ISP gave us in the exchange server or the DC (Domain Controller) as an alternate DNS server or i need to configure the NAT to do this or i do not need to do anything at all?
2. Am i opening the port exchange requires in exchange server or in the DC?
3. What else am i suppose to do get all emails from our public domain to drop as well as that of gmail issue.
4. Right now, the our emails which are currently on IMAP are also not dropping which i think could be as a result of default blockage from MS exchange.