PowerShell Health-Check Pack for Active Directory, DNS, DHCP, and Certificate Expiration

Expected Outcome

One script can run individual health functions or a combined Check-Health command, returns consistent objects suitable for CSV/JSON reporting, and has known failure cases that prove the checks work.

Assumptions

• Windows PowerShell 5.1 or PowerShell 7 with the required Windows management modules available from a supported admin host

• Read access to the selected AD domain controllers, DNS servers, DHCP servers, and certificate stores/endpoints

• A small explicit target list; do not discover and query an entire enterprise by default

• A writable local output folder for evidence files

Bill of Materials

• Windows Server with PowerShell

• Active Directory module for Windows PowerShell

• DNS and DHCP management tools

• SSL certificate management tools

Build Steps

1. Define a common result contract

   Every check should emit PSCustomObject fields such as Check, Target, Status, Detail, ObservedAt, and EvidenceSource. Status should be a small controlled set such as PASS/WARN/FAIL/UNKNOWN.

2. Implement and test each function independently

   Create Get-AdHealth, Get-DnsHealth, Get-DhcpHealth, and Get-CertificateHealth functions. Each accepts explicit targets and performs read-only queries only. Do not call a function from Check-Health until it can be invoked by itself and produces the shared result contract.

3. Keep health criteria explicit

   Examples: AD query succeeds against the named DC; DNS resolves a defined test record through the intended resolver; DHCP scope utilization is reported rather than guessed healthy; certificate expiry is compared with a configurable warning threshold. Separate observed data from the PASS/WARN/FAIL rule.

4. Compose Check-Health from the tested functions

   Check-Health calls the four functions with supplied target parameters, combines their objects, prints a concise console view, and can export the same objects to CSV or JSON without changing the underlying checks.

5. Create controlled negative tests

   Use safe lab conditions such as a nonexistent DNS record, an unreachable test endpoint, or a certificate threshold deliberately set above the remaining lifetime. Confirm the expected check changes status while unrelated checks remain stable.

6. Schedule only after interactive validation

   Run the completed script under the exact account and PowerShell edition planned for Task Scheduler, use absolute paths, and confirm the scheduled run produces the same structured output as the interactive run.

Validation

• Each function runs independently and emits the same schema

• Check-Health combines results without relying on undefined variables or placeholder functions

• At least one controlled negative test produces the expected FAIL/WARN

• The scheduled execution context can reach the targets and write the evidence file

• The report distinguishes UNKNOWN/query failure from a genuinely healthy result

Troubleshooting

• If a module is unavailable, identify the supported management host/module source instead of installing arbitrary modules during the health run

• If remote access fails, capture the target-specific authorization or network error as UNKNOWN rather than reporting the component unhealthy

• If scheduled and interactive output differ, compare identity, PowerShell edition, working directory, module path, and network credentials

Cleanup or Rollback

• Remove the scheduled task if it was created only for the lab

• Delete only disposable evidence files; keep the final script and test results under version control

Next Improvements

• Set up email notifications for health check failures.

• Integrate with monitoring tools for centralized logging.

• Expand the script to include additional services as needed.