AD Health Check

AD Health Check inspects an Active Directory domain end to end and tells you, in plain language, whether it’s healthy — without touching a thing. Every check is a read-only query or a run of Microsoft’s own diagnostics — it writes nothing to Active Directory, DNS, DHCP or any server — and it’s especially valuable before and after a domain-controller rebuild or a recovery. This guide explains how to run it, every check it performs, and how to read every line it produces.

OverviewWhat the tool does

AD Health Check is a read-only Active Directory recovery health validator. It connects to your domain, runs sixteen families of checks — forest and domain configuration, domain controllers, FSMO roles, RID pool, AD services, replication, AD backup age, sites & subnets, SYSVOL, SYSVOL/DFSR backlog, GPO consistency, DNS, time source, actual time skew, DHCP authorization, and a full pass of Microsoft’s dcdiag — and renders the findings as a color-graded PASS / WARN / FAIL report you can read on screen or export.

• It makes no changes. Every operation is a read-only query or a diagnostic command. Nothing in Active Directory, DNS, or on any server is modified.
• Nothing to install or configure. One self-contained Windows application that hosts Windows PowerShell 5.1 in-process — no modules to import, no scripts to trust, no internet needed to run the checks.
• Built for recovery confidence. Run it before you rebuild or seize roles to capture a baseline, and again afterward to prove the domain came back healthy.

SetupBefore you begin

Requirements

Installing the AD tools (RSAT) on a workstation

You don’t have to run AD Health Check on a domain controller. It runs equally well from a domain-joined Windows 10/11 admin workstation — often the preferred choice, since it keeps tools off the DCs. The one requirement is Microsoft’s Remote Server Administration Tools (RSAT), which supply the ActiveDirectory PowerShell module along with repadmin and dcdiag. All three arrive from a single RSAT feature.

Open Windows PowerShell as Administrator and run:

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

That one command installs the AD module, repadmin, and dcdiag together — everything the checks need. If you also want the optional DHCP authorization check to enumerate servers from your workstation, add:

Add-WindowsCapability -Online -Name Rsat.DHCP.Tools~~~~0.0.1.0

The install pulls from Windows Update / Features on Demand, so the workstation needs internet access (or a configured WSUS). It takes a minute or two and doesn’t require a reboot. Confirm what’s present with:

Get-WindowsCapability -Online -Name Rsat.ActiveDirectory* | Select-Object Name, State

Then launch AD-HealthCheck.exe and approve the UAC prompt. On Windows Server, install these instead with Install-WindowsFeature RSAT-AD-Tools; on a domain controller they’re already present.

Run it as a domain user

RSAT supplies the tools, but querying Active Directory still needs domain credentials. A workstation signed in with a local account (for example PC-NAME\you) cannot authenticate to AD — you’ll get an “SSPI failed” or “could not find a forest identified by ‘PC-NAME’” error, even though the domain is reachable. Two ways to give it a domain identity:

• Sign in to the workstation as a domain user with AD rights (Domain Admin or delegated), then run the tool normally.
• Or launch it with domain credentials from a local session using runas /netonly:

runas /netonly /user:YOURDOMAIN\adminuser "C:\Tools\AD-HealthCheck.exe"

/netonly keeps your local desktop but hands the tool — and the repadmin and dcdiag it runs — network credentials for the domain, so every check can authenticate. On a domain controller none of this applies: it already runs in a domain context.

What’s in the box

The download is a portable folder — no installer required:

• AD-HealthCheck.exe — the application (published by KW Tech Solutions LLC).
• EULA.txt, LICENSE.txt, and README.txt.

Install & first run

Copy the folder onto a domain controller (or an RSAT-equipped admin box), extract it, and run AD-HealthCheck.exe. Approve the UAC prompt so it runs elevated. On first launch you’re shown the license agreement; the tool won’t proceed until you accept it.

ActivationLicensing & activation

AD Health Check is licensed to run — a valid license key is required before the checks will start. There is no limited free-run mode. You enter your key once and it’s remembered on that host.

On launch, the license state is shown on the right of the toolbar. Until you activate, it reads Not activated — enter your license key to run, and the Run Checks and Save Report buttons are disabled. Click Activate… and paste the license key from your purchase confirmation.

On success you’re confirmed activated, the status turns to a green Licensed, and Run / Save unlock.

