PowerShell Script: Clear SCOM Agent Cache Safely

Clearing SCOM agent cache can resolve stale monitoring data, orphaned object issues, and heartbeat inconsistencies on managed computers. Use this workflow carefully to avoid temporary monitoring gaps.

When cache cleanup is useful

• Agent shows outdated/incorrect state
• Duplicate objects after reinstallation/rebuild
• Persistent communication anomalies with management server

1) Stop SCOM agent service

Stop-Service HealthService -Force

2) Backup and clear cache directories

$cachePath = "C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State"
$backupPath = "C:\Temp\SCOMCacheBackup_$(Get-Date -Format yyyyMMdd_HHmmss)"

New-Item -ItemType Directory -Path $backupPath -Force | Out-Null
Copy-Item $cachePath -Destination $backupPath -Recurse -Force
Remove-Item "$cachePath\*" -Recurse -Force -ErrorAction SilentlyContinue

3) Start service and force reconnect

Start-Service HealthService
Restart-Service HealthService

4) Validate agent recovery

• Check Operations Manager event logs
• Confirm heartbeat and monitoring data resume
• Verify managed object health state stabilizes

Optional command-line checks

Get-Service HealthService
Get-WinEvent -LogName "Operations Manager" -MaxEvents 50 | Select TimeCreated, Id, Message

Best practices

• Run during maintenance windows for critical servers
• Document cleanup action and reason in ticket/change record
• Avoid repeated cache clears without root-cause investigation

This method resolves many SCOM agent state issues while keeping recovery controlled and auditable.

Operational Checklist (Production-Safe)

• Confirm prerequisites and permissions before changes.
• Apply the change in staging or a low-risk window first.
• Validate client/server logs (PolicyAgent, WUAHandler, Event Viewer) after each action.
• Document rollback steps and owner responsibility.
• Re-verify service health and security controls after completion.

Validation and Success Criteria

• The target workflow completes without errors and without introducing service interruption.
• Expected security/availability behavior is confirmed through logs and direct functional tests.
• No unintended access, policy drift, or performance regression is observed after deployment.

Common Pitfalls to Avoid

• Applying changes without confirming exact environment prerequisites.
• Skipping post-change verification and relying only on command success output.
• Not defining rollback steps before touching production assets.

References

• Microsoft Learn
• CISA
• NIST