I am writing this post today with my recent experience towards the Outlook client Autodiscover SCP look-up behavior and its impact in my Hybrid Exchange deployment, experienced few months before which unveiled few new things to me and this one applies to all sort of deployments with little variation per environment design and I thought of writing a post on this a while ago and got chance today to share my experience which would be helpful for you with your environment.
Every Exchange Admin knows how critical Autodiscover service is in an Exchange environment and above all he should have strong knowledge on how the Autodiscover needs to be configured and how it works internally and externally, what are the requirements to make it work seamlessly, how the outlook client performs the Autodiscover look-up when it is connected to internal network and how it varies with external network, and know how to troubleshoot issues when things go wrong on time, because without proper Autodiscover configuration you will end up in major service interruption. Thus impacting end user experience at larger scale.
This above said essentials are applied to all types of Exchange deployment from traditional single AD forest deployment, Cross forest deployments etc. and also applies for Office 365 fully cloud and Hybrid deployment.
We have excellent articles and whitepapers available over the Autodiscover topic already from Microsoft team and experts, So I am not going to cover them here instead have referenced them below for your ease of reading and understanding the subject.
If you are new to Autodiscover and also have some dilemma towards how Autodiscover functions in a Exchange Environment, what it is used for etc. then I would suggest you to learn Autodiscover fully by reading these below white paper and Blog posts from top to bottom before you proceed further.
Once you complete reading them you will master the Autodiscover. These resources are the ones I read when I started working with Autodiscover a while ago and gained more knowledge in the subject by working with various issues overtime in my tenure. There are more related resources available in the community and below are the best ones to my knowledge to begin and also it covers some deep dive stuff too. You can advance your learning on your own by exploring the topics and expand it as desired.
White Paper: Understanding the Exchange 2010 Autodiscover Service
Autodiscover, DNS, Certificates, and what you need to know - Elan Shudnow MVP
Exchange & The Autodiscover Web Service - Rhoderick Milne MSFT
Once you guys are ready, lets get in to our topic, As you now know how the autodiscover look-up occurs with in a Exchange Environment by Clients connecting through Internal and External network we begin here.
Outlook Client from 2007 relies on Autodiscover and when you read from the above posts it clearly says that
first thing it will check when connected to the internal network is the
SCP (Service Connection Point) in your AD through which it obtains the necessary configuration and serves the outlook client to get the required URLs to make a proper outlook configuration. Also you'd now come to know how vital SSL certificate is for Autodiscover and also for other related services to work for Exchange, so if you have more CAS servers in your environment you will end up adding more names to your Cert and also using Self signed cert is not advisable and If you about to publish your environment to be accessible for outside world you will for sure go for a 3rd party Public CA and this makes additional cost to your cert when you add more FQDNs of your CAS Servers ( Keep in Mind CAS Array name does not need to be available on the Cert only you will add the CAS Server FQDNs as needed if you don't have a common name space) so the best way is to use a common name space like "autodiscover.domain.com" for all your CAS servers as a Autodiscover namespace and configure the Client Access server
AutodiscoverInternalURI for SCP and also the External URI on the internet facing CAS accordingly and get things simplified and load balance the Autodisocover requests through your Load Balancer, if you are using "
Split-DNS" then you can utilize the same cert and configure your internal and public DNS end points accordingly for Autodiscover.
Though this is done, the next major thing you would have noticed is the "
AutodiscoverSiteScope" which clearly makes your Outlook to connect to the appropriate servers with in the site boundary you define, thus saving lot of time and if this is not set properly then you will end up with your client choosing a random server in a different region for connection, thus causing outlook performance issue due to latency and breaking your HA and SR design if you plan any and also potentially cause other few issues which we are about to discuss soon. So defining proper
Sitescope makes your life easier and clients to work smoothly.
Next, lets come to the Autodiscover look-up cycle if you would have noticed how the look-up begins and how it go through the next cycle one method fails towards the other as shown below obtained from one of the reference article in-accordance with our topic and this remains the same with all internally connected outlook clients from 2007 through the latest 2013.
First -> SCP Lookup -> Fails
Next -> https://<smtpdomain>/Autodiscover/Autodiscover.xml -> Fails
Next -> https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml -> Fails
Next -> http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml -> Fails
Next -> SRV record query for _autodiscover._tcp.<smtpdomain> -
Success
*One Key point here is to note is how Organizations decide to publish their Autodiscover to External clients and if you are an On premises customer then you will publish it through your TMG or any other alternative and configure the DNS end point accordingly and for doing this the key requirement is the autodiscover name space you use and the corresponding SAN entry in the SSL certificate and most Organizations depending up on their need and cost effectiveness either go for the "autodiscover.domain.com" SAN name or will use the DNS SRV record method instead to point to a common name space which is already made available on the cert like OWA name space which will in-turn point to the appropriate end point in DNS and serve the client Autodiscover request. Publishing Autodiscover externally is mandate when you go for Office 365 and you can adopt any one method stated above per your needs and the most suggested one is to use the separate namespace for autodiscover using A record in public DNS for Hybrid.
We would concentrate on the
SCP and Autodiscover DNS record with respect to Office 365 both fully cloud and Hybrid deployment, so if you understood things correctly the way Outlook client connected internally which will first look for SCP and this behavior remains the same with the Internal Outlook clients connecting to Office 365 in both fully cloud and Hybrid deployments.
Autodiscover end point is the key for the Outlook connection to work with Office 365 and when it comes to
fully cloud deployment we will have the Autodiscover endpoint "Autodiscover.domain.com" in Internal DNS configured to point to
Autodiscover.outlook.com which redirects the client request to Microsoft Servers successfully and when it comes to
Hybrid deployment we will point the "Autodiscover.domain.com" to the
Hybrid server which will do the redirection accordingly to O365 per deployment guidelines.
So from above points its clear that we rely on the DNS records and not the SCP for the Autodiscover to work with Office 365, so in this scenario if you have more CAS servers in your environments and you will end up with
multiple SCP records and though there is a site scope defined still the Outlook client has to pass through the same Autodiscover logic when it connects to Office 365 and thus causing additional work for the client through multiple redirect attempts before the client actually gets through all the SCP look-ups to get failed one after the other till last, after which it fallback to DNS and get redirected successfully and if you have crossed the
default look-up limit (10 ) which is inclusive of all redirect attempts you will end up with your client not being able to connect to Office 365 using Autodiscover as it exceeds the maximum redirect limit and fails to connect.
You can review the excellent post from
Good Workaround blog explaining the above said facts for your clear understanding with real time examples with solution which helped me out as an add-on during my experience.
Outlook AutoDiscover redirect limit (0x800c8206)
See the below example on the same and inhere it shows the SCP failure with 2 CAS servers and if you have more it will fail for all and gets counted towards the redirect count.
If you understood the post clearly you will come to know how things work with Outlook client in Office 365 Environment and what is the impact of SCP and how to over come it, lets add some more add-on points to the above resolution from my experience which varies from fully cloud to Hybrid deployment.
Also when it comes to Office 365 it is still considered as a cross forest look-up and there is a
timeout limit for Autodiscover operation and you may need to address this too if you come across any issues here, but from my knowledge the major issue people will face in a Lager Exchange environment is towards the Autodiscover Sitescope defined to make a CAS server in one site to serve the needs for a client connecting from another site by defining multiple sites under the sitescope and this applies the same for Cross site Exchange deployment involving multiple servers at both ends and in our case its between our On premises Exchange server and O365 in Hybrid model, Even this is clearly updated to you in a nutshell in the above post.
Check here to know about the Autodiscover timeout limit :
Modify the Time Limit for Autodiscover Operations
So setting AutodiscoverSiteScope is good for staying safe but will it be useful if you are a
fully cloud customer and your goal is to stay on cloud and you still have a On premise Exchange Server just to mange objects and for other reasons with no mailboxes hosted On premises which is a multi role server and has a CAS role installed to it and you have successfully decommission the Hybrid setup, At this stage since this server is a part of your Exchange Organization it will be then counted in the Outlook Autodiscover look-up with its SCP per exchange design and Outlook client behavior. So the best thing here is to disable AutodiscoverInternalURI itself on the CAS server end so that Client will end up using the DNS endpoint which will properly be set to Cloud and things would work properly.
You can disable the Autodiscover using the below cmdlet
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $null
Remove the role CAS Role from the server leaving other roles intact if you need, but I would recommend let it stay as it is, because it will be useful for you to re-establish Hybrid deployment again at ease through HCW when needed, You have moved to Cloud now successfully and configured things accordingly lets say at a later stage there comes a critical requirement and you need to host some users On premises again need a Hybrid, so being proactive is good as Organization dependency varies overtime, but this is still your choice.
When it comes to
Hybrid deployment which is fully functional and your goal is long tern co-existence and you host mailboxes both On premises and cloud, then we
cannot disable the SCP because your entire On premises deployment relies on the SCP and this is preferred method for Autodiscover to work in an On-premises Environment and here is the tricky part, which we discussed above will come in to picture. Since we cannot disable the Autodiscover SCP records we end up with the Autodiscover Client time out issues if we have more servers in the Environment which are falling beyond the default limit and also AutodiscoverSiteScope configuration cannot help us if there are more servers within the site itself which will make the count more than the default limit . So the best approach here is to use the Registry settings workaround stated in the above Good Workaround post and the below Microsoft Knowledge base article that contains the
Registry key which will control the
Client SCP look-up behavior and shows you with a live example using Outlook Client Test Email Autoconfiguration results for reference. Setting this registry value as shown will stop the client from performing the SCP look-up and it will directly use the next step to attempt the connection which is our DNS endpoint (Autodiscover.domain.com) and connect accordingly.
Check here :
Unexpected Autodiscover behavior when you have registry settings under the \Autodiscover key
Registry
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover]
"ExcludeScpLookup"=dword:00000001
You can either do this on a whole for all users irrespective of Cloud or On premises or do it selectively alone for Cloud mailbox users and leave the On premises users outlook client as is. If you want to disable Autdodiscover SCP Look-up on a whole including your On premises Environment you need to ensure that your have configured your Internal Autodiscover DNS record properly which will server the needs for both On premises and Cloud seamlessly. If you go with this route you have the ability of forcing this changes through GPO on a whole environment or selectively at ease to get things addressed at the earliest.
Also one more point to add above all, If you are having less number of servers in a Hybrid deployment within the limit then you need not do this on urgent basis, but this is still an advisable one to be performed to ensure that your Cloud user's outlook client gets to the appropriate end point on time with out having to go through multiple re-directs which typically enhances the client experience.
Finally, you guys now understood the reason behind the Outlook Client behavior and the role of SCP with Office 365 and why I recommend to disable this and what benefit you will get and the proper planning you should take care when you are in a Hybrid deployment. I believe this post will be a good read and new experience for readers and for sure assist you to understand how Autodiscover plays a vital part in your Exchange and how you can play around with it safely for a better end user and support experience.
Always ensure that you set your Autodiscover correctly to make things work inside your Organization effectively and always validate it often though you have issues or not periodically and you can utilize the easy way of checking things interms of both On premises and Office 365 environment with the help of none other than our
Remote Connectivity Analyzer Tool.
*Additionally, Read the below related Excellent write up from
MVP Dave Stork on his blog performing one more Optimization over Autodiscover.
Optimizing the Outlook AutoDiscover process by skipping the root domain query
Update:
Here comes the
Official Knowledge base article from Microsoft relevant to this topic with the same workaround mentioned above
.
Outlook hangs when connecting to an Exchange Online mailbox that was migrated from on-premises Exchange Server
Its great that now we have a knowledge base article available handy in place with the workaround to assist customers on time.
Update:
Read the below excellent write-up from our
Rhoderick Milne MSFT on
Office 365 Autodiscover Lookup Process and experience the hidden behavior of Outlook 2013 Autodiscover process and how it varies from Outlook 2010, A must read I would say, that adds more value for your learning on this topic.
Access here:
Office 365 Autodiscover Lookup Process
Update:
Another great post from
Rhoderick Milne MSFT to solve the Autodiscover confusion on Hybrid deployments
Access here:
Office 365 Exchange Hybrid Deployments Busting The Autodiscover Myth
Update:
Understanding how Hybrid Authentication works is essential for every IT Pro who works with Microsoft Exchange On premises and Online.
Access here:
Deep Dive: How Hybrid Authentication Really Works
Update:
Understand how Hybrid Free/Busy is working
Access here:
Demystifying Hybrid Free/Busy: what are the moving parts?
Update:
Access the below support article to troubleshoot free/busy problems that occur in a hybrid deployment of on-premises Microsoft Exchange Server and Microsoft Exchange Online in Office 365.
Access here:
How to troubleshoot free/busy issues in a hybrid deployment of on-premises Exchange Server and Exchange Online in Office 365
New Update:
As More mailboxes are migrated to Exchange Online, Microsoft team decided to make significant
change to the Autodiscover behaviour starting from
Outlook 2016 version 16.0.6741.2017 (C2R), and give priority to Office 365 and Now Autodiscover process checks for the availability of Exchange Online Mailbox first, and below is the new process
- Check for restart scenarios (rare).
- Check for Local Data preference - Local Autodiscover.xml file by using GPO
- Check for Last Known Good (LKG) data.
- Check for Office 365 as priority.
- Check for SCP data.
- Check root domain
- Check Autodiscover domain.
- Check for Local data - When there is no GPO specified in Step 2
- Check for HTTP Redirect.
- Check for SRV data
- Check for O365 as Failsafe (when all other options fail)
More details are provided in this support Article:
Outlook 2016 implementation of Autodiscover
Due to this new change, there a few
issues faced by Users as updated in the below User voice post covering the scenarios
User Voice: Stop prioritizing O365 for Autodiscover
But the response from Microsoft team states that
there will be no changes made to the new process and they will continue to optimize for the Office 365 experience, This created a bit of headache for the Administrators and the current solution is to follow the
workaround described in the below support article and exclude Office 365 (
ExcludeExplicitO365Endpoint) from the list of locations checked by Autodiscover.
Access here: Unexpected Autodiscover behavior when you have registry settings under the \Autodiscover key
Stay tune for more updates...
.png)
.png)
