Exchange Autodiscover – The Active Directory SCP

April 4, 2014 46 Comments

In a previous post I explained how you can use a SRV record to resolve certificate issues with Autodiscover when your Internal domain isn’t the same as your Email domain. This time, I’m going to explain how to fix things by making changes to Exchange and Active Directory that will allow things to function normally without having to use a SRV record or any DNS records at all, for that matter. But only if the computers that access Exchange are members of your Domain. The Active Directory SCP is how Exchange hands out Autodiscover configuration URLs by default without any DNS or SRV records. However, if you have an Private Domain Name in your AD environment, which you should try to avoid when you’re building new environments now, you will always get a Certificate Error when you use Outlook because SSL certificates from third party CA providers won’t do private domains on SAN certificates anymore. To fix this little problem, I will first give you a little information on a lesser known feature in Active Directory called the Service Connection Point (SCP).

Service Connection Points

SCPs play an Important role in Active Directory. They are basically entries in the Active Directory Configuration Partition that define how domain based users and computers can connect to various services on the domain. Hence the name Service Connection Point. These will typically show up in one of the Active Directory tools that a lot of people overlook, but is *extremely* important in Exchange since 2007 was released, Active Directory Sites and Services (ADSS). ADSS is typically used to define replication boundaries and paths for Active Directory Domain Controllers, and Exchange uses the information in ADSS to direct users to the appropriate Exchange server in large environments with multiple AD Sites. But what you can also do is view and make changes to the SCPs that are set up in your AD environment. You do this with a feature that is overlooked even more than ADSS itself, the Services node in ADSS. This can be exposed by right clicking the Active Directory Sites and Services object when you have ADSS open, selecting view, then clicking “Show Services Node” like this:

ADSS - Services Node

Once you open the services node, you can see a lot of the stuff that AD uses in the back end to make things work in the domain. Our focus here, however, is Exchange, so go into the Microsoft Exchange node. You’ll see your Exchange Organization’s name there, and you can then expand it to view all of the Service Connection Points that are related to Exchange. I wouldn’t recommend making any changes in here unless you really know what you’re doing, since this view is very similar to ADSIEdit in that it allows you to examine stuff that can very rapidly break things in Active Directory.

Changing the Exchange Autodiscover SCP

If we look into the Microsoft Exchange services tree, you first see the Organization Name. Expand this, then navigate to the Administrative Group section. In any Exchange version that supports Autodiscover, this will show up as First Administrative Group (FYDIBOHF23SPDLT). If the long string of letters confuses you, don’t worry about it. That’s just a joke the developers of Exchange 2007 put into the system. It’s a +1 Caesar Cipher that means EXCHANGE12ROCKS when decoded. Programmers don’t get much humor in life, so we’ll just have to forgive them for that and move on. Once you expand the administrative group node, you’ll be able to see most of the configuration options for Exchange that are stored in AD. Most of these shouldn’t be touched. For now, expand the Servers node. This is the section that defines all of your Exchange servers and how client systems can connect to them. If you dig around in here. Mostly you just see folders, but if you right click on any of them and click Properties, you should be able to view an Attributes tab (in Windows 2008+, at least, prior to that you have to use ADSIEdit to expose the attributes involved in the Services for ADSS). There are lots of cool things you can do in here, like change the maximum size of your Transaction Log files, implement strict limits on number of databases per server, change how much the database grows when there isn’t enough space in the database to commit a transaction, and other fun things. What we’re focusing on here is Autodiscover, though, so expand the Protocols tree, then go to Autodiscover, as seen below.

autodiscover node

