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"
  • 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
  • 1
    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

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.

  • 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.

  • 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

Try using Get-WURebootStatus -ComputerName <your remote computer> -Silent.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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