Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to administer a Windows 7 machine remotely. I've enabled WinRM and can use Enter-PsSession to connect to the remote machine.

However, I'm noticing a difference between running a particular command locally, vs running it remotely, even though I'm connecting with the same user account (which is a Domain Admin).

The output from the remote session is:

> enter-pssession -computername  REMOTEHOST
[REMOTEHOST} > Get-WURebootStatus
New-Object : Creating an instance of the COM component with CLSID {C01B9BA0-BEA7-41BA-B604-D0A36F469133} from the IClassFactory failed due to the following error: 80070005.
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\pswindowsupdate\Get-WURebootStatus.ps1:52 char:33
+             $objSystemInfo= New-Object <<<<  -ComObject "Microsoft.Update.SystemInfo"
+ CategoryInfo          : NotSpecified: (:) [New-Object], UnauthorizedAccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.NewObjectCommand

ExecutionPolicy is set to 'Unrestricted', and this command works great when I'm using a local powershell session on the remote machine.

Is there a different security context for remote powershell sessions?

edit: the specific line it's failing on is this one:

$objSystemInfo= New-Object -ComObject "Microsoft.Update.SystemInfo"
share|improve this question
Could it be UAC? – HopelessN00b Mar 28 '13 at 12:16
Even though the account is a domain admin? – growse Mar 28 '13 at 12:26
Yes, the UAC prompt (well, the way Windows Vista and up use split-token authentication for administrator accounts, to be technical) interferes with domain admins just like it does with local admins. – HopelessN00b Mar 28 '13 at 12:53
Did you enabled: winrm set winrm/config/winrs @{AllowRemoteShellAccess="True"} – timmeyh Mar 28 '13 at 13:01
I've enabled RemoteShellAccess via GPO, and I still see the same result. – growse Mar 28 '13 at 13:20
up vote 2 down vote accepted

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.

share|improve this answer
I think this might have to be the way forward. – growse Apr 3 '13 at 8:52

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:

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.

share|improve this answer
edit spoke too soon. Get-WUList gives a sane result, but running Get-WUInstall or Get-WURebootStatus still throw a 0x80070005 'access denied' error. – growse Apr 4 '13 at 9:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.