Understand and Troubleshoot Dynamic Access Control in Windows Server 2012

I finished the update to the very popular guide to Dynamic Access Control. Everything you wanted to know about Dynamic Access Control, but cannot find anywhere else.

  • Technical concepts to help you successfully install, configure, and manage this feature.
  • Technical concepts to help you successfully install, configure, and manage this feature.
  • Relevant architecture of this feature, with dependencies, and technical implementation.
  • Primary troubleshooting tools and methods for this feature.

You can download it directly from Microsoft here or, you can slurp it from the blog directly (in case Microsoft moves or deletes items from their download center).


— Mike Stephens

Cluster and Stale Computer Accounts

Today, I want to write about a common administrative task that can lead to disaster: removing stale computer accounts from Active Directory.

Removing stale computer accounts is simply good hygiene– it’s the brushing and flossing of Active Directory. Like tartar, computer accounts have the tendency to build up until they become a problem (difficult to identify and remove, and can lead to lengthy backup times).

Oops… my bad

Many environments separate administrative roles. The Active Directory administrator is not the Cluster Administrator. Each role holder performs their duties in a somewhat isolated manner– the Cluster admins do their thing and the AD admins do theirs. The AD admin cares about removing stale computer accounts. The cluster admin does not… until the AD admin accidentally deletes a computer account associated with a functioning Failover Cluster because it looks like a stale account.

Unexpected deletion of Cluster Name Object (CNO) or Virtual computer Object (VCO) is one of the top issues worked by our engineers that support Clustering and High-Availability. Everyone does their job and boom– Clustered Servers stop working because CNOs or the VCOs are missing. What to do?

What’s wrong here

I’ll paraphrase an article posted on the Clustering and High-Availability TechNet blog that solves this scenario. Typically, domain admins key on two different attributes to determine if a computer account is stale: pwdlastSet and LastLogonTimeStamp. Domains that are not configured to a Window Server 2003 Domain Functional Level use the pwdLastAttribute. However, domains configured to a Windows Server 2003 Domain Functional Level or later should use the lastLogonTimeStamp attribute. What you may not know is that a Failover Cluster (CNO and VCO) does not update the lastLogonTimeStamp the same way as a real computer.

Cluster updates the lastLogonTimeStamp when it brings a clustered network name resource online. Once online, it caches the authentication token. Therefore, a clustered network named resource working in production for months will never update the lastLogonTimeStamp. This appears as a stale computer account to the AD administrator. Being a good citizen, the AD administrator deletes the stale computer account that has not logged on in months. Oops.

The Solution

There are few things that you can do to avoid this situation.

  • Use the servicePrincipalName attribute in addition to the lastLogonTimeStamp attribute when determining stale computer accounts. If any variation of MSClusterVirtualServer appears in this attribute, then leave the computer account alone and consult with the cluster administrator.
  • Encourage the Cluster administrator to use -CleanupAD to delete the computer accounts they are not using after they destroy a cluster.
  • If you are using Windows Server 2008 R2, then consider implementing the Active Directory Recycle Bin. The concept is identical to the recycle bin for the file system, but for AD objects. The following ASKDS blogs can help you evaluate if AD Recycle Bin is a good option for your environment.

— Mike Stephens

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: contoso.com and litware.com. Each forest has a forest (i.e. kerberos) trust to the other. The contoso.com forest has one Active Directory site name CHARLOTTE. The litware.com forest contains two sites: REDMOND and CONTOSO. Administrators in the litware.com forest created the CONTOSO site and subnet to support logons for litware.com users from terminal servers in the contoso.com forest.00-dclocator


Users from litware.com logon to a terminal server existing in the contoso.com 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 litware.com domain expect users from their domain (logging on contoso.com 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 (http://support.microsoft.com/default.aspx?scid=kb;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:

_ldap._tcp.._sites.dc._msdcs..com: 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:

_ldap._tcp.dc._msdcs..com: 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 Litware.com 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 (_ ldap._tcp.dc.msdcs.litware.com). The DNS response provides a positive answer to the second query. The answer includes a _ldap record for each domain controller in the litware.com 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 litware.com domain to CHARLOTTE (the name of the site hosting the computer in the contoso.com 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 litware.com domain controller that is now located in the CHARLOTTE site of the litware.com domain. After Active Directory replication completes, then restart the Netlogon service on the litware.com domain controller in CHARLOTTE site (in the litware.com 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 litware.com domain user logon from the terminal server in the contoso.com 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, litware.com. 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 litware.com 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 litware.com domain.


After renaming the sites so that they match in both forests, the terminal server in the contoso.com domain successfully located a domain controller covering the CHARLOTTE site for litware.com domain. Ideally, in this scenario you would also want the litware.com domain controller covering for the contoso.com CHARLOTTE site to be on the same subnet as the contoso.com terminal server. This helps expedite litware.com 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 (http://msdn2.microsoft.com/en-us/library/aa746475.aspx). The following sample command line gives you and idea of how to export the WMI Filter:

LDIFDE -f output.txt –d “dc=contoso.com” –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 “hq-con-dc-01.fabrikam.com”
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