Domain Locator Across a Forest Trust

I co-authored this post with good friend and colleague, Rob Greene .

We’re asked, many times, why a user does not authenticate against a local domain controller in the same site when logging on across a forest. We’ve setup the most common scenario to help explain how domain locator works for user logons across a forest.


Let’s explain the typical scenario in which we see this problem: The scenario starts with two separate Active Directory forests: and Each forest has a forest (i.e. kerberos) trust to the other. The forest has one Active Directory site name CHARLOTTE. The forest contains two sites: REDMOND and CONTOSO. Administrators in the forest created the CONTOSO site and subnet to support logons for users from terminal servers in the forest.00-dclocator


Users from logon to a terminal server existing in the forest. However, Users experience a slower-than-usual logon, and the LOGONSERVER environment variable shows the name of a remote domain controller in the REDMOND site rather than the domain controller from the CONTOSO site.

However, administrators from the domain expect users from their domain (logging on terminal servers) to authenticate using the domain controller located in the CONTOSO site. The CONTOSO site is the same physical locations as the terminal server. Authentication should occur in the local site and should be fast, right?

DC Locator

It is important to know how a Windows computer selects a domain controller. The computer, during startup, determines the Active Directory site in which it belongs. Windows accomplishes this by examining the subnet of its current network configuration. Then, the computer queries a domain controller that hosts the computer object(using the Windows API DsGetSiteName). The domain controller answers this query with the name of the site associated with the computer’s currently configured subnet. This is all done by the NetLogon service, which runs the DC Locator code at boot and periodically rechecks the domain controllers’ location.

The computer determines the site name using a domain of which the computer is a member—not the user’s domain. This determination occurs during computer startup—not during user logon. Microsoft Support article 939252 (;EN-US;939252) describes how you can change this behavior

Windows writes the site name to the registry during each computer startup. You can view the registry to determine the site to which the computer believes it belongs. You should NOT modify this registry value. The path to this registry value is:

Domain Controller discovery during user logon

Windows will attempt to use the closest domain controller (on the same subnet) to the local computer for authentication. Windows finds the closest domain controller by using DNS and SRV resource records.

Here’s how it works: Windows first performs a DNS query to find a _ldap SRV record for the computer’s current site, but using the domain name selected from the CTRL+ALT+DEL sequence – the domain name of the user. An example looks like: type SRV, class IN

The DNS server responds indicating a record by that name is not found. Windows then attempts to find any domain controller within the user’s domain. Windows accomplishes this by removing the site name from the DNS query. The example similar to the one above: type SRV, class IN

The DNS server’s response to the above request includes a resource record for every domain controller in the user’s domain. Since the client receives the list of domain controllers in no particular order this result is usually the cause as to why the domain controller locator does not use the closest domain controller for authentication.

The Netlogon service of a domain controller is responsible for dynamically registers the _ldap service resource records with its configured DNS server. This registration includes the site specific and domain specific _ldap records.

Our scenario involves a terminal server, which allows multiple users sessions. This is a great way to take network captures of user logon related issues by sing one of the logon sessions to take the network capture. It is always best to clear the DNS and NetBIOS name caches before starting a network capture. This ensures the network capture includes name resolution. You can clear these caches by using IPConfig /FlushDNS and NbtStat –R from a command window (under an elevated command prompt for Server 2008 and Vista).