Now that we’re here, we see each one of the Exchange CAS servers in our environment. Mine is called Exchange2013 because I am an incredibly creative individual (Except when naming servers). Again, you can right click the server name and then select Properties, then go to the Attribute Editor tab to view all the stuff that you can control about Autodiscover here. It looks like a lot of stuff, right? Well, you’ll really only want to worry about two attributes here. The rest are defined and used by Exchange to do…Exchangey stuff (Technical term). And you’ll really only ever want to change one of them. The two attributes you should know the purpose of are “keywords” and “serviceBindingInformation”.

  • keywords: This attribute, as you may have noticed, defines the Active Directory Site that the CAS server is located in. This is filled in automatically by the Exchange subsystem in AD based on the IP address of the server. If you haven’t created subnets in ADSS and assigned them to the appropriate site, this value will always be the Default site. If you change this attribute, it will get written over in short order, and you’ll likely break client access until the re-write occurs. The *purpose* of this value is to allow the Autodiscover Service to assign a CAS server based on AD site. So, if you have 2 Exchange Servers, one in site A and another in site B, this value will ensure that clients in site A get configured to use the CAS server in that site, rather than crossing a replication boundary to view stuff in site B.
  • serviceBindingInformation: Here’s the value we are most concerned with in this post! This is the value that defines where Active Directory Domain joined computers will go for Autodiscover Information when you enter their email address as username@domain.local if you have a private domain name in your AD environment. By default, this value will be the full FQDN of the server, as it is seen in the Active Directory Domain’s DNS forward lookup zone. So, when domain joined computers configure Outlook using user@domain.local they will look this information up automatically regardless of any other Autodiscover, SRV, or other records that exist in DNS for the internal DNS zone. Note: If your email domain is different from your AD domain, you may need to use your AD domain as the email domain when configuring Outlook for the SCP lookup to occur. If you do not want to use the AD Domain to configure users, you will want to make sure there is an Autodiscover DNS record in the DNS zone you use for your EMail Domain.

Now, since we know that the serviceBindingInformation value sets the URL that Outlook will use for Autodiscover, we can change it directly through ADSS or ADSIEdit by replacing what’s there with https://servername.domain.com/Autodiscover/Autodiscover.xml . Once you do this, internal clients on the domain that use user@domain.local to configure Outlook will be properly directed to a value that is on the certificate and can be properly configured without certificate errors.

Now, if you’re a little nervous about making changes this way, you can actually change the value of the serviceBindingInformation attribute by using the Exchange Management Shell. You do this by running the following command:

1
get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri "https://servername.domain.com/Autodiscover/Autodiscover.xml"

(Remove the space from the end of the URL.)

This will directly modify the Exchange AD SCP and allow your clients to use Autodiscover without getting certificate errors. Not too difficult and you don’t have to worry about split DNS or SRV records. Note, though, that like the SRV record you will be forcing your internal clients to go out of your network to the Internet to access your Exchange server. To keep this from happening, you will have to have an Internal version of your External DNS zone that has Internal IPs assigned in all the A records. There just is no way around that with private domain names any longer.

Avoiding Issues with Certificates in Exchange 2007+

For information, modern Active Directory Best Practices can help you avoid having trouble with certificate errors in Exchange. Go here to see some information about modern AD Domain Naming best practices. If you follow that best practice when creating your AD environment, you won’t have to worry so much about certificate errors in Exchange, as long as the Certificate you use has the Exchange Server(s) name listed. However, if you can’t build a new environment or aren’t already planning to migrate to a new AD environment in the near future, it isn’t worth the effort to do so when small configuration changes like setting the SCP

Office 365 SCP Issues

At this point, most organizations are moving to or have moved to Office 365 for email. However, during this process, you may discover some issues when you shut down your on-prem endpoint for Exchange after migration is complete. Specifically, the SCP value is still picked up by Outlook during the autodiscover process, resulting in slow or failed attempts to connect. This can be fixed by modifying the SCP to point to Office 365. Particularly, reconfigure the SCP so it points to Autodiscover-s.outlook.com or autodiscover.domain.com if you have pointed that value up. Make sure that any on-prem DNS records for autodiscover.domain.com and autodiscover.domain.local are also redirecting to autodiscover-s.outlook.com for the domain’s autodiscover record(s), whether using CNAME, A, or SRV records.

More on Autodiscover

Configure Exchange Autodiscover
Exchange Autodiscover – The Active Directory SCP
Configuring Autodiscover for Internal DNS
QuickPost: What do Exchange Virtual Directories Do?
Configuring Exchange Virtual Directories
Fixing Outlook Certificate Errors
Controlling Autodiscover with Registry or GPO
Autodiscover – Microsoft Docs

