RSS Subscription 168 Posts and 2,769 Comments

Configuring Exchange 2007 Autodiscover Site Affinity

Autodiscover site Affinity is used in environments where you do not have good connectivity between all your sites and you would like Outlook 2007 clients to utilize Autodiscover services on a Client Access Server (CAS) to which the client would have good connectivity with.  Or even if you have good or decent connectivity between your sites, you may still prefer for Outlook 2007 clients to utilize Autodiscover services on a Client Access Server in a site that is local to that client.

In our example, our company is dispersed across three countries; USA, China, and Germany.  Our Active Directory (AD) infrastructure consists of many sites.  All sites in the USA are connected via high-speed reliable dedicated fiber lines.  All sites in China are connected via high-speed fiber lines.  All sites in Germany are also connected via high speed reliable dedicated fiber lines. Every country is connected to each other via a much slower link.  Because of this, you would like all Outlook 2007 clients to use their Autodiscover services within their own country regardless of which site they are in.

In the United States, we have 3 sites:

  • US-California
  • US-Chicago
  • US-Florida

In Germany, we have 3 sites:

  • DE-Hamburg
  • DE-Frankfurt
  • DE-Leipzig

In China, we have 3 sites:

  • CN-Shanghai
  • CN-HongKong
  • CN-Chengdu

All sites within the the United States are configured with T3 links in which each site can talk to each other.  All sites within Germany are configured with E3 links in which each site can talk to each other.  All sites within China are configured with links that are similar in speed to a T3/E3 in which each site can talk to each other.  Each country talks to each other via links comparable to the speed of a T1.  As you can see, intra-country communication is occurring over a much faster link than inter-country communications.  So how can we restrict clients to utilize Autodiscover services from Client Access Servers within their own country?

This can be achieved by using Autodiscover Site Affinity.  To understand Autodiscover Site Affinity, we must first understand how the Autodiscover Service works internally within the organization for domain joined Outlook 2007 clients.

Internal Clients who are domain joined will first try to contact Active Directory for Service Connection Point (SCP) information.  Each time a CAS is installed into your Forest, that CAS will create an SCP in AD which provides a mean for Outlook 2007 clients to figure out the URL it should access Autodiscover.  This SCP is created in the following location:

CN=Autodiscover,CN=Protocols,CN=<CASServer>,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services

To manually configure the SCP, you can run the following command:

Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri

By default, the SCP is configured with the following URL (Uses NetBIOS instead of FQDN):


When your organization is set up in a single-site fashion or you don’t care about Site Affinity, this is really easy to set up.  Just pick one common URL and set all your Client Access Servers to use that URL.  Or you can leave the URL at its default which uses its’ servername instead of an FQDN.  The use between using a common FQDN or leaving it at the default NetBIOS name is significant.  I will go into this later on though.

When we use Site Affinity, we have to be more careful with what our FQDNs as we want Outlook 2007 clients in their respective countries to obtain an FQDN that belongs to a Client Access Server within their own country.

There are two methods we can do to achieve Autodiscover Site Affinity.

Method 1

We will create a custom DNS record for each country that will Round Robin your client requests to the CAS Servers in their respective countries.  The following FQDNs will be:

  • United States –
  • Germany –
  • China –

Create three host records for each country (9 total).  Three host records for affinityUS that round robin requests between CAS Servers in each site in USA, three host records for affinityDE that round robin requests between CAS Servers in each site in Germany, and three host records for affinityCN that round robin requests between CAS Servers in each site in China.

If you recall, I stated that when any CAS is installed, it creates an SCP that contains the FQDN for the Autodiscover Service.  We now have to modify this SCP so it contains a Site Scope. Outlook 2007 by default will select an SCP at random to use.  Now this is very important.  If you left the default FQDNs for each CAS to their NetBIOS name, your autodiscover requests will be all over the place but your requests will be balanced between your CAS Servers due to every FQDN being set using the CAS Servers NetBIOS name.  If you set the FQDN for every SCP in your environment to use a common FQDN, the server that FQDN is set to will be getting hammered with all the Autodiscover requests depending on Netmask Ordering option in DNS talked about below.

One thing to keep in mind is that WIndows DNS Servers provide an option called Netmask ordering which is enabled by default.  This is essentially a subnet prioritization feature that works before round robin. With Windows 2000 DNS, if both netmask ordering and round robin are enabled, only netmask ordering is utilized and the addresses are provided in the same order.  If Windows 2003 is utilized, Netmask ordering is utilized but the addresses will still be prioritized.  Netmask ordering in Windows 2000+ utilizes a matching Class C address as a local IP.  If you have Windows 2000 and Windows 2003 DNS servers in your environment, your results to clients may be inconsistent.

So let’s say your Network ID for US-Chicago is and your client obtains the SCP record, finds out the FQDN is, when that client tries to communicate with that FQDN, hits the DNS Server, the DNS server will utilize Netmask ordering and find all the records which return network.  If more than one DNS record for are returned for the Network ID, the records will load balanced through round robin if a Windows 2003 DNS server responds.

By default Outlook 2007 queries AD to locate the Autodiscover SCP’s and chooses one at random. But if you chose a common FQDN, it wouldn’t matter that it’s random because the FQDN would be the same and the same CAS would be hammered.  This is why we are using round robin for each country.   We now want to set our Site Scope for each Country.  We will do this for the United States.

Let’s say we have 1 CAS in each United States Site:

  • US-California-CAS
  • US-Chicago-CAS
  • US-Florida-CAS

We would run three commands:

Set-ClientAccessServer -Identity “US-California-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope “US-California”,”US-Chicago”,”US-Florida”

Set-ClientAccessServer -Identity “US-Chicago-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope “US-California”,”US-Chicago”,”US-Florida”

Set-ClientAccessServer -Identity “US-Florida-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope “US-California”,”US-Chicago”,”US-Florida”

Do you see what we did here?  We set every CAS in the United States to use the same FQDN.  We then said, for every client that belongs to either the US-California, US-Chicago, or US-Florida Site, they should use any one of these three SCPs instead of choosing an SCP at random.  But because we created 3 host records for affinityUS, these requests are still load balanced between all your Client Access Servers.  You now are forcing your US clients to use US Servers for Autodiscover Services and load balancing that traffic through round robin DNS at the same time.

You can use the same steps above for your Germany Sites and China sites.  All you have to do is substitute the site names, the FQDN, and the name of the Client Access Servers.

Let’s say we have 1 CAS in each Germany Site:

  • DE-Hamburg-CAS
  • DE-Frankfurt-CAS
  • DE-Leipzig-CAS

We would run three commands:

Set-ClientAccessServer -Identity “DE-Hamburg-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope DE-Hamburg“,”DE-Frankfurt“,”DE-Leipzig

Set-ClientAccessServer -Identity “DE-Frankfurt-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope DE-Hamburg“,”DE-Frankfurt“,”DE-Leipzig

Set-ClientAccessServer -Identity “DE-Leipzig-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope “DE-Hamburg“,”DE-Frankfurt“,”DE-Leipzig

Let’s say we have 1 CAS in each China Site:

  • CN-Shanghai-CAS
  • CN-HongKong-CAS
  • CN-Chengdu-CAS

We would run three commands:

Set-ClientAccessServer -Identity “CN-Shanghai-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope “CN-Shanghai“,”CN-HongKong“,”CN-Chengdu

Set-ClientAccessServer -Identity “CN-HongKong-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope “CN-Shanghai“,”CN-HongKong“,”CN-Chengdu

Set-ClientAccessServer -Identity “CN-Chengdu-CAS” -AutodiscoverServiceInternalURI “” -AutodiscoverSiteScope “CN-Shanghai“,”CN-HongKong“,”CN-Chengdu

Method 2

Method 2 is short and simple but wanted to add it last so you understand the concept of Autodiscover Site Affinity from reading about Method 1.

All your sites can utilize the FQDN that exists on their self-signed certificate.  This self-signed certificate contains the NetBIOS name and the FQDN of the server.  So instead of using a common name such as, you very well could just utilize the existing self-sigend certificate and use the FQDN of the server.  Or you can make sure that the PKI certificates you deploy contain the FQDN of the server and utilize the FQDN for the AutodiscoverInternalURI and set the SiteScope. This is the simplest way and most likely the most common way.