Here is a snippet of the output of the network capture.01-dclocatorThe results of the network capture show the domain controller locator attempts to locate a domain controller in the site with the same name as the site of the computer; but in the user’s domain (frame 3). The DNS server responds with no such name. This is correct. The forest has only two sites: REDMOND and CONTOSO. Frame 4 queries for an SRV record a second time; however, this time the query does not include the site name of the computer (_ The DNS response provides a positive answer to the second query. The answer includes a _ldap record for each domain controller in the domain (the user’s domain).

We’ve covered the background information and the problem. Now, let’s talk about how to fix it. We can accomplish this by using Active Directory Sites and Services to rename the CONTOSO site in the domain to CHARLOTTE (the name of the site hosting the computer in the domain). Active Directory site configuration is stored in the configuration partition of Active Directory. Renaming the site creates a change and you’ll want ensure this replication converges– especially to the domain controller that is now located in the CHARLOTTE site of the domain. After Active Directory replication completes, then restart the Netlogon service on the domain controller in CHARLOTTE site (in the domain). This registers the service resource records in DNS for the domain controller, including the new site in which it belongs.02-dclocatorLet’s take another network trace of a domain user logon from the terminal server in the domain.03-dclocatorThe same DNS query from figure 1 appears in figure 2. Frame 3 shows the domain controller locator attempting to find a domain controller service resource record in the CHARLOTTE site of the user’s domain, However, the difference between figure 1 and figure 2 is the DNS response. Figure 1 returned a negative DNS response because a resource record for the domain controller did not exist in the CHARLOTTE site in the domain. But, figure 2 shows a positive DNS response (frame 5) for a service resource record for a domain controller in the CHARLOTTE site of the domain.


After renaming the sites so that they match in both forests, the terminal server in the domain successfully located a domain controller covering the CHARLOTTE site for domain. Ideally, in this scenario you would also want the domain controller covering for the CHARLOTTE site to be on the same subnet as the terminal server. This helps expedite logon requests originating from the terminal servers. Regardless, the configuration provides a way to distinguish a specific domain controller for use with logons that span across forests.

– Rob Greene and Mike Stephens

Bulk exporting and importing WMI filters for Group Policy

Here is an updated version of the blog post which was originally published on the Group Policy blog. Check it out!

Did you know you can import/export WMI filters using GPMC? However, your export is limited to one filter at a time – filter to a single .mof file. You then take the exported .mof file to a different domain and use GPMC to import each file. This is great when you only have one or two WMI filters. What about if you have 15 or 20? No worries! You can do this using the LDIFDE utility. (This is a long but detailed explanation).

First, you need to find the WMI Filter you want to export (and eventually import). GPMC writes WMI filters in the Domain partition at:


The LDAP filter you use to return all WMI filters is (objectclass=msWMI-Som). You can narrow the number of returned items if you know the name of the WMI Filter by using
(&(objectclass=msWMI-Som)(msWMI-Name=filtername)). You can lean more about LDAP search filter syntax from MSDN ( The following sample command line gives you and idea of how to export the WMI Filter:

LDIFDE -f output.txt –d “” –r ”( objectclass=msWMI-Som)” –p subtree

In the example above, -f designates the name of the output file that stores the exported WIM filter objects. Next, -d designates the based distinguished name; that is, where the search for objects starts. In this example, it starts at the beginning of the domain. The –r is an inclusive LDAP search filter. In this example we only want objects of the class
msWMI-Som returned by the query. Lastly, the –p designates that type of search we want to use. A subtree search means the search begins at the designated base distinguished name and searches the entire depth of the tree for objects matching the designated filter—similar to using dir /s on a directory when searching for a file.

Your options may vary. If you have problems exporting the items then add –j (one dash, the letter J, a space, and one period) to the command line to create a log file in the current folder. A successful output.txt file looks similar to the following:

dn: CN={1154EFFC-0090-4F23-8865-C8D555BF696E},CN=SOM,CN=WMIPolicy,CN=System,DC=contoso,DC=com
changetype: add
objectClass: top
objectClass: msWMI-Som
cn: {1154EFFC-0090-4F23-8865-C8D555BF696E}
instanceType: 4
whenCreated: 20070808151246.0Z
whenChanged: 20070808151246.0Z
uSNCreated: 40979
uSNChanged: 40979
showInAdvancedViewOnly: TRUE
name: {1154EFFC-0090-4F23-8865-C8D555BF696E}
objectGUID:: EPDEbOIaGEWyX3Z/b+eiKw==
objectCategory: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=contoso,DC=com
msWMI-Author: Administrator@CONTOSO.COM
msWMI-ChangeDate: 20070618142622.740000-000
msWMI-CreationDate: 20070618142257.735000-000
msWMI-ID: {1154EFFC-0090-4F23-8865-C8D555BF696E}
msWMI-Name: Imported WMIFilter2
msWMI-Parm1: This is the description for the filter
1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

Once you successfully export the WMI Filters; you then need to prepare the output file for import.

Prepare the output file for importing:

  1. First, save the file as another file name.
  2. Then, you need to download the GUIDGEN utility (this is not so important when importing the WMI filter into a different domain). As a reference, this is a guid: {DF380E6C-DB23-44ed-9BF6-435559503347}.
    • You MUST change the guids to import into the same domain or it will NOT import.
  1. Change the guid (to include open and closing curly braces) in the DNCNdistinguishednamename, and msWMI-ID attributes (use the same guid in each of these attributes).
  2. If importing into a different domain, change the LDAP path to reflect the new domain in the dndistinguishedName, and objectCategory attributes. Only change the domain portion of the LDAP path.
  3. Next, you need to remark out the whenCreatedwhenChangedUSNcreatedUSNChangedobjectguidmsWMI-ChangeDate,  and msWMI-CreationDate attributes. Do this by inserting the # character and a space at the beginning of the line for each of the listed attributes.
  4. Optionally, you can change the text displayed in msWMI-NamemsWMI-Author, and msWMI-Parm1 attributes.
    • msWMI-Name is the display name of the WMI Filter shown in GPMC.
    • msWMI-Author is the UPN format for the person creating the WMI filter.
    • msWMI-Parm1 is the description text shown for the WMI filter in GPMC.

The final file should look similar to the following.

dn: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
changetype: add
objectClass: top
objectClass: msWMI-Som
cn: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
instanceType: 4

whenCreated: 20070618142257.0Z

whenChanged: 20070618142622.0Z

uSNCreated: 26483

uSNChanged: 26485

showInAdvancedViewOnly: TRUE
name: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}

objectGUID:: 7sA6lK0PVE2fGNOSDTS5Kw==

objectCategory: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=fabrikam,DC=com
msWMI-Author: Administrator@fabrikam.COM

msWMI-ChangeDate: 20070618142622.740000-000

msWMI-CreationDate: 20070618142257.735000-000

msWMI-ID: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
msWMI-Name: Imported WMIFilter2
msWMI-Parm1: This is the description for the filter
1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

You’re almost ready to import the WMI filters. However, importing or adding a WMI Filter object into AD is a system only operation. You need to enable system only changes on a domain controller for a successful LDIFDE import. To do this, on the domain controller you are using for importing, open the registry editor and create the following registry value.

Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: Allow System Only Change
Value Type: REG_DWORD
Value Data: 1 (Binary)

Next, you’ll need to reboot the domain controller to activate the new setting. Once the domain controller is rebooted, you can use LDIFDE to import the file into AD. Use the following command:

LDIFDE  -i –f input.txt

If you have problems then add –j . (one dash, the letter J, a space, and one period) to the command line to create a log file in the local folder. Once the import is complete you should delete the System Only Registry key and reboot the domain controller to deactivate the setting. A successful import looks similar to the following.

Connecting to “”
Logging in as current user using SSPI
Importing directory from file “import-wmi.ldf”

Loading entries
1: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
Entry DN: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
changetype: add
Attribute 0) objectClass:top msWMI-Som
Attribute 1) cn:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 2) distinguishedName:CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
Attribute 3) instanceType:4
Attribute 4) showInAdvancedViewOnly:TRUE
Attribute 5) name:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 6) objectCategory:CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=fabrikam,DC=com
Attribute 7) msWMI-Author:Administrator@FABRIKAM.COM
Attribute 8) msWMI-ID:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 9) msWMI-Name:Imported WMIFilter2
Attribute 10) msWMI-Parm1:This is the description for the filter
Attribute 11) msWMI-Parm2:1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

Entry modified successfully.

1 entry modified successfully.

The command has completed successfully

And there you go: you’ve successfully exported and imported WMI filters.

-Mike Stephens