Home/Toolchest

Windows server health snapshot

A read-only Windows Server snapshot for uptime, disk pressure, memory, stopped automatic services, and recent critical events.

Good For

  • server health checks
  • incident intake
  • patch window readiness
  • support handoff
  • baseline evidence

How to Use It

  1. Capture uptime first so recent reboots or long-running hosts are visible before deeper troubleshooting.
  2. Review disk free space by fixed drive and compare low-space drives with application, database, IIS, or log locations.
  3. If memory pressure is suspected, compare free memory with workload expectations and recent monitoring history.
  4. Review stopped automatic services, then confirm whether each service is intentionally disabled, delayed, or failing.
  5. Check recent system errors for disk, service-control, driver, update, or unexpected shutdown signals.
  6. Save the snapshot before making repair decisions so the ticket has a before-state for validation.

Execution Modes

  • local
  • remote-single-host
  • remote-host-list

Inputs and Outputs

Inputs

  • computer name
  • CSV or TXT server list
  • admin or delegated read access
  • expected service baseline
  • known disk thresholds

Outputs

  • verbose-console
  • csv
  • future-html-report

Command Starter

Safe to run: read-only

$ComputerName = "server01"
Get-CimInstance Win32_OperatingSystem -ComputerName $ComputerName | Select-Object CSName, LastBootUpTime, FreePhysicalMemory, TotalVisibleMemorySize
Get-CimInstance Win32_LogicalDisk -ComputerName $ComputerName -Filter "DriveType=3" | Select-Object DeviceID, Size, FreeSpace
Get-Service -ComputerName $ComputerName | Where-Object { $_.StartType -eq "Automatic" -and $_.Status -ne "Running" } | Select-Object Name, DisplayName, Status
Get-EventLog -ComputerName $ComputerName -LogName System -EntryType Error -Newest 25 | Select-Object TimeGenerated, Source, EventID, Message

Validation

  • The snapshot identifies whether disk, memory, service state, or recent system errors are likely contributing factors.
  • Any stopped automatic service is classified as expected, intentionally disabled, or needing service-specific triage.
  • Follow-up checks after repair show improved free space, resolved service state, or no repeat critical event.

Reporting

  • copy the uptime, disk, service, and event summaries into the incident record
  • export multi-server runs to CSV for patch or support review
  • promote repeated health checks into a scheduled HTML report when drift matters

Safety Notes

  • This snapshot is read-only and should not restart services or clear logs.
  • Do not treat every stopped automatic service as a failure; compare against the server role and change history.