17 Responses to “Configuring Exchange 2007 Autodiscover Site Affinity”

  1. on 25 Aug 2008 at 9:24 amkingofbytes

    Hi Elan!

    Would not the Germany and China sites have to have different Internal URI’s? The first two Germany powershell commands and the first two China powershell commands list “affinityUS”……the third command in each site respectively appears to be right.

    Unless I am missing something?

    Take Care>>>Dustin

  2. on 25 Aug 2008 at 9:51 amElan Shudnow

    Fixed! Thanks for letting me know.

  3. on 31 Aug 2008 at 6:46 amsubject: exchange

    Weekend reading…

    Five Microsoft Exchange Server backup worst practices Third-party Exchange Server 2007 backup and restore…

  4. on 02 Nov 2009 at 9:05 pmDavid Levine

    I had a question, that I just can't seem to locate anywhere on the internet… What exactly is "site name" and what should site name be set as? Site Name makes me think it should somehow relate to AD site but everywhere I look it appears to be netbios name of the actually CAS server? So what is it?

  5. on 25 Nov 2009 at 11:05 amDAK

    "site name" is simply an Active Directory Site name

  6. on 22 Jul 2010 at 1:10 amRjoy

    the command should be "AutodiscoverSiteScope" not "AutodiscoverServiceSiteScope"

  7. on 30 Jul 2010 at 12:36 ameshudnow

    Fixed. Thank you.

  8. on 28 Sep 2011 at 7:18 amSteve

    I have client machines in a resource forest and the exchange servers in the account domains. Which AD site name is used? Do I use the one in the resource or account forest?

  9. on 28 Sep 2011 at 9:27 pmElan Shudnow

  10. on 15 Oct 2011 at 7:03 amDevang Patel


    As you have mentioned that nine records to be created in DNS. i dont understand which records and at which site dns server it should be entered.


  11. on 17 Oct 2011 at 5:53 amElan Shudnow

    Well the -AutodiscoverSiteScope is where you put any site where there are clients. You're telling these sites to hand out the URL specified in AutodiscoverServiceInternalURI. So you need to make sure the sites in -AutodiscoversiteScope can resolve the AutodiscoverServiceInternalURI. That's minimal. I would recommend making sure each site can resolve each other's AutodiscoverServiceInternalURI in case some of your CAS Servers go down you can still fail over to the URI's in another location.

  12. on 15 Dec 2011 at 7:09 amScott

    HI –

    I have a scenario where I have 2 CAS servers in Site A with users on and users from a trusted AD forest using linked mailboxes in Site B with Internally, I exported my SCP info and imported into their AD and all is well. When users from DomainB test autodiscover from home, they experience issues with the cert I have in place for Domain A, the FQDN doesnt match their domain. (I do not have it on the cert)

    Is it as easy as adding to my SAN cert I have in place? Effectively, domainA receives all mail for DomainA and DomainB but obviously with different SMTP domains.



  13. on 15 Dec 2011 at 10:47 amElan Shudnow

    You shouldn't need to put it on Domain A's certificate. The reason why is that the DomainB user is obtaining the SCP from AD which should point to the Autodiscover Service in DomainB. So when the client makes an HTTPS connection, it should be to the Autodiscover service in DomainB. There's probably something else going on.

  14. on 15 Dec 2011 at 11:26 amScott

    I dont have the error in front of me, but it states that the name doesnt match the name on the certificate….I am assuming its something with Autodiscover?

    The only Autodiscover info on Domain B is the detail I imported. They dont have any mail servers and its an older domain (2003 .vs 2008 in Domian A).

    When I am logged into the domain B mailbox, I test auto configuration and I am prompted for credentials. (even after just using OA to log into the mailbox).

  15. on 15 Dec 2011 at 11:35 amElan Shudnow

    Ah so domainB has the mail servers. Make sure the is on the certfificate as well as any EWS/OWA/OAB/etc. names for both InternalURLs and ExternalURLs.

  16. on 15 Dec 2011 at 11:54 amScott

    Sorry, no… Domaiin A has servers and certs…. domain B has just linked mailbox users from a different @smtpdomain.

    I dont have any internal URL's on the cert…. I have a load balanced array with the public name on the cert.

  17. on 16 Dec 2011 at 1:54 pmElan Shudnow

    Well on the DomainA Exchange certs, make sure the names are on the cert as well as any of the InternalURL,ExternalURL, and the FQDN that is assigned to the AutodiscoverserviceInternalURI parameters on *-ClientAccessServer.

Trackback this post | Feed on Comments to this post

Leave a Reply