The 'Invoke-CUMonitorUpdate' cmdlet works perfectly when run locally in an interactive PowerShell session, but consistently times out after ~5 minutes in remote or non-interactive execution contexts – even though the Monitor update completes successfully in the background.

Root cause: The WCF-over-Named-Pipes validation at the end fails due to Windows security restrictions for delegated "NETWORK USER" tokens.

Impact:
- Automation scenarios cannot reliably detect actual success

- False-positive error codes trigger unnecessary rollbacks/retries

- Current workaround: Ignore return code + add separate status check

Proposed Solution:
Extend cmdlet logic with a remote-friendly validation path:
1. Primary: WCF Named Pipe (current behavior, for local sessions)
2. Fallback: Alternative status check (e.g., direct log/DB query, REST API, or net.tcp transport) when Named Pipe fails

Optional Parameters for powershell:
-ValidationMode (Local|Remote|Auto) # Auto detects execution context
-ForceRemoteValidation # Skip Named Pipe entirely

Benefits:
Clean integration into automation without workarounds; return code accurately reflects actual update success regardless of execution context.

Thank you!