Playbooks for the Servers Everything Depends On ​

August 31, 2026 · InfraScout Team

Every environment has a few servers the rest of it can't work without: mail, the certificate authority, the database tier, the management server, the hypervisor. For each role, this post covers the question a playbook answers, its phases, the checks worth knowing, its guardrails, and what you end up with. Exchange Assessment, PKI Assessment, Security Review, and Infrastructure Review are in the InfraScout playbook library, which we import into your tenant on request. SQL Server, SCCM/MECM, and vCenter are examples of custom playbooks you can build the same way. For how a playbook is put together, see What's in a Playbook.

All seven are read-only and evidence-bound. They save findings as they go, so a high-severity issue is recorded when it turns up. They mark a check they can't run as "not assessable", with the reason, keep credentials out of their output, and recommend changes without making them.

Exchange Assessment ​

The question: are your on-premises or hybrid Exchange servers patched, resilient, configured correctly for mail flow and clients, and free of known-exploited weaknesses?

The playbook identifies every server and its CU and SU, maps the organization and server topology, then works through databases and storage, the DAG, client access virtual directories, transport, and recipients, RBAC, and retention. It ends with security hygiene and a per-server deep dive modeled on Microsoft's Exchange HealthChecker, which checks:

  • Build currency, and whether the installed .NET and Visual C++ runtimes match what the CU requires
  • Power plan, page file sizing, TCP keep-alive, and NIC and RSS tuning
  • AMSI integration, Extended Protection, Credential Guard, SMB, and TLS configuration
  • Emergency Mitigation Service status, hybrid and OAuth certificate validity, and pending reboots

The vulnerability pass matches builds against ProxyLogon, ProxyShell, ProxyNotShell, and OWASSRF. It also scans the OWA and ECP authentication folders for unexpected .aspx files, a common web-shell indicator. The open-relay check looks for receive connectors that grant anonymous or broad permissions without an IP restriction. Resilience checks flag single-copy databases, long queues, and missing witnesses. Severity is fixed per condition: a backup older than 30 days rates higher than one older than 7, a certificate expiring within 30 days higher than one within 90.

The report runs from a management summary through topology, DAG, transport, RBAC, and a HealthChecker chapter to a four-tier remediation plan (24 hours, one week, one month, one quarter) and a chapter of positive findings, as a DOCX on request. A chat run takes 10 to 55 minutes, almost all of it read-only PowerShell.

PKI Assessment ​

The question: can anyone escalate privileges through your certificate infrastructure, and are your certificates and TLS endpoints healthy?

The playbook identifies CAs, domain controllers, and TLS endpoints, then assesses each CA (type, key and hash strength, revocation, auditing, permissions). It inventories certificates across Windows stores and Linux locations, including Let's Encrypt and Java keystores, tests TLS endpoints, reads the AD-integrated PKI objects over LDAP, and checks operational health: auto-enrollment, key recovery, CA backup, event logs, and expiry monitoring.

The core of the escalation check is the public ESC taxonomy:

  • ESC1: the enrollee supplies the subject on a client-authentication template that low-privileged users can enroll in
  • ESC2: Any Purpose or SubCA templates open to low-privileged enrollment
  • ESC3: enrollment-agent templates that let a user request certificates on behalf of others
  • ESC4: weak ACLs on certificate templates
  • ESC5: weak ACLs on the CA and other PKI objects in Active Directory
  • ESC6: a CA-wide flag that lets any requester set the subject alternative name
  • ESC7: ManageCA or ManageCertificates rights held by low-privileged principals
  • ESC8: HTTP enrollment endpoints that don't enforce HTTPS, which opens them to NTLM relay

The playbook treats an unauthorized entry in the NTAuth store as a domain compromise. RSA keys under 2048 bits and SHA-1 signatures are critical. It also flags certificates that are expired, expiring within 30, 60, or 90 days, unusually long-lived, or self-signed, and any endpoint still offering SSLv3, TLS 1.0, or TLS 1.1. The report has to include at least three attack scenarios: an ESC1 escalation, NTAuth poisoning, and a golden certificate forged with a stolen CA key. Where summary and detail views disagree, the more granular one wins.

