Why can a Domain Admin run a powershell cmd locally, but connecting over WinRM with the same account, command returns an UnauthorizedAccessException?

The Windows Update API is special. It specifically checks for and disallows remote access by checking if your token is marked as remote. I don't know why it was written this way.

I ended up creating a scheduled task and invoking the windows update API inside that - quite a nuisance.

Depending on exactly how Get-WURebootStatus cmdlet accesses it's information, I think it might be related to the "second-hop" problem in PowerShell.

When you enter a remote PowerShell session, you're asking WinRM to create a session on the remote host using your credentials. If, from that same session, you attempt to access another (remote) system or service that requires those credentials, the request will fail because the remote machine isn't authorized to use your credentials for authentication to anything else. A 'Hey, Scripting Guy!' blog explains this well:

http://blogs.technet.com/b/heyscriptingguy/archive/2012/11/14/enable-powershell-quot-second-hop-quot-functionality-with-credssp.aspx

You would see this same (or similar) issue when, after remoting into a machine and then attempting to access another remote machine share path with Test-Path, for the same reason.

The solution (as is presented in the blog article) is to enable and use CredSSP as the authentication mechanism when creating the PSSession.

You can also wrap the command in a scheduled task and have that run immediately as well, but that is a lot of extra work that could be unnecessary.

Copy from Stack Overflow: Powershell Remote: Microsoft.Update.Session, Access Denied: 0x80070005:

When you are in a remote PowerShell session your logon session on this remote computer is flagged as a "network" logon (Logon Type: 3). For some obscure (security? sell SCCM?) reason, part of the Windows Update Agent COM APIs are restricted to only be usable by locally logged on Administrators.

Using PsExec and Scheduled Tasks have been suggested as workarounds.

IMO, the most seamless (and still secureable) solution is to facilitate the RunAs-style "Local Virtual Account" feature of PowerShell Session Configurations / JEA. Usually, JEA is used to "restrict" what a user can do on a remote computer PowerShell-wise, but we are (ab-)using it here to gain full access as if we were a locally logged on Administrator.

(1.) Create a new unrestricted (and persistent!) session configuration on ComputerB (remote server):

New-PSSessionConfigurationFile -RunAsVirtualAccount -Path .\VirtualAccount.pssc
# Note this will restart the WinRM service:
Register-PSSessionConfiguration -Name 'VirtualAccount' [-ShowSecurityDescriptorUI] -Path .\VirtualAccount.pssc -Force
# Check the Permission property:
Get-PSSessionConfiguration -Name 'VirtualAccount'
# Those users will have full unrestricted access to the system!

(2.) From ComputerA (local client) connect to our unrestricted session configuration on ComputerB:

New-PSSession -ComputerName 'ComputerB' -ConfigurationName 'VirtualAccount' | Enter-PSSession
[ComputerB]: new-object -com "Microsoft.Update.Downloader" # Yay!