Use Group Policy to Configure Windows Firewall to allow WMI

Using Group Policy to enable WMI (Windows Management Instrumentation) remote requests through the Windows Firewall

It is always a good idea to enable the Windows firewall under the domain profile. Enabling the firewall can prevent needed functionality as well.  For example, in some scenarios it may be required to be able to interact with client workstations or servers via WMI (which would be a type of unsolicited DCOM request on port 135).  Windows firewall will block this functionality unless you explicitly allow it.  To allow WMI remote requests through the windows firewall using Group Policy,  the “Allow Remote Administration Exception” policy needs to be enabled in the group policy object being applied to the workstations and / or servers requiring this access in the environment.  In order to set this, open up Group Policy Manager, and browse to the following location: Computer Configuration\Administrative Template\Network\Network Connections\Windows Firewall\Domain Profile(if setting this for the domain profile).  The same policy can be found in the “Standard Profile” as well.

Once you enable “Allow Remote Administration Exception” (and the computer objects refresh their policies usually 4 hours), WMI traffic should be allowed.

If you are impatient like me, sometimes it is best to just issue a command from the commmand line and be done.  The following are examples of commands that can be used to enable the same functionality as above.

Allow WMI through the Windows Firewall from the command line


If a connect attempt using wbemtest.exe fails – follow these steps to allow the requests through the firewall.

From the local machine command line, if the platform is Windows XP / Server 2003 (Below are three commands each providing different options)

 c:\> netsh firewall set service remoteadmin enable
 c:\> netsh firewall set service remoteadmin enable subnet
 c:\> netsh firewall set service remoteadmin enable custom,LocalSubnet

Windows7 / Server 2008 (Two commands below provide 2 ways to set the firewall to allow WMI)

 c:\> netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

You should see something like the following if successful.

Updated X rule(s) (where X is the number of rules updated)

  c:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes

Again, you will see something like the following if successful.

Updated X rule(s).

This should be all that is required to allow WMI remote requests through the Windows Firewall.  The name of the Group Policy Object setting prevented me from getting this to work for quite a while.

Group Policy Filtering using WMI


The purpose of WMI filtering is to allow more control over the Active Directory objects that Group Policy is applied.  WMI filtering can be very powerful when used correctly, and can prevent the complex tree of Organization Units created to try and separate the Active Directory objects correctly.  Microsoft recommended best practice is to leverage filtering and item level targeting (for preferences) to avoid large and complex Active Directory structure.  While OUs can be used to filter, it is also a manual process and requires the interaction of an administrator.  With WMI filtering, if a workstation is upgraded to another operating system, WMI will automatically acknowledge that change, where in the OU structure, the account would have to be moved to a new OU manually.  So WMI filtering can reduce management overhead and prevent errors in policy application.

A couple of things to note when designing Group Policy using WMI filters:

  • The WMI query syntax is similar to an SQL query
  • Complex syntax can be written, but the more complex it becomes the more difficult it will be to manage
  • The more filters are used and the more complex the queries, the greater the length of the logon time
  • Per Microsoft recommended best practice, if a user / computer configuration if it is not being used, it should be disabled.  Every configuration that is processed will add time to the logon process even if it is not being used


By default no WMI filters exist in Active Directory.  The WMI filter container can be found in the Group Policy Management MMC under the Group Policy Objects container.

To create a new filter, right click the WMI Filters container and select “new” from the list.

This will open the WMI filter dialog window.  (shown below)

Type a name and description, and then click the “Add” button to add the query to run (to determine OS version in this case)

This will open a new dialog window and it will prompt for the namespace (which should already be populated and unless you are doing something really strange should not be changed).  It should be defaulted to root\CIMv2.  It will also have a big box to type the query you want to run in.  This is where you put the following:

select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"

When you click “OK” on the WMI dialog window you will see the following:

Additional queries can be run (like checking for the presence of a battery, or this query can be modified to include the check for the existence of a battery.  Remember the notes from above, more complexity will lead to more difficulty managing them and it will increase logon times.  Click the “Save” button to save your new filter.

If everything worked out, you will now see something similar to the following:

Where a new filter will be listed under the WMI Filters container.  The last step before testing is associating the filter with the GPO.  To do this, click on the GPO you want to filter, and under the scope tab look for the WMI Filtering section toward the bottom of the window.  Select your newly created filter and you will now be filtering based on OS and only Windows 7 workstations will be affected by this policy. (for this example).


There really isn’t too much that can go wrong with these.  A couple of things that should be verified are the following:

  • Make sure the scope is set accurately, if the computer is a part of a security group, make sure that security group has read and apply rights to the Group Policy Object
  • Make sure that the group policy is applied to the correct OU and that it is enabled
  • Make sure no inheritance blocking is set, or an enforcement rule applied to another GPO that will prevent the settings of this GPO from applying correctly
  • Run the following command from a command prompt to verify that the GPO is applied as expected
gpresult /r

This is a quick way to set Group Policy using a variety of conditions providing the ability to maintain a more “flat” Active Directory structure so less manual processes need to be completed reducing time requirements and avoiding errors.

Power Broker Open(Likewise Open) and Samba


Power Broker Open, what used to be named Likewise Open is a fantastic (mostly) worry free utility for joining Linux systems to a Windows Active Directory domain.  The amount of configuration is minimal and scripts have been created to manage these configurations.  For a cost you can even get additional modules and functionality to allow management of the Linux platform.  One of the more frustrating parts of this software is the lack of documentation, or maybe I should say proper documentation.  The goal of this article is to provide proper documentation on integrating Samba authentication against Active Directory using Power Broker Open.


I have recently discovered how to enable samba integration with this authentication.  It is not enabled by default and it is not the typical method of using winbind.  It may also be tempted to run the following:

net -U <username> ads join

but this just breaks the Power Broker Open functionality.  Success may be achieved with the Samba functionality, but it will be using a different mechanism for authentication now and all the authentication that was provided with Power Broker Open will cease to function.  A utility is included at least from the versions available from 12.04 and up, that adds the required functionality.


If Power Broker Open is installed on the system, all the required executables will be located in the /opt/pbis location in the bin directory.  The code that sets up the Samba integration is the following, and once you run it, that should be all that is required.  You will see a couple of lines, one that will be verifying the Samba version currently installed on the system, and the other one verifying the success / failure of the integration setup.

samba-interop-install --install

It is important to note that this utility must be run as root.  So either sudo or running as the root account will be required.  The error that is displayed when not running with root permissions does not make this obvious.  Once the Samba version is verified and compatabile and the integration was verified successful, from another domain joined workstation, entering the address of the server should provide the shares available.  If you need to setup shares, this can be done in the /etc/samba/smb.conf file.  The file is filled with documentation on how to do this, but all that is needed is to setup the shares in “shares” section of this file.  The official Samba website has really good documentation on setting up shares and the various options.  It can be found here:


Only a couple of things will prevent this from being successfully configured.

  1. Proper elevated credentials were not used when running the executable
  2. An incompatable version of Samba is installed on the system
  3. Power Broker Open has not been properly configured

Fix Active Directory Authentication / Login Ubuntu 13.10 and PowerBroker (Likewise-open)


When attempting to authenticate and logon to a GUI on the Ubuntu 13.10 platform, it appears as if authentication is successful, and the desktop may even appear briefly, but then immediately returns to the logon screen.  Verification of the setup and configuration of PowerBroker shows no issues.  Also, a standard console logon works successfully.  Only seems to affects Active Directory users, local users can still logon successfully and are presented a desktop.

Background / Cause

This bug:

explains what is causing the behavior, at least from a high level.  The details remain unknown.

The same problem seems to manifest itself in Ubuntu 13.10 where after logging in, the $PATH variable is incorrect.



Per the bug listing above, updating /etc/pam.d/common-session by commenting out the following line by adding a (#) in front of it, and adding the line below:

session sufficient

and add:


Successful authentication and access to the desktop as an Active Directory user with PBIS 7.5.2 is now possible.



Clean Up Active Directory Domain Controller Manually (when dcpromo fails or isn’t an option)


There are times a domain controller cannot be removed per Microsoft recommended best practices using dcpromo.  When this occurs the following guide has been the definitive method to properly and cleanly remove a domain controller from active directory.

Background / Cause

There are a number of reasons that a domain controller needs to be manually removed from Active Directory.  For example, if there is an unrecoverable hardware failure, a corrupted virtual machine, or someone just performed the wrong steps, leaving information in Active Directory and DNS.  a failed dcpromo either removing a domain controller or adding a domain controller is also another reason for manual domain controller object clean up.


In the event that the NTDS Settings object is not removed correctly or fails using dcpromo,  you can use the Ntdsutil.exe utility to manually remove the NTDS Settings object.

If a new domain controller with the same name as the failed domain controller is built to be placed back in production, then only need perform only the first procedure to clean up metadata, which removes the NTDS Settings object of the failed domain controller. If the goal is complete removal of the domain controller all the procedures / steps need to be completed: clean up the Domain Controller metadata, remove the failed server object from Active Directory Sites and Services, remove the computer object from the domain controllers container in Active Directory Users and Computers, and clean up DNS.


The following tools will be required to successfully complete all steps: Ntdsutil.exe, Active Directory Sites and Services, and Active Directory Users and Computers.

An account with Enterprise Admins universal group membership is also required.

Caution: Using the Ntdsutil.exe utility incorrectly may result in partial or complete loss of Active Directory functionality.

Step 1: Clean up the Domain Controller metadata

From a command prompt, type Ntdsutil.exe and press ENTER (shown below).


At the Ntdsutil: prompt, type metadata cleanup and press ENTER.

ntdsutil: metadata cleanup
metadata cleanup:

From the metadata cleanup: prompt, type connections and press ENTER.

metadata cleanup: connections
server connections:

From the server connections: prompt, type connect to server <servername>, where <servername> is the domain controller (any functional domain controller in the same domain) from which you plan to clean up the metadata of the failed domain controller. Press ENTER.

server connections: connect to server dc1
Binding to dc1 ...
Connected to dc1 using credentials of locally logged on user.
server connections:

Note: Windows Server 2003 Service Pack 1 eliminates the need for the above step.

Type quit and press ENTER to return you to the metadata cleanup: prompt.

server connections: q
metadata cleanup:

Type select operation target and press ENTER.

metadata cleanup: select operation target
select operation target:

Type list domains and press ENTER. This lists all domains in the forest with a number associated with each.

select operation target: list domains
Found 1 domain(s)
0 - DC=domain,DC=net
select operation target:

Type select domain <number>, where <number> is the number corresponding to the domain in which the failed server was located. Press ENTER.

select operation target: Select domain 0
No current site
Domain - DC=domain,DC=net
No current server
No current Naming Context
select operation target:

Type list sites and press ENTER.

select operation target: list sites
Found 1 site(s)
0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
select operation target:

Type select site <number>, where <number> refers to the number of the site in which the domain controller was a member. Press ENTER.

select operation target: Select site 0
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
Domain - DC=domain,DC=net
No current server
No current Naming Context
select operation target:

Type list servers in site and press ENTER. This will list all servers in that site with a corresponding number.

select operation target: List servers in site
Found 2 server(s)
0 - CN=dc2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
1 - CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
select operation target:

Type select server <number> and press ENTER, where <number> refers to the domain controller to be removed.

select operation target: Select server 1
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
Domain - DC=domain,DC=net
Server - CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
 DSA object - CN=NTDS Settings,CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net
 DNS host name -
 Computer object - CN=dc1,OU=Domain Controllers,DC=domain,DC=net
No current Naming Context
select operation target:

Type quit and press ENTER. The Metadata cleanup menu is displayed.

select operation target: q
metadata cleanup:

Type remove selected server and press ENTER.

A warning message will be displayed.  It can be reviewed, but pressing Yes will remove the metadata of the server.


metadata cleanup: Remove selected server
"CN=dc1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=net" removed from server "dc2"
metadata cleanup:

At this point, Active Directory confirms that the domain controller was removed successfully. Note:  If an error is received stating the object could not be found, Active Directory might have already removed from the domain controller.

Type quit, and press ENTER until back at the command prompt.

Remove the failed server object from the sites and services mmc

In Active Directory Sites and Services, expand the appropriate site.

Delete the server object associated with the failed domain controller.

Remove the failed server object from the domain controllers container

In Active Directory Users and Computers, expand the domain controllers container.

Delete the computer object associated with the failed domain controller.

Windows Server 2003 Active Directory might display a question window, asking you if you want to delete the server object without performing a dcpromo operation (which, of course, you cannot perform, otherwise you wouldn’t be reading this article, would you…) Select “This DC is permanently offline…” and click on the Delete button.

Another confirmation window will be displayed.  If this is, in fact, the domain controller object to be removed, click Yes.

Remove the failed server object from DNS

In the DNS snap-in, expand the zone that is related to the domain from where the server has been removed.

Remove the CNAME record in the _msdcs.root domain of forest zone in DNS. You should also delete the hostname and other DNS records.  A through discovery of all records should be completed to ensure all references to the missing domain controller have been removed.  This means that expanding all areas of the DNS tree and verifying each section only has valid “live” domain controllers is required.

If you have reverse lookup zones, also remove the server from these zones.

Other considerations

Also, consider the following:

  • If the removed domain controller was a global catalog server, evaluate whether application servers that pointed to the offline global catalog server must be pointed to a live global catalog server.
  • If the removed DC was a global catalog server, evaluate whether an additional global catalog must be promoted to the address site, the domain, or the forest global catalog load.
  • If the removed DC was a Flexible Single Master Operation (FSMO) role holder, relocate those roles to a live DC.
  • If the removed DC was a DNS server, update the DNS client configuration on all member workstations, member servers, and other DCs that might have used this DNS server for name resolution. If it is required, modify the DHCP scope to reflect the removal of the DNS server.
  • If the removed DC was a DNS server, update the Forwarder settings and the Delegation settings on any other DNS servers that might have pointed to the removed DC for name resolution.

Known Issues / Troubleshooting

Problem: | The domain controller doesn’t appear to exist when using the ntdsutil.exe utility

Solution: | It is possible that the metadata for the domain controller was, in fact, removed but other areas (Sites and Services, Users and Computers, and / or DNS) may still have information about the server.  Quitting the ntdsutil.exe utility and reviewing the other areas is recommended.  If no further evidence has been found, it is safe to assume the domain controller was successfully removed.

Problem: | Strange error messages showing up on client machines when authenticating to the domain.

Solution: | This is almost always related to incomplete removal of domain controller information in DNS.  Review all levels of DNS to ensure complete removal of all information regarding the missing domain controller.


Petri IT Knowledgebase


Active Directory Group Policy Preferences


Microsoft released a great new set of tools for Active Directory with the release of Windows Server 2008 called Group Policy Preferences.  Group Policy Preferences was introduced in the 2008 release of Microsoft Windows Server.  It was the opinion of most members of the systems administration community that we should have seen these incorporated into Active Directory much sooner.  They provide a simple GUI  interface to manipulate and control almost any aspect of the Microsoft Windows operating system.


The following document will not only outline Group Policy Preferences and the powerful management tools available but also provide Microsoft best practice surrounding them.  Simple examples will be provided but these examples can be combined to really harness the full power of Group Policy Preferences.

Detailed Information


Probably one of the easiest and most useful tasks that Group Policy Preferences accomplishes is mapping network drives.  The best way to accomplish this is to incorporate existing Microsoft best practice (which should already be in place in a standard  environment) and mesh it together with the new Group Policy Preferences component for ease of administration and improved security.

Security Setup

This example will assume that an Accounting department exists and that a share for the Accounting department is required for collaboration.  Per Microsoft recommend best practice, and found to work most efficiently  across all types of environments is creating domain local security groups for access to shared resources and assigning NTFS permissions to these security groups.  Next domain global groups are created and all the users required to access the resources are placed into these global groups.  Finally, the global groups are associated to the local groups connected to the shared resources.  This is actually a Microsoft recommend best practice but very few organization actually implement this strategy and even disagreed with Microsoft wholeheartedly.  However, when leveraging this configuration it becomes very clear why this method is used and recommended by Microsoft.

The following will provide the details of an example of how this methodology works.  The shared resource name will be simply “Accounting“.  It is recommend to name the folder name identical to the shared name for simplicity, but isn’t necessary.  It is also recommend to create a folder administration group for managing file and folder NTFS permissions.  This will provide very granular control over who has access to all file and folder permissions.  Potentially, user accounts would only be placed into this security group as permissions need to be changed or setup.  A domain global security group is created called “user-file and folder admins” group. This is not necessarily an arbitrary name.  Naming and naming conventions are also critically important when working with Active Directory.  Any IT professional that feels differently has most likely had very little experience managing or administering an Active Directory domain. The naming convention used in this example will follow the format [type]-[description]-[optional details] where [type] is the type of objects that are associated with the group, [description] is a short description of the group like Accounting Department, and the [optional details] could be something like read OR write or manage OR standard detailing the access levels.  For the Accounting department, in order to provide some examples of user security groups, we have 3 security groups; user-Accounting Department-general, user-Accounting Department-managers, and user-Accounting Department-controllers.

In a similar fashion the network resource will have various security groups associated with it.  In order to keep this simple, the following will be used; file-Accounting Share-read and file-Accounting Share-write.  We now have all the groups required to setup a solid environment and provide access controls through NTFS permissions.

We will make user-Accounting Department-managers and user-Accounting Department-controllers a part of the file-Accounting Share-write and the user-Accounting Department-general group a part of the file-Accounting Share-read security group.  This will allow managers and controllers to manipulate the data in the share, but the general accounting users will only be allowed to read the data as we may want them to have access to the data, but we don’t want them to manipulate or change it.  Users will then be placed in the appropriate user global security group.

NOTE:  It is really important that users are never placed directly into the file security groups.

Mapping a network drive using Group Policy Preferences

After testing and verifying the access rights based on the new security groups, the next step involves actually setting up the configuration that will map the drives.  First, a Group Policy Object is created which will contain the preferences.  The reoccurring theme is back with naming of Group Policy Objects.  When creating a Group Policy Object, the name will be important and a standard should be followed per Microsoft.  For this example, the following template is used; [object it applies]-[Short description]-[type], where [object it applies] refers to user, computer, or both, [Short description] provides a quick description of the Group Policy Object‘s goals, and [type] would be policy, preference, or both indicating what methods of configuration are used.

Based on this template for Group Policy Objects the following Group Policy Object is created user-Drive Mapping-preferences.  The name quickly identifies that the Group Policy Object will apply to user objects, it is for the purpose of drive mapping, and it uses preferences to accomplish this task.

Once the Group Policy Object has been created, right clicking the object and selecting the “edit” option will open the policy.  Drilling down under the User Configuration section, then Preferences, then Windows Settings, Drive Maps will be listed.  Right clicking this object will provide a menu, select “New -> Mapped Drive“.  A new “Properties” window will be displayed allowing a configuration to be built for the drive mapping.

All preferences use the same 4 options; create, delete, update, and replace.

  • Create will create the “configuration” if it doesn’t exist, but will not check for changes or update if anything is changed.
  • Delete removes the “configuration” and can be used in conjunction with the other actions.
  • Update will update the “configuration” by creating if needed or updating if required.  A quick note, the update action does not remove an item if the object it is being applied to falls out of scope.
  • Replace is similar to update, but it is the only action that can be used with the “remove when no longer applies” option.  If the “replace” action is implemented and the object (user for example) is no longer in the scope of the preference, replace will remove the preference configuration.

For mapped drives, the most common action used is “replace” as it will add and remove mapped drives as needed.  Once the action has been selected, the path to network resource in this case \\fileserver01\Accounting is provided in the “Location” entry box and the “reconnect” check box is selected if this functionality is needed.  Preferences also allows for the network resource to be named.  This is a great idea to prevent end-users from becoming confused or using the drive letter associated with the network resource.  By placing a check in “Label as“, and in the space provided supply a meaningful name for your network resource (to remain consistent and to keep things simple, the actual shared resource name could be used here (Accounting).  Next the drive letter is selected.  Again, another great option with Group Policy Preferences is the ability to select “User first available, starting at:” which will attempt to map the drive to the drive letter indicated first, but if it is in use continues to attempt to map the drive to ascending letters until an open letter is found.  This functionality displays why naming the shared resource is so important.  If the end-user was calling the network resource the “G” drive for example, but today it is the “J” drive, they would be confused and likely contact the help desk believing they lost access to their network drive.  Of course using “Existing” allows a single letter to be chosen for the mapping.  There are several other options on this Properties page, but they will not be covered in detail here.

The next, and arguably the more impressive page / tab is the “Common” tab.  This is the options that will be configured for how the drive mapping will be used.  This tab contains features like “Run in logged-on user’s security context (user policy option)” which allows preferences to run as the user logging on with the user’s defined rights and permissions.  The “Remove this item when it is no longer applied” option (used only when the “Replace” action is selected) removes the configuration if it no longer applies to the object (user or computer).  “Apply once and do not reapply” is used when a configuration is only needed to be applied one time, similar to “run once” in Windows.  The last option is “Item-level targeting” and is what really makes Group Policy Preferences worthwhile.  It allows fine grain control over what configurations apply and how they apply using almost unlimited filtering.

For this example, we will be assuming that the organization has several sites / locations and the accounting department of each of these sites has individual drive mappings.

By leveraging the “Item-level targeting” the drive can be mapped to the users of the account security groups (created above) who have a IP address in the subnet of the specific location, or using the Active Directory Site.

First it should be understood that adding a single targeting item is completely acceptable, but several items can be used with either AND or OR statements and IS or IS NOT statements.  Several items can be combined into a collection and collections can be evaluated the same way individual items are evaluated.

In order to better understand this, using the example above, a mapped drive definition will be setup that will map the network drive to any user who meets the following criteria:

  • is a member of the user-Accounting Department-managers security group
  • is a part of the “Location A” site in Active Directory Sites and Services
  • has been assigned an IP address in the range of –

To make this happen, a collection is created.  In that collection 2 targeting items are created.  The first item defines that the IP address is between and and the other item defines the object must be a part of the Location A site in Active Directory Sites and Services.  Now, using the item options it can be specified that one of these conditions must be true, or both of these conditions must be true by toggling the And and Or options.  Using “And” will define that both items must be true for the drive mapping to occur while using “Or” will allow for either of the conditions to be met.  The same applies when looking at the “Is” and “Is Not” item options.  These options perform just want you would expect.  By using the “Is” option, the conditions must be true, and conversely by using the “Is Not” option, the conditions must be false.


Once the collection is created and configured to provide expected results, the last task is to provide a single item requiring membership in the user-Account Department-managers.

Again, the item options can be used to require is be true and the collection be true or require that one or the other is true.  In the example, the goal is to have everything match, so the “and” modifier will be used for all items and since we want everything true, the “Is” modifier will also be used for each item.

Saving this new configuration and applying it to an OU that contains the users, the following will be the result of all the configurations made in this example from the security group selections to the item level targeting of the drive mapping preference.

  • Managers of the Account department for the Location A site will receive a mapped drive
  • These users will have read and write access to the drive
  • If they move to another location, they will lose the mapped drive until they return to Location A
  • If a manager is moved to a new role within the organization, simply removing them from the user-Accounting Department-managers will remove the drive mapping from their workstation, but also remove access rights to the network location so manually providing the UNC path to the resource will result in an “access denied” message.

The example above provides a simple and hopefully straight forward example of how Group Policy Preferences can be leveraged and how potentially powerful they can be in administration of rights and delegation of resources.

Known Issues / Troubleshooting

Problem: |  The network resource does not get mapped to a drive even though all settings are correct and user is a member of required security groups.

Solution: |  Due to Group Policy Preferences being relatively new, there are several prerequisites required in order for the instructions of the preferences to interact with older windows systems.  The prerequisites will not be covered here, but a quick search should provide several Microsoft documents that define what each version of Windows require in order for successful use of Group Policy Preferences.

Problem: |

Solution: |

References / Additional Resources



Active Directory Health Check Discovery Steps

Goal / Scope

Active Directory or directory services is the backbone of a good network.  It allows for configuration of devices and role management of users as well as a good central location for network information.  Maintaining a high level of health for Active Directory is very valuable. Currently, there are many resources available online, but few seem to organize the information and look holistically at the Active Directory environment.  This reference document should provide a baseline for reviewing a Microsoft Active Directory environment completely and organize it to be effective.  Feedback and comments are welcome.

The scope of this document is to provide a step by step process for performing a Microsoft Active Directory health check in any organization and provide recommendations and next steps to remediate and / or stabilize the environment.  The target Active Directory forest / domain functional levels for this document are 2003 through 2012, but due to the high level overview approach, other functional levels should benefit from this process as well.


After performing  the steps in the process outlined below, issues present in the environment, performance bottlenecks, and overall health concerns should be understood and steps to address them available.

Health Check Tasks

1.0     Discovery

1.1  event logs

Document: event log errors and warnings.

Determine Critical Events: review and document event log errors and warnings that impact Active Directory health as well as overall state.

1.2  Microsoft Best Practices Analyzer(s)

  • The Microsoft Best Practice Analyzer:  running the Best Practice Analyzer for general server health is also recommended to catch any issues potentially related to Active Directory.
  • The Microsoft Active Directory Domain Services and DNS Server Best Practice Analyzer(s):  running the Best Practice Analyzer specifically targeted at Active Directory services and DNS services will provide additional information concerning Microsoft’s recommendations for a healthy and stable Active Directory environment.

The BPA for Active Directory Services is located in Server Manager > Roles > Active Directory Domain Services.  Scroll down to ‘Best Practices Analyzer’ and click ‘Scan This Role’.  The DNS Server BPA is located in Server Manager > Roles > DNS Server.  Scroll down to ‘Best Practices Analyzer’ and click ‘Scan This Role’.

1.3  Obtaining Information

Note: To make life easier and where budget permits, there are software packages out there like Quest’s Spotlight on Active Directory which are well worth the cost given the functionality. The following health check process will only leverage free tools and utilities.

Most of the following information can be collected via scripts, but will be important to the outcome of the health check.

  • Servers: number / type / role(s) / names / IP Addresses
  • Server Specifications: CPU(s) / RAM / virtual / physical hardware architecture / number of NICs / OS version(s) / Service Pack level(s) / manufacture of hardware of physical servers or hosts of virtual servers
  • Location(s) of Servers: DMZ / site(s) / high availability / redundancy (if applicable)
  • Hardware Drivers:  versions, are latest versions of all drivers installed and up to date, and if not provide reasoning the hardware is not using the latest drivers.
  • unrelated products / software:  what other software is installed on the server, running in the background
  • antivirus software:  installed on the Domain controllers and clients
  • Other servers sharing resources:  for virtual servers, what other servers are running on the host sharing resources

In order to obtain the bulk of information regarding the Domain Controller servers, the following utility script(s) can be used:  AD_Health PowerShell script and DC_Info PowerShell script, and can be found here.  The DC_Info script is actually part of the AD_Health script, but is include separately in case the need arises to only query for basic server information.  The AD_Health script checks a number of different functions and tasks required in an Active Directory environment and reports the results in a file called “c:\scripts\logfile” by default.  This can be modified in the script.  The script can (and was actually created to) be used and run as a scheduled task.  This could provide daily reports on key information about the Active Directory environment.

Another PowerShell script that duplicates some of the information obtained from the above scripts can also be leveraged.  This PowerShell script will provide a summary via email if configured correctly.  The script can be found here.

The last PowerShell script used for the Active Directory health check is the vCheck PowerShell script which provides the following information:

  • FSMO Owners
    • Domain Naming
    • PDC
    • Schema
    • RID
    • Infrastructure
  • Active Users and Machine Counts
    • User Accounts
    • Computer Accounts
  • Domain Admins Group Members
  • Passwords Set to Never Expire
  • Computers Inactive
    • Computer Name
    • Password Last Set Time Stamp
  • DCDiag Failures
    • Line Item
    • Pattern (Result)

This script also provides a summary of the statistics for running the script such as time to complete, plug-ins used, etc.  It is also a great scheduled task to provide email reports on the health of the Active Directory environment from a security standpoint and keeping accounts / objects cleaned up.  The screenshot below is a sample of the output, that can be emailed, emailed as an attachment, and / or displayed as html.

vCheck2 Sample Screenshot

Note: Active Directory Health Check script from thesysadmins was added to this list and is another great way to collect information on older domain controllers that may not have PowerShell.

The following commands (in bold) can be run using a command prompt on any domain controller in the environment.  The results / output can be piped to a text file instead of displaying them in the command window by appending “> c:\temp\filename.txt“.  Simply using “filename.txt” will place the file in the directory the command was issued from.

1.4  Manually obtaining information

Some situations will require manual information gathering.  Below are some methods to gather required information without using scripts.

Note: If running on a DC prior to Server 2008, you will need to install the Windows Server 2003 Administration Tools Pack (Adminpak) from here

Find System Boot Time and Uptime:

systeminfo | find “System Boot Time:”
systeminfo | find “System Up Time:”

Display current TCP/IP network configuration:

ipconfig /all

Analyze the state of domain controllers in a forest:

dcdiag /a

Provide an overview of any replication failures, and if last replication attempts were successful:

repadmin /replsummary
repadmin / showrepl

Update: Instead of using repadmin, the new Active Directory Replication Status Tool (ADREPLSTATUS) can be used.  The requirements are the following:

  • .NET Framework 4
  • Server 2003 Domain Controllers and later.

Returns the FSMO roles holders:

netdom query fsmo

1.5  Active Directory Sites and Services

  • Verify site objects are created for every geographical site
  • Verify subnet object(s) are created for all subnet(s) being utilized
  • Verify subnets are correctly assigned to corresponding sites

1.6  Decommissioned / Rogue DCs

Sometimes DCs are decommissioned / disabled without being removed from Active Directory using the dcpromo command:

  • If the Domain Controller is not tombstoned then run dcpromo to remove the domain controller properly
  • If the Domain Controller has been decommissioned but is still in Active Directory Sites and Services, then using the following guide will help clean things up.
  • Advanced Domain Controller removal requires using ntdsutil.exe to clean up metadata, and should be used with caution.  However, if this approach fails, adsiedit is the last resort for clean up of a domain controller, but it is recommended to contact Microsoft for support at this point.

1.7  Check Domain Controllers for general configuration

  • IP Configuration:  Is the subnet configured correctly? Are DNS servers configured correctly (the domain PDC should be first, then the Domain Controller itself or another local site Domain Controller second.  If another option is required,  the higher level (root domain) PDC can be used as well.
  • Time:  All DCs should be in time synchronization with the root domain PDC – find the time on the PDC (taking time zones into account) and verify.
  • Windows Firewall:  Inbound ports – UDP/TCP 53, 88, 389, 464; UDP 123, 137; TCP 139, 445, 3268 need to be open and available for proper Active Directory functionality.

1.8  Topology

Run the Microsoft Active Directory Topology Diagrammer (ADTD)


  • must be run from a workstation on the domain, with Microsoft Visio installed.
  • ADTD.Net Setup.msi which can be obtained from here .

Install and run “ADTD.exe”.

Populate the Server/Domain box, and run through the tabs ticking off what is to be included in the Visio output (the more detail the better) > click Discover! > click Draw!

The results will provide a lot of useful information such as FSMO role holders, Operating System and Service Pack Level of Domain Controllers, Site Links, etc. in a visual format.

1.9  Additional Investigations

  • Active Directory design
  • Security and Group Policy
  • Network Analysis
  • Network Configuration(s): firewalls / routers / switches / network load of equipment used
  • Network Services:  DNS and DHCP should be reviewed for accuracy and missing information.
  • Active Directory Domain Sites:  number of physical location(s) / number of Active Directory site(s)
  • Usage Time Frame(s):  What times during any given day are the loads for authentication higher / lower

1.10  Clients

  • Client Types:  Windows, Apple, Linux platforms, other
  • OS versions and Services Packs: (as applicable)
  • 3rd Party Add-ons:  What 3rd party helper add-ons are running (if any) for non Windows platforms for authentication and Active Directory integration

2.0     Best Practices per Microsoft recommendations

2.1  Forest / Domain Configuration and Naming

The Microsoft best practice design rule is to design a single Forest with a single Domain whenever possible. By having a single Forest and Domain, central administration can be maintained while, at the same time, it allows for granular subordinate Organizational Unit (OU) administration and delegation of authority.  This structure would provide the least amount of administrative overhead.  The PDS recommendation is thus to create a single forest / domain to maintain centralized administration and use other AD components (Organizational Units and Security Groups) to delegate administration and authority to agency / program units as required.

Forest / Domain Configuration Comparison
Option Advantages Disadvantages
Simple to create and maintainNo trusts necessaryLower hardware costs An adverse change made to the schema could potentially corrupt Active Directory and affect the entire forest
Multiple Separate schema in multiple forest More domain controllers resulting in higher hardware costs

Table 2 – Forest / Domain

Two possible DNS naming conventions have been suggested, and will be detailed here.
The first would be to use external naming both internally as well as externally.  For example, would be the DNS suffix internally and would also be used as the external addresses.
The second would be to create a DNS naming convention that uses an alternate extension internally so instead of, would be used for internal resolution.
Both methods are valid; however, PDS is recommending the second method that uses the .local or .internal extension.  This will allow for the creation of a completely separate domain that is not internet routable.  Anything that requires access to resources on the internal domain would have separate DNS entries.  The internal domain name should be something purchased and valid per Internet domain name policies.

2.2  Active Directory Sites

Active Directory sites are a collection of locations seperated by WAN connections or low speed connections having differnet IP subnets.  “Well-connected” WAN connections generally don’t require site separation.  “Well-connected” WAN connections inferes LAN speeds or better.  Site links are created to reflect the WAN connections between these sites so that a replication topology can be generated to control replication traffic between domain controllers distributed among them.  Sites are created and domain controllers are distributed among them to provide faster authentication and resource accessibility for users at each site.  Client computers are configured to attempt communication with servers located in the same site as the client before looking for domain contollers in other sites.

Requirements for using multiple sites:

  • Geographically different sites connected by a lower speed WAN connection but require high availability of data and network resources
  • Sites require dynamic mapping of network resources such as printers and mapped drives
  • Sites require access to documents and data from a central location but also locally maintained documents and data


Active Directory Sites are used as replication boundaries between Domain Controllers from the same domain.  Active Directory Sites are also used to improve performance and the end-user experience by providing location awareness for manipulating provided services.  Multiple Sites control replication traffic and resource communication latency over network slow links.  Also location awareness for resource mapping or other configuration can be leveraged in Active Directory Domains at 2008 functional level or better using Group Policy Preferences.  Even if all WAN connected sites are connected via high speed links, Active Directory Sites provide other functionality aside from replication boundaries and WAN latency.  This functionality should be considered as well for future scope.

Site Configuration Comparison
Number of Sites Advantages Disadvantages
Single Less AdministrationChanges replicate faster Too much traffic over slower WAN linkslimited ability for location awareness
Multiple (recommended) Controlled replication over WAN linksAbility for location awarenessimproved performance over slow WAN connections Sites are arranged per subnets, so configuration updates need to happen when additional subnets are added or removedpotential delays in replication of changes

Table 7 – Single vs. Multiple Sites

2.3  Security

Summary of Best Practices for Securing Active Directory Domain Services

The following table provides a summary of the recommendations provided in this document for securing an Active Directory Domain Services installation. Some best practices are strategic in nature and require comprehensive planning and implementation projects; others are tactical and focused on specific components of Active Directory and related infrastructure.  Practices are listed in approximate order of priority, that is., lower numbers indicate higher priority. Where applicable, best practices are identified as preventative or detective in nature. All of these recommendations should be thoroughly tested and modified as needed for your organization’s characteristics and requirements.

Recommendations Summary for Securing Active Directory and related infrastructure
  Best Practice Tactical or Strategic Preventative or Detective
1 Patch applications Tactical Preventative
2 Patch operating systems Tactical Preventative
3 Deploy and promptly update anti-virus and antimalware software across all systems and monitor for attempts to remove or disable it Tactical Both
4 Monitor sensitive Active Directory objects for modification attempts and Windows for events that may indicate attempted compromise Tactical Detective
5 Protect and monitor accounts for users who have access to sensitive data Tactical Both
6 Prevent powerful accounts from being used on unauthorized systems Tactical Preventative
7 Eliminate permanent membership in highly privileged groups Tactical Preventative
8 Implement controls to grant temporary membership in privileged groups when needed Tactical Preventative
9 Implement secure administrative hosts Tactical Preventative
10 Use application whitelisting on domain controllers, administrative hosts, and other sensitive systems Tactical Preventative
11 Identify critical assets, and prioritize their security and monitoring Tactical Both
12 Implement least-privilege, role-based access controls for administration of the directory, its supporting infrastructure, and domain-joined systems Strategic Preventative
13 Isolate legacy systems and applications Tactical Preventative
14 Decommission legacy systems and applications Strategic Preventative
15 Implement secure development lifecycle programs for custom applications Strategic Preventative
16 Implement configuration management, review compliance regularly, and evaluate settings with each new hardware or software version Strategic Preventative
17 Migrate critical assets to pristine forests with stringent security and monitoring requirements Strategic Both
18 Simplify security for end users Strategic Preventative
19 Use host-based firewalls to control and secure communications Tactical Preventative
20 Patch devices Tactical Preventative
21 Implement business-centric lifecycle management for IT assets Strategic N/A
22 Create or update incident recovery plans Strategic N/A


2.3.1  Security Groups

Security groups are used to secure resources by allowing administrators to assign the same permissions to a large number of users in one operation.  Windows 2000 security groups can be one of three types.  They can either be:
•    Universal group – used to grant users permission across an entire forest.
•    Global group – used to organize user objects from the same domain
•    Domain Local group – used to grant users permission to gain access to network resources such as folders, files or printers in the domain

Active Directory Management Role Groups

The actual use of security groups for Active Directory management is not very common.  This is an important step for helping maintain the security and integrity of Microsoft Active Directory.  Depending on what the business requirements dictate, rights should be delegated to each of the groups setting the access of each group based on the roles of the members of the group.

Domain Local groups will be granted rights at the Domain and OU level. Then the Global groups are assigned into the Domain Local groups. See matrix below where the row across the top is domain global groups containing the users and other domain global groups and the first column is the level of access for each of the objects.  For each level of access, a domain local group is created and then domain global groups are populated into these groups based on role requirements.

Further information on Security Groups and Active Directory management, based on roles can be found here.

 Security Group Matrix for Active Directory Administration
  Admin L1 Admin L2 Admin L3 Help Desk L1 Help Desk L2 Help Desk L3
Create, Modify, Delete Users  X  X        
Create, Modify Users  X  X  X  X    
Create Users  X  X  X  X  X  
Create Modify, Delete Computers  X  X        
Create, Modify Computers  X  X  X  X  X  
Create, Modify, Delete Groups  X  X  X      
Create, Modify Groups  X  X  X      
Create, Modify, Delete OUs  X          
Create, Modify OUs  X          
Reset Passwords  X  X  X  X  X  X

Table 9 – Security Group Assignments for AD Administration

File and Printer security groups

File system security groups will be managed in a similar way to the Active Directory managment groups.  The file resources will have domain local security groups associated directly with them and the end-user objects and global security group objects which require access to the resource will be maintained in global groups associated to the domain local groups.  This becomes increasingly important when Group Policy Preferences are introduced into the environment.  For further information on Group Policy Preferences and Microsoft recommended best practice please look here (coming soon).

2.3.2  Antivirus and Antimalware Deployments

An out-of-date malware scanner is only marginally better than no scanner at all.  Antivirus and Antimalware protection should be checked and verified up to date on all systems.  Please see Antivirus and Antimalware Recommendations (coming soon) for more details.

2.3.3  Incomplete Patching

If you don’t keep up with security fixes, your network won’t be yours for long.

Microsoft releases security bulletins on the second Tuesday of each month, although on rare occasions security updates are released between the monthly security updates (these are also known as “out-of-band” updates) when the vulnerability is determined to pose an urgent risk to customer systems.

A consistent and well maintained patching plan should be in place to reduce the risk of system compromise.

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions.  As part of a good health check, if a known issue presents itself, it is nice to provide the generally accepted solution.

Problem: |

Solution: |

Problem: |

Solution: |


Active Directory Health Script

Active Directory Health Check PowerShell Script

vCheck Active Directory Health Check

Remove a Domain Controller from Active Directory Manually

Multiple Password Policies in an Active Directory Environment

Goal / Scope

This information will identify the proper process for implementing fine-grain password polices, or implementing several different password policies in a single Active Directory domain.  By default, only a single password policy can only be set per domain.  Beginning in Windows 2008 Active Directory domains, the ability to set several password policies was enabled.  The process is not straight forward.


The new functionality Fine-grained password policies can provide are leveraged by the following changes to the Active Directory Domain Services schema:

  • A Password Settings Container (PSC) is created by default under the System container.  This container stores the Password Settings objects (PSOs) for the domain
  • Password Settings (PSO) is the object that contains the attributes for all the settings that can be modified in regards to passwords.  The following are the settings that can be used:
    • Enforce password history
    • Maximum password age
    • Minimum password age
    • Minimum password length
    • Passwords must meet complexity requirements
    • Store passwords using reversible encryption

There are also attributes for account lockout settings shown below:

    • Account lockout duration
    • Account lockout threshold
    • Reset account lockout after

In addition to these attributes, the PSO also has the following new attributes:

  • PSO link

    This is a multivalued attribute that is linked to users and / or group objects.

The PSO link can be found in the attribute named msDS-PSOAppliesTo, and it is a multivalued attribute which means you can apply a PSO to multiple users or groups. When troubleshooting a PSO, it is important to note that all user and group objects in Windows Server 2008 domain now have an attribute called msDS-PSOApplied and it contains the value of the PSO which is applied to the user or group object.

  • Precedence

    This is an integer value that is used to resolve conflicts if multiple PSOs are applied to a user or group object.

Precedence is determined by the msDS-PasswordSettingsPrecedence attribute of the PSO if all else is equal.  The following is a guide that can be used to determine how PSOs are determined and applied:

  1. A PSO that is linked directly to the user object is the resultant PSO.  (Multiple PSOs should not be directly linked to a user object)
  2. If no PSO is linked directly to the user object, the global security group memberships of the user, and all PSOs that are applicable to the user based on those global group memberships, are compared.  The PSO with the lowest precedence value is the PSO applied.
  3. If no PSO is obtained from conditions (1) and (2), the Default Domain Policy is applied.

Methodology / Process Steps

In order to correctly set a password policy, at first glance it may be a temptation to use Active Directory Group Policy.  In fact, the default password policy for a domain is set using the default domain policy.  However, building and implementing, even enforcing a Group Policy object with password policy settings enabled will do nothing to update the password policy for the objects it applies to. There are a couple of considerations to note before starting to work with fine-grained password policies:

  • Fine-grained password policies can only be applied to user objects and global security groups
  • Only members of the Domain Admins group can set policies by default, other users can be delegated this right
  • The domain functional level must be at least Windows Server 2008
  • Fine-grained password policies can not be applied to an organizational unit directly (shadow groups can be used)
  • Fine-grained password policies do not interfere with custom password filters potentially used in the same domain.  Custom password filters may have been deployed to domain controllers running Windows 2000 or Windows Server 2003 and these filters can continue to be used to enforce additional restrictions for passwords.

Creating a PSO

There are a couple of methods for viewing and modifying PSOs but only 1 way to create them.  ADSI edit is the tool necessary to create PSOs. Once ADSI edit is open, right click “ADSI edit” in the left hand pane and select “Connect to…” from the menu.

ADSI Edit Connection Menu

This will open a dialog window that will allow you to choose the connection.  Default Naming Context should be selected, all other options can be left as defaults.

ADSI Edit Connection Settings Window

Once this window is open, clicking on the items in the tree reveal anything that is listed below the item.  So clicking on Default naming context [domain name] should reveal a plus [+] next to the item, and clicking on this [+} will expand the list below.  Click on DC=[domainname] below default naming context to reveal the [+] and click it to expand the list of items below it.  Now locate CN=System and under that CN=Password Settings Container.

ADSI Edit Tree View

This is the location of the PSOs.  It should be empty by default.  Right clicking the middle pane and selecting “new” and then “Object” from the list will allow creation of a new PSO.

ADSI Edit Create New PSO Menu

Below is an example of an Existing PSO.

ADSI Edit PSO list

When “New” and then “Object” is selected a wizard runs.  This wizard asks a number of questions and requires that all the questions are answered before finishing the creation of the new PSO.

The following are screenshots of the different choices that need to be made to complete the creation of the PSO.

Initially it is going to show the class types of the policy object that can be created shown below.

ADSI Edit Create PSO Window

In this case, only 1 type of class can be selected, clicking next will move to the next step.

In the next step, a name must be selected for the password policy.

ADSI Edit Name PSO

The next step requests the precedence.  This will be important when determining which policy will be applied when using group membership.

ADSI Edit Set Precedence

The next step sets the store passwords using reversible encryption option and takes a boolean (true or false)

ADSI Edit Store Passwords Reverse

The next step configures the option for password history length, meaning “How many passwords would you like the system to remember and prevent the password from being set to these.”

ADSI Edit Password History

The next step is password complexity.  This is another boolean input, either true or false.  This sets default password complexity rules of the following:

  • Passwords must not contain the user’s entire samAccountName (Account Name) value or entire displayName (Full Name) value.  Both checks are not case sensitive.
    • The samAccountName is checked in its entirety only to determine whether it is part of the password.  If the samAccountName is less than three characters long, this check is skipped.
    • The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs.  If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password.  Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked.  For example, the name “Erin M. Hagens” is split into three tokens: “Erin,” “M,” and “Hagens.”  Because the second token is only one character long, it is ignored.  Therefore this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password.
  • Passwords must contain characters from three of the following five categories:
    • Uppercase characters (A – Z)
    • Lowercase characters (a – z)
    • Base 10 digits (0 – 9)
    • Nonalphanumeric characters: (~!@#$%^&*()-_+=`|\[]{}:;”‘<>,.?/)
    • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase.

ADSI Edit Password Complexity

The next step is setting the minimum password length.

ADSI Edit Password Length

The next step is setting the minimum password age.  This option sets how much time needs to pass before a password can be changed once a password has been changed.  The input of this option is the following format:

0:00:00:00, where the first 0 is the number of days, the second section is the number of hours, the 3rd section is the number of minutes and finally the last section is the number of seconds.  In this example, 1:00:00:00 is configured for the value of 1 day.

ADSI Edit Minimum Password Age

The next step sets the maximum password age, or the length of time before a password needs to be changed, and is in the same format as the minimum password age (0:00:00:00)

ADSI Edit Max Password Age

The next step is defining the lockout policy.  How many attempts can be made before the account is locked out.

ADSI Edit Lockout

The next step is to set the lockout duration time.  This setting defines how long the lockout of the account will last.  This setting is again formatted as the examples above (0:00:00:00)

ADSI Edit Lockout Duration

The final step is accepting what was created and completing the PSO.

ADSI Edit PSO Wizard Final Window

There is an option / button to modify other attributes, but these base attributes will be enough for most scenarios.

The final step is to apply the newly created PSO to a user or group.  This can be completed by right clicking the newly created PSO, and selecting “Properties”.  This will bring up the attribute editor window.   Locate the “msDS-PSOAppliesTo” attribute select it and click the edit button.

ADSI Edit PSO AppliesTo

This will allow the addition of the user or global security group.  This completes a setup of a fine-grain password policy for windows 2008 or later.

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions. Problem: | The password policy was assigned to a security group and accounts have been added to the security group, but the policy is not being applied to these accounts. Solution: | The most likely reason for this to occur is if the security group is not a global group.  If a universal or domain local group is used, it will fail to apply the password policy.  NOTE:  It is possible to link a PSO to other types of groups and objects in the domain, however, when the RSOP is determined for a user or group, only PSOs that are linked to global security groups or user objects are considered.  PSOs that are linked to distribution groups or any other type of objects will be ignored. Problem: | A password policy seems to be applied, but it is not the right policy or the setting don’t match what is expected. Solution: | The precedence values could be playing a role in this scenario.  Verify the attribute named msDS-PasswordSettingsPrecedence.  The key to this attribute is as follows:  The lower the number the higher the precedence to other PSOs.  Example:  2 PSOs are created and have been applied to  a user object via group membership.  The names of the groups are PasswordsA and PasswordsB respectively.  The preferred PSO or PSO that is expected is the PSO associated with the PasswordsA group.  However, this PSO has a msDS-PasswordSettingsPrecedence of 5 and the PSO associated with the group PasswordsB has a msDS-PasswordSettingsPrecedence of 2.  Due to the fact the PSO associated with the PasswordsB group has a lower msDS-PasswordSettingsPrecedence value, it will be the PSO applied to the user.


Setup Fine-grain password policy

Fine-grain password policies

Passwords must meet complexity requirements

Update GPO Templates

Goal / Scope

How to install additional GPO templates into an Active Directory environment.  This is limited to environments running Server 2008 or later


Additional templates for managing devices and endpoints are often very useful.  The method for importing GPO templates into Group Policy for use has changed from previous versions of Windows server and Active Directory.  The process is much simpler and more straight forward once it is understood.

Methodology / Process Steps

To import or leverage new GPO templates in an Active Directory environment, the admx template files simply need to be copied to the following location:


Once the files are in place, opening the Group Policy MMC, will allow the new policies to be set and applied.

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions.

Problem: | Unable to copy the files to the specified location

Solution: | These steps must be run as a domain administrator

Problem: | The new policy is unable to be read when attempting to view or make changes to the policy

Solution: | The admx templates need to be copied to all domain controllers in the environment that will be accessed to make changes to the policies.