Active Directory Health Check Discovery Steps

You are here:
< Back

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

Last Updated On October 24, 2017