Topic starter
24/10/2026 8:48 pm
TL;DR: Direct PowerShell remoting to the Windows Update Agent COM API fails because the API expects a local interactive context, so remote patching needs an indirect job-based pattern instead, according to Action1 research. For IAM and PAM teams, the governance issue is not patching itself but how delegated admin rights and scheduled execution can expand lateral-movement risk.
Editorial analysis by NHI Mgmt Group, based on content published by Action1: “Update Windows Remote with WinPSWindowsUpdate Remote Computer”.
Key questions
Q: What breaks when Windows Update is called remotely through the COM API?
A: The call fails because the Windows Update Agent COM API expects a local interactive context, while remoting supplies a network logon.
Q: Why does remote patching create privilege risk for Windows administrators?
A: Remote patching often relies on broad administrative credentials or on the ability to create SYSTEM-level scheduled tasks across many hosts.
Q: What do security teams get wrong about patching when exploit development is automated?
A: They often assume that the absence of public exploit activity means there is time to wait.
Practitioner guidance
- Restrict remote task creation rights Treat the ability to use Invoke-WUJob as privileged access because it creates a SYSTEM-level scheduled task on a remote host.
- Use delegated or just-in-time admin access Replace broad reusable administrator accounts with delegated or just-in-time permissions for patch jobs so a compromised management account cannot fan out across the estate in one step.
- Log every remote patch job Capture update output, job state, and failure details to a log file or central audit store so patch runs can be reviewed after execution and retried only where needed.
Bottom line: Remote Windows patching is blocked by an execution-context mismatch, not by PowerShell itself.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →