Active Directory Forest Health Monitoring with PowerShell

Use Case

In medium to large enterprise environments, Active Directory is not just a directory service. It is the authentication backbone of the organization. Every login, Kerberos ticket, Group Policy application, and many application authentications depend on it.

Now imagine an environment with multiple domains in a single forest, Domain Controllers spread across different AD Sites, limited WinRM access between network segments, security restrictions blocking remote PowerShell remoting, and no centralized AD monitoring tool.

Leadership still expects high availability and zero authentication failures. This is where forest-level health visibility becomes important.

What This Script Does

The purpose of Get-ADForestHealth.ps1 is to provide a forest-wide, domain-by-domain Domain Controller health snapshot using native tools.

Instead of depending completely on WinRM-based remoting, the script uses WMI and native utilities such as DCDIAG to gather structured health metrics and generate a consolidated HTML report.

The result is a clear, color-coded, operationally useful health dashboard that can be reviewed by Active Directory administrators, infrastructure teams, or operations teams.

Architecture Overview

The script follows a simple logical flow: discover the forest, enumerate domains, identify each domain’s PDC Emulator, collect Domain Controller health data, and generate a single consolidated report.

Logical Flow

At a high level, the script performs the following steps:

1. Discover all domains in the forest
2. Identify the PDC Emulator for each domain
3. Execute collection logic against each domain
4. Enumerate all Domain Controllers in that domain
5. Run health checks against each Domain Controller
6. Gather OS, disk, CPU, memory, uptime, and DCDIAG results
7. Build a structured HTML health report
8. Save one consolidated forest-level report

Tools Used

The script relies on native Microsoft and Windows tooling that is commonly available in Active Directory administration environments.

What Exactly Is Being Checked?

The report is designed to highlight common health indicators that matter during daily operations, incident review, and proactive Active Directory maintenance.

Health Check List

Connectivity
DFSREvent
KccEvent
KnowsOfRoleHolders / FSMO awareness
NetLogons
ObjectsReplicated
OS free space on system drive
CPU utilization
Memory utilization
Uptime in days

PowerShell Script

The full PowerShell script is maintained on GitHub so it can be updated, versioned, and downloaded directly.

# Quick usage

# 1. Download or clone the script from GitHub.

# 2. Review the script configuration:
#    - Report output path
#    - Domain or forest scope
#    - Execution account permissions
#    - Any email or report delivery settings, if configured

# 3. Run from a secured admin host or management server
#    with RSAT / Active Directory PowerShell module available.

# 4. Recommended execution:
powershell.exe -ExecutionPolicy Bypass -File .\Get-ADForestHealth.ps1

Requirements

Run the script from a trusted administrative system that has the Active Directory PowerShell module installed. The account running the script must be able to query forest, domain, and Domain Controller information.

Because the script collects health information from Domain Controllers, firewall rules, WMI access, RPC availability, and security permissions can affect the output. If a check fails, that failure itself is useful because it may point to a visibility or management-path issue.

How to Read the Report

Treat the report as an operational dashboard. Green or healthy checks mean the Domain Controller responded as expected. Warning or failed checks should be reviewed by domain, site, and Domain Controller name.

Start with failed connectivity, replication, DFSR, and NetLogons checks first. These are usually more urgent than resource warnings such as high CPU or low disk space, although both matter for long-term stability.

Operational Value

The main value of this script is repeatability. Instead of manually running checks across domains and Domain Controllers, administrators can generate a consistent forest-level report and compare results over time.

This is especially useful before and after patching, during audit preparation, after network changes, after Domain Controller maintenance, or when investigating authentication complaints across multiple sites.

Limitations

This script provides a health snapshot, not a full monitoring platform. It does not replace centralized monitoring, alerting, log analytics, or long-term trend collection.

Results also depend on network reachability and permissions. If WMI, RPC, firewall rules, or administrative access are restricted, some checks may fail or return incomplete data.