## TL;DR
RDP is a viewing tool, not a monitoring channel: sessions end at reboots (which patching causes on purpose), idle policies disconnect them, and the install continues unseen. Move monitoring to session-independent sources: the Windows Update Agent and event logs queried over WinRM or the local agent, CBS and WindowsUpdate logs read after the fact, and the scheduled-task result pattern for installs.

```text
rdp session dropped while agent monitored a failed update install
```

## Use this when
- The watcher loses track of updates at the first reboot and cannot tell success from failure.
- RDP sessions to patching hosts drop repeatedly during waves.
- Someone must stay logged in to babysit installs, defeating the automation.

## Not for this skill when
- A human is doing hands-on troubleshooting on one host. Interactive RDP is appropriate there.
- The host has no WinRM or agent channel at all. Establishing a management channel is the prerequisite project.

## Steps
1. Inventory what the RDP watcher actually reads (progress UI, dialogs) and map each item to a log or API source: update history, event log IDs for install start and completion, CBS log tail. Verify: every watched signal has a session-independent source
2. Implement the monitoring over WinRM short polls or the local management agent, reading those sources. Verify: a test update is tracked start to finish over the new channel
3. Handle the reboot gap explicitly: mark the host as in-reboot, then resume checks when WinRM answers, and read the post-reboot install result from history. Verify: the reboot no longer reads as a failure or an unknown
4. Remove the RDP dependency from the wave procedure and document RDP as a break-glass tool only. Verify: the runbook and agent config contain no RDP step
5. Run a full Windows wave with monitoring only on the new channel. Verify: completion states match a manual spot check on sample hosts

## Variant phrasings
### monitor windows update without rdp winrm event logs
The replacement-channel phrasing.
### rdp session disconnects during update reboot monitoring lost
The symptom phrasing.
### windows update progress api instead of watching screen
The API phrasing.

Compatibility: Compatibility: Windows hosts with WinRM or a management agent; event log and update history sources are built into Windows.

## Why it happens
Watching a screen is how a human patches one machine. It fails as automation for structural reasons: the session is tied to a user logon, the most important moment of the patch (the reboot) destroys it, and GUI progress is not data. Every fact the screen shows originates in logs and APIs the agent can read directly, more reliably and in parallel across hundreds of hosts.

## Edge cases / pitfalls
- GUI-only installers that truly have no log or silent mode are the exception; isolate them as manual tasks rather than bending the whole wave to RDP.
- Session recordings some compliance regimes require are a separate concern from monitoring; do not let a recording requirement resurrect RDP-driven patching.
- If the RDP drops were caused by the update breaking the network driver, that is a patch defect to log, separate from the monitoring redesign.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HIvw8nhXPs8QcN_e5VsRJg