WorkflowRunning a health check

The whole tool is one screen. Across the top is the Checks to run panel; below it the action buttons and license status; then the results grid; and at the bottom a live activity log.

Because every check is read-only, you can run it as often as you like, on a live production domain, without risk. A run typically takes well under a minute, plus up to a few minutes for the comprehensive dcdiag pass on a busy domain.

ReferenceThe checks, explained

Each check family below validates one part of Active Directory and emits one or more graded rows. Every row carries a Status (PASS / WARN / FAIL / INFO), a Category, the specific Check, and a Detail line with the evidence.

Notes on individual checks

• AD Recycle Bin (Forest / Domain). If it’s off, the tool recommends enabling it — it lets you restore accidentally-deleted users, groups, and OUs. It’s surfaced as a WARN because it’s advisory, not a fault. Note that enabling the Recycle Bin is a one-way change (it can’t be turned back off), which is why the tool suggests rather than does it.
• Replication partitions. A healthy domain shows a PASS for every partner in each of the five partitions. A FAIL here — with the partner and partition named — is one of the most important signals for recovery, so read these rows first if the verdict isn’t clean. The tool grades how recently each link last replicated: fresh is a PASS, stale is a WARN, and a partner whose last success predates the domain’s tombstone lifetime is a FAIL — that DC is past the point where replication can resume without lingering-object risk, so it needs investigation or a rebuild rather than a forced sync.
• AD backup age. A recovery tool has to answer “when was this last backed up?” — a domain nobody has backed up is the worst recovery case. The check reads the last AD/System-State backup time per partition (via repadmin /showbackup) and reports the oldest. It is deliberately advisory — WARN at most, never FAIL: a missing or old backup is a strong prompt to act, not a sign that AD itself is broken.
• DNS ghosts. The DNS check specifically looks for orphaned DC service records — SRV records left behind by a DC that’s no longer in the domain — a common leftover after a botched demotion that quietly breaks locator lookups.
• Time. If the PDC’s or a DC’s time source can’t be read (for example an access error when the tool isn’t elevated), it’s reported as a WARN with a hint to re-run elevated, rather than being silently passed.
• Time skew. Separate from the Time check’s configured source, this measures the real offset of each DC’s clock against the reference (via w32tm /monitor). Kerberos tolerates about five minutes of skew before authentication fails, so the check passes under 30 seconds, warns as drift grows, and fails past five minutes. If w32tm can’t reach the DCs (for instance when run un-elevated), it reports a single advisory WARN rather than guessing.
• RID pool. Every DC hands out security IDs from a shared, finite RID pool. This reports the headroom left; it almost always passes (the pool is huge), but it is worth the query for the rare cases that matter — a pool near exhaustion, or one corrupted by a bad DC restore / USN rollback (which shows as a FAIL, because it can silently break object creation).
• DFSR backlog. The SYSVOL check confirms the share is published; this confirms it’s actually replicating. SYSVOL can be shared yet silently not converging — so a GPO change on one DC never reaches the others. A non-zero backlog that persists (or a journal-wrap event) means DFSR is stuck. Needs the DFSR tools (present on a DC); on a box without them the check reports an INFO note rather than failing.
• GPO consistency. A Group Policy object lives in two halves — an AD object and a SYSVOL folder — that must stay in sync. This flags orphans (one half without the other) and GPT.ini version mismatches. A brief mismatch during an edit is normal; a persistent or widespread one is an early warning that SYSVOL replication is broken.

OutputReading the results

Every row is graded with one of four statuses. The banner at the top of the grid rolls them into a single verdict.

The verdict line

Above the grid, a running verdict summarizes the whole run and updates live as rows arrive:

The verdict is followed by the tally — PASS=… WARN=… FAIL=… — the same counts that head the exported report.

On screen, findings fill the colour-graded grid in the main window shown earlier — one row per finding (Status, Category, Check, Detail) with the running verdict above it. When you save the run, those same rows are written to a file: the HTML report under Saving the report below shows exactly what the saved report looks like.

ReferenceThe dcdiag diagnostics

The last check runs Microsoft’s own dcdiag across every domain controller in the enterprise, in two passes. First the comprehensive set with the DNS suite held back (/c /v /e /skip:DNS) — every applicable test, per DC, with the forest-wide tests running once. Then the DNS suite on its own, with its read-only subtests named explicitly (/test:DNS /DnsBasic /DnsForwarders /DnsDelegation /DnsRecordRegistration).

