Home / server / Questions / 336705
In Process
reconbot
Asked: 2011-12-02 09:02:23 +0800 CST

Issues with patching servers remotely using winrm and Microsoft.Update.Session

  • 772

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
 (E_ACCESSDENIED))"
    + 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?

windows-server-2008 windows-server-2003 powershell windows-update winrm

3 Answers

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

    • 6

  2. 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 ""
    • 0

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

    • 0