Health Checks That Are Done Before the Team Arrives ​

September 9, 2026 · InfraScout Team

Picture a working day that starts with the health check already done: a fresh, dated wiki page covering your domain controllers, internal certificate authority, SQL Server estate, and Microsoft 365 mail hygiene, with an overall status, a rating per area, and what changed since last time. This post walks through that pattern with agentic workflows: the shared design, what each check should cover, and the guardrails that make it safe to run unattended.

The problem: checks exist, but nobody runs them ​

Most teams already know what a good health check looks like: a dcdiag routine, a spreadsheet of certificate expiry dates, a list of SQL Agent jobs to look at. What goes missing is consistency. The check runs when someone has time, which usually means after something has already broken. Meanwhile the estate drifts. Replication falls behind on one site, a CRL stops publishing, a backup chain gets a gap, a temporary allow-list entry becomes permanent. A check only catches this kind of slow drift if it runs every time, the same way, and remembers what it saw last time.

The shared skeleton ​

All four checks follow one design. Each is a scheduled agentic workflow started by a short instruction with three parts: the playbook to follow, a rule for the time window, and a rule for publishing. The playbook holds the checklist; the instruction tells the run how to fit into a series of runs.

text
Run the domain controller health playbook against all domain controllers.

Window: read the "last run" marker from memory and cover everything from
that timestamp up to now, with no gap and no overlap. If no marker exists,
use the last 24 hours as a baseline. When the run finishes, write the new
marker.

Findings: list the open insights for this check, re-verify each one against
the current state, update or resolve them, and save new findings as insights
with evidence. Submit each per-host session for review.

Publishing: create a NEW page in the <space> wiki space titled with today's
date and the covered window. Never overwrite or edit an existing page.
Start the page with the overall status (healthy, degraded, or unhealthy),
then rate each area OK, WARN, or FAIL, then list what changed since the
last report: new, worsened, and improved.

An incremental window ​

Each run reads a "last run" marker from memory and covers the stretch from that marker up to now. The windows line up end to end, so no event falls into a gap and none gets counted twice. The first run has no marker, so it takes a baseline instead: 24 hours for most checks, and seven days for the mail report, where weekly patterns matter more. Windowed checks such as event log sweeps look only at what happened inside the window. Status checks such as replication health or certificate expiry are a snapshot of the current state.

The same memory holds an environment overview, a change log, known issues and quirks, and per-host baselines, so each run starts with context instead of rediscovering it.

Findings that stay current ​

Each finding is saved as an insight with its evidence. Every run re-verifies the open insights for its check against the current state, updates them, opens new ones, and changes the status when something is fixed. The per-host sessions go to human review, so an engineer still signs off on the conclusions.

A new page every run ​

The run never overwrites an old page, so the page history becomes the trend line. The header gives the exact window and overall status, each area gets an OK, WARN, or FAIL rating, and the section on what changed since last time is usually the one people read first.

Domain controller health ​

On each domain controller, the run uses PowerShell, LDAP queries, and event log queries through the agent to work through a numbered checklist. The checklist covers replication, SYSVOL and DFSR state, time synchronization, FSMO roles, RID pool headroom, disk space, the secure channel, LDAP, global catalog and Kerberos availability, and backup recency. It adds dcdiag output and sweeps the event logs over the window. The report rates each DC and rolls those ratings up to the domain.

Comparing against the last run pays off here. In one example, a steady audit event stream stopped on every domain controller at once. A quiet log alone proves nothing, so the run checked the registry and the exported security policy and confirmed a real configuration change rather than a quiet period.

PKI and certificate authority health ​

The PKI check covers the CA hosts and any web-enrollment servers. It checks CA and end-entity certificate expiry, CRL and delta CRL publishing and their overlap periods, enrollment failures, and certificate templates that match known risk patterns (the ESC categories). It sweeps the event logs for auto-enrollment failures and service crashes and keeps a certificate inventory. Findings are ranked from critical to low and marked unchanged, worse, or improved.

Typical findings include expired certificates, weak hashes or small keys, private keys where they shouldn't be, CRL publishing problems, and enrollment failures that worsen a little each week. The check is careful about claims: an error absent from the current window is "not reproduced this window," not fixed.

SQL Server health ​

The SQL check covers every SQL Server host and instance it can reach. It reviews the error logs, SQL Agent job history, backup continuity, tempdb latency, DBCC baselines, and wait stats. It also looks for privilege problems such as logins with more access than they need. Open findings are re-checked live on every run, and the report separates patterns that affect a whole cluster from problems on a single host.

It also names its own gaps: an instance the service account can't read appears as "could not assess," never as healthy.

Microsoft 365 spam report ​

The mail check uses the Microsoft cloud tools and Defender advanced hunting. It splits the window's mail by verdict (spam, high-confidence spam, phish, bulk, and malware), shows how much was delivered, quarantined, or blocked, and lists the most-targeted recipients. It also covers detections and post-delivery removals (ZAP), including how long ZAP took to act.

The second half of the report doesn't depend on the window. It covers standing exposure that lets mail skip filtering: allow-list entries, transport rules that bypass filtering, impersonation protection that is turned off, tenant-wide auto-forwarding, and domains without DKIM. It confirms each of these by reading the Exchange Online configuration without changing anything. Week over week, the report shows campaigns escalating, spoofed-sender patterns returning, and slow post-delivery removal, and it separates a one-off false-positive spike from a trend.

What each check should cover ​

If you're building your own playbooks, start from these:

  • Domain controllers: dcdiag and repadmin results, SYSVOL and DFSR state, the time source, FSMO role reachability, RID pool headroom, the secure channel, and event signatures for trust and certificate-validation failures.
  • PKI: CA and end-entity expiry, CRL and delta CRL publishing and overlap, key sizes and hash algorithms, auto-enrollment failure rates, and ESC template patterns.
  • SQL Server: backup recency and continuity, Agent job history, error log sweeps, tempdb latency, login role membership, and login failures for clustered service accounts.
  • Mail: the verdict split, Defender for Office 365 detections and ZAP timing, and audits of allow-lists, bypass rules, and anti-phishing settings. Review false positives week over week.

Two rules apply to all four: a window based on a saved last-run marker, and a new page for every run.

Governance ​

Every run acts as a dedicated service account, and the workflows that use Microsoft cloud tools are pinned to a single cloud connection. Each workflow gets only the tool groups it needs. The infrastructure checks use the agent, playbook, inventory, and insight groups. The mail check adds identity, service, and security. Wiki publishing goes through a separate external MCP server with its own scope, and the instruction names the one wiki space the run may write to. Any trigger payload is treated as untrusted data.

WARNING

Keep these workflows assessment-only. They read, record insights, and submit sessions for review. They never remediate. When a run lacks the rights to check something, it should report the gap instead of trying to work around it.

Cadence ​

Each run takes roughly 12 to 16 minutes, so an early-morning schedule has the page ready before the working day starts. The domain controller and spam checks in this pattern started daily, and most checks later moved to a weekly Monday run. The window logic handles both: a Monday run simply covers everything since the last marker. After about three months, the main benefit is that nobody rebuilds context by hand. Every page starts where the last one stopped.

Next steps ​

Start with one check. Write or adapt a playbook for it, use Run now a few times until you trust the report, then add a schedule. The agentic workflows admin guide covers triggers, service accounts, and run review. The playbooks guide shows how to structure the checklist. AI memory explains where the last-run marker and baselines live.