The output is a DOCX with a template permission matrix, a certificate inventory, an expiry timeline, and severity-colored findings covering context, attack vector, affected objects, and remediation, optionally published to your wiki. It also runs as a scheduled health check in 10 to 15 minutes, with a new page per run.

A Custom Playbook for SQL Server Health ​

The question: for every instance, what is normal, and what differs from normal, and why?

Phase 0 discovers the estate and probes permission limits up front. Phase 1 records the baseline: build, edition, resources, databases, configuration, HA topology, and workload shape. Phase 2 covers twelve domains. Nine are operational: instance state, database and file state, backup and real restorability, integrity evidence, HA/DR, SQL Agent, storage/tempdb/memory, waits and blocking, and the error log. Three are posture: configuration, security, and patch level and lifecycle. Phase 3 finds root causes across instances, and Phase 4 builds the rollup and report.

The playbook compares the backup chain with each recovery model to show the RPO you can actually achieve. It reads the last known-good DBCC from database metadata and checks suspect_pages. It reviews agent jobs, alerts, and operators, tempdb contention, and IO stalls normalized per operation. Wait stats are a delta over a stated window, not cumulative counters, and queues need two readings. Posture covers linked servers and credentials, encryption, sysadmin sprawl, and build lifecycle.

The key design choice: no thresholds and no lists of bad values. The playbook says where to look and how deep, and the agent derives what's wrong from the baseline. Every finding carries an evidence contract: the object, the measured value, the source, the window, why it counts as a deviation on this instance, and the blast radius. Generic findings are not allowed.

No DBCC runs, cache flushes, configuration writes, ALTER statements, restarts, or failovers. Expensive queries are bounded (limited-mode fragmentation scans, date-bounded history reads), and a permission-blocked check is not assessable, never OK. Each instance rolls up to HEALTHY, DEGRADED, or UNHEALTHY, and one with an unassessable domain can't be HEALTHY. Posture is rated separately. The report opens with a scorecard matrix, then the baseline, findings grouped by cause, and a remediation plan. Quick, standard, and deep modes trade depth for time, and a scheduled run over an incremental window typically takes 15 to 20 minutes.

A Custom Playbook for SCCM/MECM ​

The question: is the site healthy, what does the client population look like, and which attack paths actually exist?

Phase 0 finds the site systems, reads the site identity over WMI, and tests each data path (WMI, AdminService REST, T-SQL). Phase 1 maps topology, from boundaries and discovery to distribution points and maintenance tasks. Phase 2 audits operations: SQL and replication, content, client health, failed deployments, collection sprawl. Phase 4 profiles the client population. Phase 3, the attack surface, uses the public SpecterOps Misconfiguration Manager taxonomy:

  • TAKEOVER: paths to site compromise, such as a site database granting sysadmin to the site server's computer account, or SMB signing not required, which allows NTLM relay
  • ELEVATE: a Network Access Account whose credentials work on every client, or client-push credentials that can be captured
  • EXECUTE: deployment abuse, or PXE boot without a password
  • CRED: BitLocker recovery keys stored in plaintext, or credentials embedded in task sequences

It also covers RBAC sprawl and co-management and Intune gaps. Before any unfamiliar query, the agent discovers the schema, and when documentation contradicts the live schema, the schema wins. Only WMI reads and SQL SELECTs with explicit columns are allowed. BitLocker keys are recorded only as counts, and certificates and credential blobs only as account names. Severities stop at high, because these are gaps, not active incidents. A finding that a later phase cancels with a compensating control is dismissed, not deleted. The report ends with attack-path narratives, the cancelled findings, and remediation grouped into quick wins, maintenance-window work, and strategic changes. A chat run on the site server takes minutes.

A Custom Playbook for vCenter ​

The question: what state is the virtualization platform in, and where are the snapshot, capacity, and lifecycle risks?

Two prerequisites are set up once, outside the assessment: a protected credential on the agent host and PowerCLI. Each run pins the vCenter TLS certificate by thumbprint and aborts if it differs, never trusting blindly. It then enumerates clusters, hosts, datastores, VMs, and snapshots, and checks:

  • Datastores at 85% full or more
  • Snapshots older than 30 days, and any snapshot on a domain controller. On Windows Server 2012 and later, a hypervisor that exposes a VM-Generation ID lets AD detect a snapshot revert and avoid a USN rollback; where that support is missing, reverting a domain controller can still roll replication back. Either way a snapshot is not a backup, so the check flags them
  • VMware Tools status, and virtual hardware below vmx-14
  • End-of-life guest operating systems, and host patching that looks overdue based on uptime
  • vCPU-to-core ratio and RAM over-commit

Each PowerShell call is a fresh process, so every script connects, queries, and disconnects in one go. Get-View with a property list is far faster than the default cmdlets, and aggregation happens server-side. Only Get-* is allowed. Snapshot deletion, power operations, and configuration changes need your approval per action, and the secret never crosses a logged channel. The output is a DOCX report with charts (host utilization, datastore usage, snapshot aging, guest OS mix) plus an XLSX snapshot list sorted by risk, and every insight names the cmdlet behind it. A chat run takes about half an hour. A vCenter MCP server is the alternative path, described in What MCP Servers Add to an Assessment.

Security Review ​

The question: how exposed is every server the agents can reach, and how would an attacker chain those weaknesses together?

The phases are inventory, Windows checks, Linux checks (each a shared module), cross-platform network exposure and credential hygiene, and the report. The rule is "discover, then audit": anything found gets audited, not only what you listed. On Windows and in Active Directory, it covers krbtgt age, privileged groups, delegation, LAPS, AdminSDHolder, fine-grained password policies, and password quality. For protocols, it checks SMB, LDAP signing and channel binding, the NTLM level, Kerberos encryption types, and TLS. It also covers Windows logging, Defender, AD CS ESC1 to ESC8, and SQL Server and Exchange security. On Linux, it covers SSH, sysctl hardening, SUID/SGID binaries, LUKS, auditd and AppArmor, and checks specific to the applications it finds. The report has to include at least five attack scenarios and ends with a four-tier plan and the positive findings. A typical chat run takes 10 to 30 minutes.

Infrastructure Review ​

The question: what do you actually have?

It moves from reconnaissance to service discovery to per-application deep dives, then analyzes the whole infrastructure: network topology, a dependency map, capacity, a consolidated software list, end-of-life detection, and consistency checks that catch the same service configured differently on different servers. Enumerate first, go deep second, and document the unexpected. The output is a documentation-style DOCX with status indicators.

Asking for One ​

You don't need special syntax. Name the playbook, the scope, and what you want back:

text
Run the PKI Assessment against our certificate authorities and domain
controllers. Save each finding as you go, mark anything you can't read as
not assessable with the reason, and give me the report as a DOCX with the
template permission matrix and the expiry timeline.

What These Playbooks Have in Common ​

A few patterns recur across all seven and are worth copying into your own.

Shared modules. Constraints, execution guidelines, output format, DOCX generation, wiki publishing, and the Windows and Linux security checks are written once and reused. The Exchange, PKI, and SQL health checks share one publishing module and one rollup scheme. The Security Review reuses the Exchange, SQL, and AD CS checks, so one fix reaches every playbook.

Baseline, then deviations. The SQL playbook does this explicitly. SCCM and Exchange do it implicitly by comparing site systems or servers with each other. A finding means "this differs from what's normal here."

Root cause over symptom lists. A good run turns twelve symptoms into three findings that explain them. The SQL playbook groups findings by cause. The SCCM playbook goes further: a later phase can cancel an earlier finding or raise its severity.

"Not assessable" is never a pass. A blocked check says so, with the reason, and keeps a rollup from reporting HEALTHY. Honesty beats completeness.

Stable insight keys. A recurring issue updates one insight instead of creating a duplicate each run, so you can see how long it has been open.

Dismiss, don't delete. A finding a later phase cancels is dismissed with the reason, so reviewers see why it was raised and why it no longer applies.

Next Steps ​