46 thoughts on “Exchange Autodiscover – The Active Directory SCP”

  1. Hi, Great Article,

    I think this is exactly what I need to solve my problem, one question! When I go through ADSS and get down to where i need to be I don’t have the attribute editor available? Do you know how to get this up? It appears in AD Users and Computers fine? Been trying to find a solution for a while now and cannot seem to get one.

    If you have any ideas then let me know

    Cheers

    1. To be honest, I’ve never seen a situation where the attribute editor didn’t show up in AD S&S. Except for when I was working with server 2003 (Attribute tab wasn’t added until server 2008, I think). You can get the same effect with the following command in Exchange Powershell: get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri “https://servername.domain.com/Autodiscover/Autodiscover.xml”

      1. I’ve run the commands and the record has changed now, I can see when I run the auto-discover tests that the SCP is being used and is correct, but it only returns a http401 error for me, got any ideas? When I browse to the auto discover I am given the prompts and then get the 600 error as expected but for some reason Outlook just is not having it

          1. That hasn’t worked either, as far as I can see all the permissions are correct. I’m stumped at this, have you got any other ideas?

          2. Hold ctrl while right clicking the Outlook icon in the notification area. It’ll add a new option for a connectivity test. Run that and see where the problem is coming from

          3. Its all good I got it working, turns out it was a typo in the DNS record, altered and now working perfectly.

  2. Pingback: How can I fix Autodiscover for local clients in on premise Exchange 2013 – Mags Forum Technology

  3. I’m so tired of looking for examples of how to set up a site where you actually have more than one exchange server. Apparently every site that runs Exchange as an email service has only one server, one autodiscover internal DNS entry with one IP, and it all works. Unfortunately, I’m an idiot, I have more than one server for redundancy and such, and I’m trying to determine if I should have an autodiscover record in my internal DNS for just one server, or for all of them. I mean, we are talking about redundancy after all, right. So if you have an internal namespace of vfr.dataways.com and an external namespace/SMTP name as dataways.com with 2 CA servers and 4 DAG Exchange servers, just what should your autodiscover service be configured as on the inside? Should every server have the internal URL’s listed as the servername.vfr.dataways.com (which kind of negates any redundancy you might have decided to engineer into the system) or should all the URL’s be the same? I know I’m bucking the trend here with more than one Exchange server, but does anyone have any suggestions as to how to set this up correctly, because right now, all my Exchange connections appear to go to the public web site URL’s instead on the internal ones, which is really pissing me off since everyone loses their Outlook connection if the ISP drops.

    1. The best practice for Exchange High Availability is to use a hardware load balancer to handle client access and configure DNS with an A record for autodiscover (and whatever else you want to use as the server name) that points to the Virtual IP of the load balanced application (OWA/EWS/Etc). From there, all URLs for Exchange should use the DNS records for Autodiscover or mail.domain.com or whatever else you want to have. The important part is that the Exchange CAS servers/URLs need to be load balanced for true redundancy. If you don’t have a load balancer, you would want to pick a single server as the “Primary” mail server and configure all URLs to point to that. If the primary server fails, you would need to manually change DNS to point to the “Secondary” server. Exchange will allow you to access mailboxes that sit on the secondary server through the primary, so you only ever have to have DNS records for client access pointing to one of them at a time, but a load balancer is required if you want to avoid manual intervention in a failure. You can also use Round Robin DNS to do things, but that doesn’t work very well in practice and causes random slowness and connectivity issues when one server fails.

      Regarding the issue of clients using the Public web site URLs, you can resolve this by setting up DNS records that point autodiscover.dataways.com and mail.dataways.com to the Internal IP address of the Load Balancer or primary server. You can do this easily by adding Pinpoint DNS records to the domain’s DNS. https://acbrownit.com/2017/04/24/resolving-the-internalexternal-dns-zone-dilemma/ explains how to do this. With the pinpoint records in place, clients on the domain will use the Internal DNS records when running the Autodiscover and other lookups.

      The key here is that Exchange High Availability and redundancy requires a load balancer to function. In Exchange 2010, you could separate the CAS and MBX roles on different servers and use the NLB features in windows for load balancing, but that was actually more expensive than most entry level load balancers and MS told people to avoid doing it anyway. That configuration isn’t supported in 2013 and later. Any multi-server solution that doesn’t have a load balancer will require manual intervention to work.

  4. We have two domains ( Domain A and Domain B ) and an exchange environment for each

    If computer is joined to Domain A and user from Domain B logs on to this computer.
    how will outlook get scp information ? from domain A or Domain B ?
    Currently we have an issue where in situation explained above , outlook fails auto discovery and fails outlook setup.

    Any advice would be appreciated ! thanks

    1. The SCP lookup in your situation would connect to the domain the computer is connected to to check the SCP before moving on with the process. Since both domains have SCPs configured in them, doing a cross-domain Autodiscover check will ultimately fail because the autodiscover request that gets done uses an invalid email address, username, and password. The way to handle this would be to disable the SCP lookup step on domain joined computers in both domains if they need to have cross-domain accounts set up. You can do this in a couple ways, one is to push out a GPO that forces Outlook to skip the SCP lookup step (This is more labor intensive, since it requires downloading, installing, and configuring the GPO templates for Office for each version your company uses). The other way is to set the SCP value in each domain to NULL run get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri $null in Exchange Powershell to do that. If the SCPs are Null, clients will fail on that step and move on to the non-joined lookup steps.

  5. Can I just say that your explanation was very thorough and nicely done – I was jumping around many websites but none I found seemed to address the common problem where the email domain and the AD domain name is different. Thanks.

  7. I am running Exchange 2010, with internal and external discovery addresses set the same. You noted that if this is so, you need to make a DNS entry on the DC for autodiscover. Would this be an A or a CNAME? A only lets me point to an IP, not a URL like http://mail.scottxxxx.org. What should the record type and contents be?
    I have OWA and cell phone access working but not Outlook Anywhere – Outlook can’t connect when trying to add to profile.

    1. You can use either an A record or CNAME. If you use an A record, set it to the IP address of the exchange server (Internal, preferably). If you use a CNAME, it needs to point to one of the existing DNS records that points to Exchange.

  8. Great articles! I didn’t know how little I knew about the autodiscover process. It’s much clearer now. Thanks for writing them.

    You mention that SCP helps clients find a CAS in their site to prevent them from “crossing a replication boundary.” If all CAS servers in a site are down, will the client attempt to connect to a CAS in a different site or simply fail the SCP autodiscovery and fall through to the DNS autodiscover methods? I ask because we suffered a server outage which took the local servers offline. The databases (in a stretched DAG) properly failed over to another site but the clients were unable to connect. Just wondering if that is by design or if we have something configured less robustly that it should be. Thanks.

    1. Hypothetically (meaning I haven’t tested this, but based on documentation, this is how it should work), setting the SCP to a different URL for each Exchange server should allow you to get better failover for clients, but it requires perfect setup of ADSS.

      Specifically, each Exchange server needs to be assigned to the AD site they “belong” to. That is a different process that is automated by the Exchange Topology service, which examines the servers’ IP address, then checks ADSS to determine which site contains the subnet that IP is in.

      In other words, if you have sites set up in ADSS, but don’t have subnets assigned to those sites (which happens almost all the time), the Exchange servers cannot effectively determine site membership, and SCP redirection will likely fail.

      https://msdn.microsoft.com/en-us/library/office/dn467395(v=exchg.150).aspx has a good explanation of how SCP lookups are *supposed* to work. The Keywords attribute on the Autodiscover object for each server is written by the Topology service based on what it finds.

      With all that said, best practices are to use Site Resilient load balancing on CAS servers in stretched DAGs to ensure that *all* clients can access the autodiscover servers without having to modify DNS. Since only domain joined clients are able to access the SCP, using only the SCP for failover means that only domain joined systems on the local network will be able to access Exchange in a failover (If that method works for failover at all, and I can’t say if it does for sure because I haven’t tested it).

  9. Thank you so much. I though I had checked everything but when I used “Test Email Auto Configuration” by clicking outlook icon at bottom right of screen it showed me that my mapi virtual directory was set to internal address. I changed this mapi directory using the following command
    Set-MapiVirtualDirectory -Identity “machinename.domain.local\mapi (Default Web Site)” -InternalUrl https://www.domainltd.com/mapi -IISAuthenticationMethods NTLM,Negotiate
    This worked but outlook cache was still looking to internal address. I adjusted account to not use cache, started outlook and then closed outlook. Then enabled cache again and it connected fine.
    Thanks again.

  10. When I apply DNS changes how do I ensure that the account I am opening outlook with is picking up those changes, I have run “ipconfig /flushdns” on client pc and cleared cache on local dns on server. I still get machinename.domain.local the name on the security certificate is invalid or does not matchthe name of the site..

    1. That should clear DNS for you. There’s probably some other Virtual Directories still set wrong, though. If you go to the taskbar, there should be a little outlook icon by the clock. If you hold control down and right click it, it’ll give a hidden option that says “Test Outlook Autoconfiguration”. Run that and see what it says.

  12. Not much hair left. I have adjusted scp to ping to mail.domain.com and my cert points to mail.domain.com but I am still getting certificate errors. Not quite sure where I have gone wrong. Tried autodiscover route as well but cannot sort problem.

    1. If your cert only has mail.domain.com listed, you’ll want to use a SRV record in DNS for non domain clients. Also, depending on you Outlook version, you’ll need to configure the EWS virtual directory.

      1
      Get-ewsvirtualdirectory | set-ewsvirtualdirectory -internalurl "https://mail.domain.com/ews/exchange.asmx

      Will do that

  13. Thank you so much for posting this! Our Go Daddy cert would not allow local addresses and of course Exchange 2013 puts the local FQDN in AD. I followed your instructions and put the mail.domain.net and no more cert errors.

  16. Hey there –

    I’ve built many Exchange servers and run the command line single name cert fixes, and never had an issue…until now.

    I see in EWS that my autodiscover address is the same as my cert name.

    I see in Test Outlook Auto Config that my autodiscover address is the same as my cert name.

    I see in ADSS that this attribute is the same as my cert name.

    But….when anyone opens Outlook it continues to give the certificate error saying that its looking for autodiscover.mydomain.com. This has been an issue for a LONG time so I know its not just a replication/time/reboot issue.

    Anyone know if there is anywhere else I can look?

    1. If the mail profiles were created before the Configuration was set to match the cert, they will cache the values that were there before indefinitely. Doing a repair on the Exchange account in the mail profile will usually fix this.

        1. I haven’t yet worked with Outlook 2016, so I don’t know what might cause this. If the repair button isn’t available, it may be due to a GPO setting blocking it, though. You can complete a repair by recreating the user’s mail profile in most instances, but this does, of course, result in the OST file being recreated.

  17. Argh – our marketing person just moved to a Shared Hosting provider that has a Shopping Cart feature – which means Shared SSL Certificate.
    Exchange Autodiscover (damn you!) looks at domain.com/autodiscover first for its instructions and of course the names do not match.
    Why can’t Microsoft just remove this lookup from Outlook.
    There are a ton of companies using Shared Webhosting that encounter this issue.

  18. In an Exchange 2013 environment this did not work for us. I believe that the autodiscover service looks at multiple attributes. Changing just the “AutoDiscoverServiceInternalUri” did not resolve it. I have not tried changing the CN for Autodiscover as this was a live environment.
    Any ideas? Internal domain is the same as external as recommended by MS.

    1. Exchange 2013 functions differently than Exchange 2010, which is what I wrote this article for. One of the big differences is that 2013 utilizes Outlook Anywhere (RPC over HTTPS) for all connections to the server. As a result, you’ll want to change the setting for the AutodiscoverServiceExternalURI as well, since this is the value that is used when communicating with Outlook Anywhere clients.

  20. It didn’t work, still getting the certificate warning: The name of the security certificate is invalid or does not match the name of the site.

    Had to revert the changes back or would have had many calls about the message.

  21. “IMPORTANT NOTE!!!: Only attempts to configure Outlook profiles using the AD Domain name as the email domain will pull the SCP record!!!”

    Do you have any references to documentation on this please? We have “user@company.com” primary addresses and a “company.local” AD name. But the internal autodiscover test email configuration with a “user@company.com” address still works fine.

  22. So I can set the name in SCP to be same as my external SSL Cert “mail.doamin.com” even though my internal domain is not the same as the external domain (mail.domain.local)?

  23. Is the servername in “https://servername.domain.com/Autodiscover/Autodiscover.xml” supposed to be “https://autodiscover.domain.com/Autodiscover/Autodiscover.xml”?

Leave a Reply