And I will stick to my site

Some time ago on Polish Windows Server users forum about client site location mechanics in context of Exchange Server and how it deals with site location. As it turned out problem which was discussed was result of some specific 9bad) design but I will cover this further in more details. But thread itself was push for myself to dig a bit about how client locates and chooses site in some scenarios. This post is result of short research on this topl


(cc) prefers salt marsh's

Location of site …

During its startup and logon process one of first things which workstation gets to know if its site. This is result of a process of DC location which was described in details in excellent series of articles by Jorge (parts 1, 2 i 3).

During this process workstation gets information about site it belongs to and caches it in local registry under DynamicSiteName registry key.  As an option system administrator might choose to asign workstation to given site through setting static site mapping in  SiteName registry key. And this is how it starts …

When it comes to domain controller location process it is probably done after steps described by Jorge and workstation will use located DC until it will fail unless it is Vista or higher client or update descried in KB 939252 was deployed.

But when it comes to site discovery things looks a bit differently. Local Netlogon service is querying for site location at equal interval of time where interval is specified in  SiteNameTimeout (5 minutes by default) registry key. Result of this query is stored in DynamicSiteName registry key which was mentioned above. But question comes to my mind … if site to which client is assigned will change will it trigger new DC discovery. Sounds like it should be … and in fact this is the case.

According to DsrGetSiteName function description in case when site timeout interval will pass workstation has to perform site re-discovery process and if this will result in new site assignment it should force DC re-discovery to find optimal DC for new site.

If the timer is expired, the server MUST locate a domain controller in the domain.

So if workstation will be assigned to new site (for example directory configuration will change and subnet was assigned to a new site) it should also try to find new DC which is optimal for given site.


DC location ….

So this is theory. How it looks like in pratice (OK, virtual lab 🙂 ). Lets test it in simple configuration with two sites:

  • Default-First-Site (IP subnet:, DC –> LHFDC01
  • DMZ (IP subnet:, DC –> LHFDC02

Initially our test workstation is assigned with IP so it belongs to DMZ site. Now lets make small change to our directory configuration and change IP subnet assignment which will assign subnet to Default-First-Site site. After directory data replication (I’ve enabled notification of changes between sites to speed it up):

So … site information has been update but workstation is still using DC assigned to old site which is reflected in NLTEST results. But after a while we will see that workstation started also to use DC assigned to its new site:

Our lab configuration has confirmed what was expected after reading documentation (which is OK and in most cases is expected 🙂 ).


Getting back to original Exchange problem …

Lets step back and think for a moment about original problem which started a thread. It was related to problem with Exchange 2007 server which was flapping sites every few minutes. Its event log was full with events about problems with site location and this server was constantly changing DCs to which it was chatting.

This behavior was result of particular sites and subnet configuration in which overlapping subnets were assigned to different sites. This solution was applied as a remedy to problem where client was not able to find site with its subnet assigned to it so somebody has decided to assign one HUGE subnet to central hub site. As a result Exchange server was returned with different site information every several times it was querying for it.

As I think this was bad design and it wasn’t even resolution to a problem this particular design is not supported with Exchange :

The only impact according to it would be "A site can be associated with one or more
IP subnets. Make sure that no overlapping subnets are configured.
If subnets overlap, an Exchange 2007 server will be unable to correctly determine
its site membership and routing errors may occur.

As I think this design was not a remedy as this problem can be solved with proper DNS records registration …

… but this is a topic for different post :).