Claude helped me automate my Active Directory domain health checks

This is a condensed version that I condensed using ChatGPT Astra to refine the video that was a little bit longer prior to the Astra cuts and transitions, so it became prettier and shorter.

Claude helped me automate my Active Directory domain health checks, ASTRA 6 Redux

The short cut of the same Active Directory (AD) health check build, re-edited as an ASTRA 6 Redux and running about seven minutes instead of fourteen. Same project, same run, less preamble: an overdue health check across four domain controllers (DCs) at two sites, done for real with Claude Code riding along so a reusable procedure could fall out of the work. The through line is the method rather than the subject. Do not design the automation first, do the actual job, have the AI write down what you did, and pay close attention when it proposes checks you were not already running. Claude added four of those. The redux keeps every load-bearing beat: the parameterized batch script, the extra queries, the CrowdStrike alerts that arrived while Phil was still in the middle of telling Claude to stay read-only, the Robocopy collection step, the ingestion and triage summary, and the closing decision to keep the result as a procedure with a CLAUDE.md rather than promote it to a skill.

This is the short version of how an overdue maintenance task turned into an automated weekly health check, without any of it being planned that way.

I run IT alone for around 185 employees, roughly 200 computers, and about 15 virtualized servers, with four Active Directory domain controllers across two sites. A health check I had done by hand for years was overdue, so I did it for real and brought Claude Code along, recording in case a shareable procedure came out of it. One did.

The method works on any job you repeat, in any field. Do not sit down to design an automation. Do the actual work, have the AI write down what you did as you go, and then pay attention when it suggests things you were not checking. That last part is where the value hides. In my case it added four tests I had never run, including time synchronization checks and replication diagnostics that show whether the servers are genuinely talking to each other.

There is also a security lesson in here for free. Before I had finished telling Claude to stay read-only, it went off and queried my live network on its own initiative, and my endpoint security caught it and emailed me three alerts. Scope your assistant to read-only, working only on flat log files, before you let it anywhere near a production network with admin rights.

The finished build gathers logs on each server, syncs them to a network share, and summarizes only what needs my attention.

The method in one paragraph

Do not design the automation first. Do the real job, let the AI write down what was actually done, and watch for the checks it suggests that you were not running.
The suggestion pass is the payoff. Claude surfaced four tests that years of manual runs had never included.
The pattern is domain-agnostic. The Active Directory content is Phil’s job, not necessarily the viewer’s, but the workflow habit transfers to any repeated task.
The recording was opportunistic. Phil hit record only in case a procedure worth sharing came out of it.

The manual baseline

Hand-run batch scripts wrapping DCDIAG (the Windows domain controller diagnostics utility) on each of four domain controllers.
Output saved to a file per server, then gathered from all four DCs onto a network location and reviewed one file at a time in Notepad.
DCDIAG runs a fixed battery of tests per DC and flags anything failing, for example a Distributed File System (DFS) error logged in the last day.
Context for why automation matters here: one admin, roughly 200 computers, 185 employees, about 15 servers, all virtualized, with a future hire in mind who will need a written procedure to follow.

The script Claude helped build

A single parameterized batch file that runs identically on every domain controller, answering the general question “how is this server doing”.
An output folder path set as a variable at the top, a generated date and time stamp, and a variable holding the domain controller name.
The DC name and timestamp are substituted into the output filename so each file self-identifies, and everything lands in the same output folder.
Commands run first and write to file, so results exist locally on the server even if the network is unavailable.

The queries, including Claude’s additions

The standard Windows domain controller prompts and queries used to test a domain.
Windows Time queries, added because time drift is a genuine domain breaker. VMware guests and a drifted server BIOS clock can put machines on different time sources, and domains do not tolerate that.
Flexible Single Master Operations (FSMO) role queries, a new one Claude proposed unprompted.
Replication Administration (repadmin) output, showing how the servers talk to each other and surfacing any replication errors.

Collection and ingestion

Robocopy, the built-in Windows sync utility, copies each server’s output to a single collection destination once the local files are written, with Claude supplying the sync parameters.
At the time of recording this had only been tested on one server.
The ingestion step reads every collected log, updates a health triage view, and reports only what actually needs attention, rather than leaving four raw text files to read.

The CrowdStrike moment

Phil had not yet told Claude to stay read-only, or to confine itself to the flat log files, and Claude was running with elevated privileges.
Before he got around to setting that scope, CrowdStrike fired three email alerts reporting possibly malicious commands detected on his machine.
The alerts landed at the same moment he was typing the read-only instruction. Claude then finished and reported that the commands had been blocked, and that they were read-only commands.
His explanation: Claude and Codex will both go out of their way to impress you and make you happy. Usually trustworthy, but occasionally it assigns itself a side quest and buries you in minutiae you were not trying to work on.
The correction was to restrict it to the log files for the rest of the session.

What the run found

Two domain controllers failed the system log test, but for different reasons.
One was a missing Windows update, which Phil installed, with the reboot scheduled for the weekend. He characterized it as typical decommissioning noise from Windows servers.
A summary table plus a DCDIAG section listing each fault and why it failed replaced reading raw logs.
After the update on DCO2, a different controller surfaced an error that Phil flagged for his own follow-up rather than treating as urgent.

Procedure, not skill (yet)

Phil’s stated preference: create the workflow, work through the details and roadblocks on the first couple of real runs, and only then consider turning it into a skill.
He asked Claude directly whether anything here was skill-shaped, in planning-only mode, explicitly instructing it not to create the skill.
The advantage of keeping it as a procedure is that the procedure file can hold its own references and lookup tables, something he has seen Claude do on tasks like invoice processing.
Working backwards, a CLAUDE.md was then written for the systems folder so the folder knows how to handle system log and health check processing, where to look for things, and that this procedure exists. The procedure came first, the folder documentation second.

Where it could go

Servers gather their own logs on a schedule and send them to a network share.
A scheduled job pulls the share contents into an ingestion folder and runs the Active Directory health check procedure against them.
Results get reported by email, into Obsidian daily notes, or through whatever channel reliably gets attention.
Phil stopped short of building that, keeping a methodology to run reports on demand for now.

Key takeaways

Do the job for real and let the AI document it. The automation is a by-product of the work, not a design exercise done in advance.
Ask what else should be checked. That single question added time synchronization, FSMO role, and replication queries to a check Phil had run by hand for years.
Set read-only and a file-only scope before the assistant touches a production network with elevated rights. Otherwise endpoint security may set it for you.
Write the collection step into the script so the logs arrive centrally with no human in the loop, which is what makes scheduling possible later.
Replace raw log reading with a triage summary. Two DCs failing the same test for different reasons is easy to miss otherwise.
Build the procedure first, then write the CLAUDE.md that points at it, and leave the skill decision until the process has actually been run a few times.