When you execute commands remotely they are run with administrative privileges because only administrators are permitted to remotely execute commands in powershell. The error, "Exception calling "CreateUpdateDownloader" with "0" argument(s): "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"" is not a native powershell error, it indicates that this line is failing:
$UpdatesDownloader = $UpdateSession.CreateUpdateDownloader(), this line is trying to create the updatedownloader object using the
$UpdateSession = New-Object -ComObject Microsoft.Update.Session object.
Without knowing WHERE the downloader tries to reach out to, I can only assume the mothership, it may indicate that credentials you have while remotely connected to a server could be the subject of a proxy. This is a common security practice, users remotely connected to machines cannot download items directly from the internet (no matter how trusted the source).
Hope this helps,
Chris
Finally solved it, helped by the evidence I recently added to the question:
netsh http show iplist
IP addresses present in the IP listen list:
-------------------------------------------
127.0.0.1
On systems where this was working, that list was empty. This seemed rather counter-intuitive to me at first. Nevertheless, I gave this a go:
> netsh http delete iplisten ipaddress=127.0.0.1
Immediately after, I notice this output from netstat
:
>netstat -anp tcp
Active Connections
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49175 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49179 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49190 0.0.0.0:0 LISTENING
TCP 10.115.63.107:139 0.0.0.0:0 LISTENING
TCP 10.115.63.107:3389 10.115.13.25:64873 ESTABLISHED
TCP 10.115.63.107:49235 192.168.40.146:445 ESTABLISHED
TCP 10.115.63.107:49291 192.168.40.45:8014 ESTABLISHED
TCP 169.254.34.30:139 0.0.0.0:0 LISTENING
And indeed, WinRM works like it should.
I surmise, via testing, that if no HTTP listener is configured, then all HTTP listeners will bind to the default entity: 0.0.0.0
. Because a loopback address was configured as a listener address, the listener was binding to this address instead.
At some point, I must have taken some action that caused this configuration, though I'm not sure how. At any rate, it's working fine now. Thanks all.
Best Answer
First thing that pops in my head: is cmd elevated? It would be by default on local Administrator account, not so with domain accounts that belong to local Administrators group. Your current prompt (c:\users...) kind of suggests this might be the reason for access rights issues (elevated cmd starts in c:\windows\system32 by default).
I've tested both elevated and non-elevated and get same results as you do with "normal" and expected results with "elevated" one.