Autodiscover is the most important feature of Exchange. It gives a maximum of usability for every user and maximum of capability for every collaboration service. I will explain in detail all important things to know about Autodiscover and how to troubleshoot autodiscover issues.
What is Autodiscover
Autodiscover is a web-service located on every Client-Access / Mailbox server in every exchange organization.
It is mostly reachable from the Internet and is using port 443. By default it can be also reached on port 80, but this is only an internal redirection. So HTTP is actually not required.
It is always using the same URL just with a different Maildomain (your domain).
To avoid any connectivity issues in your environment it is recommended to create a DNS entry for AUTODISCOVER for every “mail-domain” in your exchange environment.
What is Autodiscover used for?
Autodiscover is responsible for locating user mailboxes in an Exchange Organisation.
In a big Exchange Organisation you may have a lot of Exchange Server and all of them may have several Mail-Databases. In this case every Client-Access request is being proxied always to the Mailbox-Server which is hosting the mailbox. So, if Autodiscover is not right configured on some servers, you will have a lot of availability issues with all mailboxes on those servers.
Autodiscover is used for following client requests:
- Mailbox configuration from internal network
- Mailbox configuration from external network
- Calendar availability, internal and external
- Calendar sharing, internal and external
- Teams-calendar button in Teams
- Teams-calendar availability (free / busy)
- On which server is which mailbox located, so that you have the best connectivity to your mailbox
- Mailbox moverequests from one exchange server to another. Autodiscover is responsible to redirect User-Outlook requests to the right server after his mailbox has been migrated.
How to configure Autodiscover
You can configure Autodiscover by using
- PowerShell
- Exchange Administrative center (ECP)
Be aware that Autodiscover is located on each Exchange Mailbox / CAS server and needs to be configured on EVERY Exchange-Server.
Via PowerShell
ExternalURL
After a successful Exchange installation, Autodiscover is automatically configured somehow. So you need to check firstly what is configured
Get-AutodiscoverVirtualDirectory
If you have multiple Exchange-Servers is will deliver those output.
Name Server InternalUrl
---- ------ -----------
Autodiscover (Default Web Site) EX21
Autodiscover (Default Web Site) EX25
Autodiscover (Default Web Site) EX24
Autodiscover (Default Web Site) EX22
Autodiscover (Default Web Site) EX23
Autodiscover (Default Web Site) EX26
Autodiscover (Default Web Site) EX27
Autodiscover (Default Web Site) EX28 So if you want to check configuration on a specific single server you can use “-Server” property and “Servername” to get exact result.
Get-AutodiscoverVirtualDirectory -Server EX21 | fl
RunspaceId : aa14ca1b-6e44-4691-956c-6e381fc974ef
Name : Autodiscover (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity...}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity...}
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication : True
LiveIdBasicAuthentication : False
BasicAuthentication : True
DigestAuthentication : False
WindowsAuthentication : True
OAuthAuthentication : True
AdfsAuthentication : False
MetabasePath : IIS:// ex21.mccloud.cloud/W3SVC/1/ROOT/Autodiscover
Path: C:\Program Files\Microsoft\ExchangeServer\V15\FrontEnd\HttpProxy\Autodiscover
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags : {}
ExtendedProtectionSPNList : {}
AdminDisplayVersion : Version 15.1 (Build 2507.6)
Server : EX21
InternalUrl :
ExternalUrl :https://autodiscover.ex21.local/Autodiscover/Autodiscover.xml
AdminDisplayName :
ExchangeVersion : 0.10 (14.0.100.0)
DistinguishedName : CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=EX21,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=mccloud,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=root,DC=global
Identity : EX21\Autodiscover (Default Web Site)
Guid : f0d0df98-6155-462a-bcbd-0a766cf3bb9b
ObjectCategory : root.global/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory
ObjectClass : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory}
WhenChanged : 10/29/2021 11:17:18 AM
WhenCreated : 3/7/2018 4:41:57 PM
WhenChangedUTC : 10/29/2021 9:17:18 AM
WhenCreatedUTC : 3/7/2018 3:41:57 PM
OrganizationId :
Id : EX21\Autodiscover (Default Web Site)
OriginatingServer : dc1.mccloud.global
IsValid : True
ObjectState : Changed
You can find all properties of this CMDlet here.
As you can see is ExternalUrl configured with a “local” domain and can not be used from the internet. This URL need to be changed to your public “External” domain to be reachable from the internet.
ExternalUrl :https://autodiscover.ex21.local/Autodiscover/Autodiscover.xmlSo we will use this command to change ExternalUrl
Get-AutodiscoverVirtualDirectory -Server EX21 | Set-AutodiscoverVirtualDirectory -ExternalUrl https://autodiscover.mccloud.cloud/Autodiscover/Autodiscover.xml You can find all parameters for this CMDlet here.
If you want / need to setup a different InternalURL, just do it. If you don’t set it up, InternalURL will be the same as ExternalURL automatically.
Authentication
Take care which authentication methods are configured. As long this is a public service and is reachable from the internet, you should disable all unused authentication methods to remove all security leaks from your environment.
In a secure environment you should use:
- OAuth (Modern Hybrid-Authentication)
- ADFS (On-Prem ADFS service)
Be aware that Outlook-Mobile clients will never use NTLM or WindowsAuthentication.
So, clarify internally if you really need these two options.
ECP
Exchange Admin Center (called ECP) is a part of Exchange-Webservices and is like all other Exchange-Webservices persistent on every Mailbox / CAS server.
ECP is always located at the same URL, just with a different domain.
Open your ECP and GoTO:
>
Here you can see all virtual directories in your Exchange-Organisation. We want to configure Autodiscover.
Select one this and GoTO “authentication”
As you can see, only the half of all options is available in ECP.
You can also read Microsoft Documentation for Autodiscover here.
Crucial things to know about Autodiscover
There are a lot of important things to know about AUTODISCOVER, most things are documented on Microsoft pages. I will list and explain only the crucial and most important things, which cause the most problems.
Certificate
Exchange web-services, requiring a certificate for secure connection to all services.
It is highly recommended to start with certificate planning before Exchange Installation!
Depends on your environment you can use
- Public certificate
- Private certificate
Depends on requirements of your organization.
If you are using ZERO-Trust environment (always on VPN) you can use “Private” certificate, but if you want to use “Hybrid-Environment” or “Hybrid-Modern (HMA)”, it is recommended to use a public certificate.
Be aware that you can use only 1 certificate for the whole environment chain.
Zero-Trust environment
If you have only secured and trusted connections (VPN or Internal) you can safely use a “Private” certificate and/or public one (costs more). You can provide all “Root” and “Issuing” CA certificates to your user and devices, and all requests will work without issues.
Such deployment may have issues with Outlook mobile app, because Outlook is always connecting to your On-Prem Exchange environment using MS-Sync protocol.
That means that Outlook is connecting to Exchange-Online first and Exchange-Online is connecting to Exchange-Onprem using active sync.
Exact MS-Sync documentation you can find here.
BUT:
- Make sure that all your E-Mail servers and Load-Balancers are responding to the web requests with a right name which is included in the certificate.
- You do not need to include all domains in your certificate, you just need to configure DNS in proper way.
- Use Exchange-Certificate wizard if you are not familiar with encryption and certificates.
- Make sure that all your Exchange-Servers and Load-Balancer have the same certificate installed.
- All requests to AUTODISCOVER are mainly based on your primary SMTP address, so make sure that your primary SMTP-address-domain is
o Included in your Certificate
o Configured in DNS
“Hybrid-Environment” or “Hybrid-Modern (HMA)”
In a Hybrid-Environment it is recommended to use “Microsoft Exchange Online” as front-end for all your E-Mail clients using Outlook.
Outlook is a cloud application and is always trying to connect to MS-Cloud, same as all MS-Cloud apps
In this scenario it is recommended to use “Public” certificate because Exchange-Online needs to have a proper trusted connection to your environment.
- Exchange-Online is responsible for AUTODISCOVER
- Public DNS configuration is very important here
Additional information about Hybrid-Modern-Exchange you can find here.
Please do not try to use a private certificate in this scenario!
DNS
Microsoft Exchange is a Directory Service and is fully based on DNS. DNS resolution and configuration is very important for every Directory Service.
Outlook Desktop and Outlook Mobile Client is always trying to reach Autodiscover URL first based on:
- Mailbox primary-smtp-address
o It is looking for SRV record for Autodiscover
o SRV record should show to Autodiscover of each maildomain
o Autodiscover of each maildomain is a CNAME of your MAIN maildomain which is included in your CERTIFICATE
- If you have no SRV record, your outlook will try to reach Autodiscover URL from primary SMTP domain of your mailbox
In Microsoft Documentation of Autodiscover, Outlook is trying to reach out to SCP configured in your Active Directory and is not looking for SRV first.
It’s true, but SCP is mostly wrong or not configured.
· You can configure only ONE SCP in whole AD forest, so if you have more than ONE accepted domain (and we have more in our use case) SCP cannot be found for alternate mail-domains.
· If your clients can not reach your domain-controller SCP will also not work.
· Only domain-joined devices can use SCP, so in that case Mobile-Devices, Macs, Linux and other clients can not reach out to SCP.
Loadbalancer
In out environment we have two load-balancer.
- First load-balancer is balancing Client-Access requests and proxying them to responsible DataAvailabilityGroup.
- Second load-balancer is balancing Client-Access requests to responsible Mailbox-Server
Load-Balancers are responsible for
1. All requests are balanced across all servers, so that you don’t have a bottle neck in your Exchange Environment
2. If one or more Exchange-Server/s are not available, load balancer will not forward any request to avoid time outs.
Load-balancers could also be a bottle neck in your environment if you have wrong sizing.
Load-balancers need to respond with the same FQDN as your Exchange-Servers.
Load-Balancers need to have the same Zertifikate as your Exchange-Servers.
Any kind of SSL or Packet Inspection is not supported, this will simulate a man in the middle attack and your clients will not be able to connect to your Exchange Servers.
Make sure that your SSL inspection is DISABLED
How to troubleshoot autodiscover
If you have checked your environment and autodiscover is implemented as explained in this article, you should have no issues with Autodiscover functionality.
If you have a problem with your Autodiscover, here is a checklist of all components which may cause a problem.
Status | Autodiscover availability from Internet (trusted IP) |
| DNS records |
| Port 80 |
| Port 443 |
| Autodiscover authentication (user login) |
| Autodiscover validation( certifikate) |
| Autodiscover .XML validation |
| Autodiscover configuratoin (Outlook) |
| Exchange authentication methods |
| Login using UPN |
| Domain\SamAccountname |
| Which Authentication methods are used |
| Basic |
| Bearer |
| Endpoints connectivity |
| OWA |
| ECP |
| RPC |
| PowerShell |
| MAPI |
| EWS |
| Availability check (Exchange vs ExO) |
| HMA configuration |
| Get-MapiVirtualDirectory | FL server,*url* |
| Get-WebServicesVirtualDirectory | FL server,*url* |
| Get-ClientAccessServer | fl Name, AutodiscoverServiceInternalUri |
| Get-OABVirtualDirectory | FL server,*url* |
| Get-AutodiscoverVirtualDirectory | FL server,*url* |
| Get-OutlookAnywhere | FL server,*hostname* |
| Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames |
| $x= Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 |
| $x.ServicePrincipalnames.Add("https://mail.corp.contoso.com/") |
| $x.ServicePrincipalnames.Add("https://owa.contoso.com/") |
| Set-MSOLServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 -ServicePrincipalNames $x.ServicePrincipalNames |
| Set ALL VD (Virtual Directories) accept OAuth |
| Get-AuthServer | where {$_.Name -like "EvoSts*"} | ft name,enabled |
| Set-AuthServer -Identity "EvoSTS - {GUID}" -DomainName "Tenant Domain" -IsDefaultAuthorizationEndpoint $true |
| Set-OrganizationConfig -OAuth2ClientProfileEnabled $true |
| Check Teams-Calender button persistance |
| Check Teams-Availibility Exchange vs ExO |
Microsoft is providing a great troubleshooting tool for Exchange-Connectivity issues.
With this tool and this article, you may be able to fix any issues.
Here is a script for Exchange-HMA troubleshooting.
If you have additional questions, just reach out to me.
I hope you have enjoyed this demystification article.
If you have any questions just leave me a feedback.