Docs
ConnectWise Automate Patching Not Working? Fix Policy, WUA, and Reporting Gaps
Troubleshoot ConnectWise Automate patching when policy enforcement breaks Windows Update behavior, WUA health blocks installs, or reporting does not match endpoint reality.
Troubleshooting for MSPs and IT admins troubleshooting ConnectWise Automate patch workflows
Free Audit
Run a Free ConnectWise Automate Windows Update Audit
If you want to validate ConnectWise Automate patch risk across devices instead of relying on one patch status view, run the free audit against your Automate environment.
Short Answer
Direct answer: in ConnectWise Automate, patching problems usually come from one of four places: Automate policy is enforcing Windows Update behavior you did not expect, Windows Update Agent or BITS is unhealthy on the endpoint, reporting and approval state is stale or contradictory, or reboot and update-source controls are blocking completion.
Do not start by changing every patch rule. First prove whether the failure is policy, reporting, install, or detection.
ConnectWise Automate patching failures are usually not one bug. The research points to a repeat pattern: Automate policy and registry enforcement changes Windows Update behavior, local WUA or BITS health breaks scan or install, or the Patch Manager state machine falls behind because approvals, supersedence, reboot state, or retry counters no longer reflect what the endpoint can actually do.
Caution: a missing or stale patch result in Automate does not automatically mean policy is wrong. It can still be an endpoint WUA issue or reboot/completion issue.
Use this guide to troubleshoot ConnectWise Automate patching when approval flow, policy scope, install status, or reporting does not match endpoint reality.
Fast Triage in Automate
- Check the effective Automate patch policy, especially whether Windows Update UI or policy is being managed in a way that changes endpoint behavior.
- Confirm the patch is in scope and review approvals, supersedence, and current state in Patch Manager.
- Review the patching dashboard or tile for missing baselines, failed installs, and stale inventory.
- Validate Windows Update Agent, BITS, and reboot state on one affected endpoint before widening scope.
Common ConnectWise Automate Failure Patterns
| Symptom | Likely cause | What to check first |
|---|---|---|
| Windows Update UI is broken or hidden | Automate policy is enforcing UI-disabled or registry-backed Windows Update settings | Check the effective patch policy and Windows Update agent mode first. |
| Patch inventory is empty or stale | WUA, BITS, network access, or update-source policy is failing on the endpoint | Check WUA health, BITS, and whether the endpoint can reach the intended update source. |
| Approved patches never install | Supersedence, retry exhaustion, pending reboot, or endpoint Windows Update failure | Check the current approval state, reboot status, and whether failed retry state has stopped more attempts. |
| Machines stay missing for too long | Reporting lag, stale patch state, or the endpoint never returned a clean final status | Compare Automate with endpoint proof before changing policy. |
| Patching fails by customer or site | WSUS remnants, firewall, proxy, bandwidth, or third-party controls are blocking updates | Check update source, network path, and security-tool interference on that client. |
The Main Split to Make First
ConnectWise Automate troubleshooting moves faster when you classify the failure first:
- Reporting mismatch: the patch may be installed or superseded, but Automate still shows it as missing or expected. If that is the symptom, go to ConnectWise Automate missing patches.
- Install failure: the patch reached install and Windows failed, or Automate stopped retrying it. If that is the symptom, go to ConnectWise Automate updates not installing.
- Detection failure: the patch never surfaced in inventory or scan results the way you expected. If that is the symptom, go to ConnectWise Automate not detecting patches.
What the Research Says to Check
- Policy-mode side effects: Managed modes, UI-disabled modes, and registry tattooing can make Windows Update look broken when Automate is enforcing that behavior intentionally or incorrectly.
- WUA and BITS health: empty patch windows, failed installs, and stale inventory often trace back to unhealthy Windows Update services, cache corruption, or servicing-stack problems.
- Supersedence and retry-state problems: approved patches can become superseded, and failed retry counters can leave Automate in a stale state until you reset the right layer.
- WSUS, proxy, firewall, and third-party tools: update-source controls and security tooling can break scanning and installs even when Automate policy looks right.
Common Mistakes
- Deleting Windows Update registry keys locally without fixing the upstream Automate policy that is reapplying them.
- Ignoring WUA and BITS health on the endpoint.
- Treating stale Patch Manager state like proof of live endpoint state.
- Skipping reboot-state checks when installs appear stuck or inventory looks empty.
- Assuming approvals alone prove the patch should still install even after supersedence or retry exhaustion.