Splitting it that way is deliberate, and it is the reason this tool can call itself read-only — see Dynamic update — deliberately not run below. Together the two passes can take up to about fifteen minutes on a large or busy domain. Each dcdiag test becomes its own graded row — per-server tests are labelled with the DC they ran on (e.g. AD-DC1 / Connectivity) — so you get the depth of dcdiag without reading its raw console output.

If a domain controller is unreachable, an enterprise-wide dcdiag would otherwise stall for minutes — several comprehensive tests (CheckSecurityError, CutoffServers, the DNS suite…) probe every DC in the topology and hang on the dead one. The tool detects the outage and instead runs an essential set of DC-local tests per reachable DC, marking each unreachable DC as a skipped FAIL (it’s already flagged under Domain Controllers). So a run stays fast and useful even mid-outage — which is exactly when you need it — and the DCs and Replication checks give the authoritative picture of what’s down.

Typical tests you’ll see include Connectivity, Advertising, FrsEvent / DFSREvent, SysVolCheck, KccEvent, KnowsOfRoleHolders, MachineAccount, NCSecDesc, NetLogons, ObjectsReplicated, Replications, RidManager, Services, SystemLog, VerifyReferences, and the DNS suite (Authentication, Basic, Forwarders/Root hints, Delegations, Dynamic update, Records registration) plus CrossRefValidation per partition.

Warnings that are expected

A few dcdiag results commonly show as WARN on a perfectly healthy domain. The tool labels each so you don’t chase them:

Wrap-upSaving the report

Click Save Report… to export the current results. Three formats are offered:

Example — the HTML report (scroll within the frame)

The file is named with a timestamp by default (ADHealthCheck_YYYYMMDD_HHMMSS). Run the check before a change and again after it, save both, and you have a clean before/after — the HTML pair makes an especially clean recovery record — that proves the domain returned to health.

ReferenceTroubleshooting

The session log — written for you, every run

Saving a report is a choice. The session log is not — AD Health Check writes one every time it runs, whether you ask or not. Every line that appears in the on-screen activity log is also appended, as it happens, to:

%ProgramData%\KWTechSolutions\ADHealthCheck\logs\session-<timestamp>.log

Each file is headed with the product version, the machine it ran on, and the user who ran it. Because it is written line by line rather than flushed at exit, the record survives closing the window or a crash mid-run — which is exactly when you want it. It is a plain text file; open it with anything.

Nothing is transmitted anywhere. The log stays on the machine that produced it, and removing old ones is up to you.

ResponsibilityBackups are yours

You are responsible for maintaining a current, tested FULL SYSTEM BACKUP of every domain controller in your environment. AD Health Check reads and reports. It does not create a backup, does not verify one, and is not a substitute for one.

This matters most in exactly the situation this tool is built for: a rebuild or a recovery. A clean report tells you the domain looks healthy right now. It tells you nothing about your ability to get back to this state if the next thing goes wrong.

LegalLicensing & notices

Your use of the software is governed by the End User License Agreement (EULA.txt, shown on first run). In short: AD Health Check is read-only and its findings are advisory; it is provided “AS IS,” without warranty, and does not guarantee the health, security, or recoverability of any system. KW Tech Solutions LLC is not liable for data loss, service disruption, or any decision or action taken on the basis of its findings. You are responsible for maintaining a current, tested FULL SYSTEM BACKUP of every domain controller in your environment — this software does not create, verify, or substitute for one.

Support covers this program only — its installation, activation and operation. It does not extend to Active Directory, DNS, DHCP, your domain controllers, or anything else the program inspects, nor to acting on its findings.

The About dialog, reachable from the title bar, carries the short version of everything on this page: the version and publisher, what read-only does and does not cover (including the DnsDynamicUpdate exclusion), that full system backups are yours, where the session log is written, the AS-IS terms, the support scope, and the Microsoft trademark notice.

Microsoft, Windows, Windows Server, and Active Directory are trademarks of Microsoft Corporation. AD Health Check is an independent product of KW Tech Solutions LLC and is not affiliated with, authorized, sponsored, or endorsed by Microsoft.