Exchange Autodiscover – The Active Directory SCP

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 and you configure Outlook using user@domain.local. This 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:

get-clientaccessserver | set-clientaccessserver -autodiscoverserviceinternaluri “https://servername.domain.com/Autodiscover/Autodiscover.xml”

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.

Final Note

Depending on your Outlook version and how your client machines connect, there is some additional configuration that will need to be completed to fully resolve any certificate errors you may have. Specifically, you will need to modify some of the Exchange Virtual Directory URLs to make sure they are returning the correct information to Autodiscover.

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 the one above can fix certificate errors.

Advertisements

34 responses to “Exchange Autodiscover – The Active Directory SCP

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

  2. 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)?

  3. “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.

    • I think I may have been brain dead when I wrote that. What I meant is that the computers have to be domain members before they will look at the SCP.

  4. 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.

  5. Your Active Directory link on the left is spelled wrong. Looks like a great blog I will investigate further though!

  6. 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.

    • 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.

  7. 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.

  8. 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?

    • 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.

      • Hello, tried to repair the account in Outlook (2016) accounts list, but the repair button is grayed out. How can I fix this?

      • 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.

  9. Used your articles to get a better understanding of the technical aspects of Autodiscover, and managed to solve my problems. Thanks a lot!

  10. 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.

  11. 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.

    • 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.
      Get-ewsvirtualdirectory | set-ewsvirtualdirectory -internalurl "https://mail.domain.com/ews/exchange.asmx
      Will do that

    • You will need to make sure that whatever you set your SCP for (and everything else) is an FDQN that is on the Certificate you’re using.

  12. 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..

    • 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.

  13. 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.

  14. 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.

    • 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).

  15. 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.

    • 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.

  16. 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s