I have a network with windows 2003, 2008 and 2008r2 servers. I have a powershell script that I wrote to patch a local machine using the "Microsoft.Update" com objects. (Similar to Windows Update PowerShell Remoting.) My script works wonderfully locally but I'd like to use it's functions remotely as I have a fair number of servers to manage. In that case it falls down (similarly to that other post, which wasn't solved).

I was however able to narrow the failure down to two methods on a particular class.

(New-Object -ComObject "Microsoft.Update.Session").CreateUpdateDownloader()
(New-Object -ComObject "Microsoft.Update.Session").CreateUpdateInstaller()

If you run these in a powershell locally as an admin, you'll have no issues. If you try to use invoke-command (or enter-session, or winrs) you'll get the following error. (This is testing with localhost, but any host will do. I've also tried with different authentication methods such as credssp and kerberos.);

PS C:\> Invoke-Command -ComputerName localhost -ScriptBlock { (New-Object -ComObject "microsoft.update.session").createUpdateDownloader()}
Exception calling "CreateUpdateDownloader" with "0" argument(s): "Access is denied. (Exception from HRESULT: 0x80070005
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ComMethodTargetInvocation

I've seen this mentioned on blogs as a bug, but with no backup to that claim. Two workarounds exist and both don't make me happy.

  • Use psexec to run commands as the system user. PSExec is what I'm trying not to use as it has proven unreliable. I'd also like a pure powershell solution.
  • Create a scheduled task and tell that to run your script as the system user. (via this post) This is not only messy but then I wont have the update results. I'll have to log to a file or update a database or something.

I'm open to other ways to run updates on a host remotely as this seems to be an issue a lot of people are hitting.

I found some docs that explains the message but not the reason or workaround.

Return Value Returns S_OK if successful. Otherwise, returns a COM or Windows error code.

This method can also return the following error codes.
Return code   Description
E_INVALIDARGA parameter value is invalid. 
E_ACCESSDENIED    This method cannot be called from a remote computer.

How does it know I'm on a remote computer?

  • This does seem a lot more complex than standing up a WSUS instance and going that route. Have you considered that route? Dec 1, 2011 at 19:32
  • You can't control exactly when a server will be bought down and ensure that it will come back up with WSUS alone. We do leverage it for the updates themselves. I'd be interested if you can trigger it to do it's thing on demand.
    – reconbot
    Dec 2, 2011 at 16:45
  • I have the same problem using PowerShell Web Access on Server 2012, behind the scenes it also uses PowerShell remoting. Same error. Mar 2, 2013 at 15:30
  • 1
    Possible answer here serverfault.com/a/474031/23300
    – Nic
    Aug 18, 2013 at 15:46
  • @reconbot i know its very old question but i am also facing issue. Did you got any fix or alternate way?
    – Roxx
    Dec 3, 2015 at 18:26

3 Answers 3


You just cannot do it mate, be cause MS doesn't allow you to do it via WUApi.

Details can be found here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa387288(v=vs.85).aspx

You can try to use Scheduled task to get this done.


Such a command need to be run with privileges on the remote machine, whence the need to be run as a domain admin user or a admin on the remote machine.

If yours is the first case, I have no help, but you are only local admin, not remote, use get-credential like this.

$cred = get-credential

Invoke-Command -ComputerName localhost -credential $cred -scriptblock {}

An alternate and more direct form is let Invoke-Command ask for credentials:

Invoke-Command -scriptblock {$ENV:username} -Credential ""
  • I am running with the credentials of an admin account, the error specifies "This method cannot be called from a remote computer."
    – reconbot
    Jan 26, 2012 at 15:39

I was able to get this working by setting up a JEA endpoint on the remote server to run as a local virtual account.

From https://docs.microsoft.com/en-us/powershell/jea/session-configurations:

Local Virtual Account

If the roles supported by this JEA endpoint are all used to manage the local machine, and a local administrator account is sufficient to run the commands succesfully, you should configure JEA to use a local virtual account. Virtual accounts are temporary accounts that are unique to a specific user and only last for the duration of their PowerShell session. On a member server or workstation, virtual accounts belong to the local computer's Administrators group, and have access to most system resources. On an Active Directory Domain Controller, virtual accounts belong to the domain's Domain Admins group.

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.