Powershell Remote: Microsoft.Update.Session, Access Denied: 0x80070005

5

I've written a script to search/download/install Windows Updates on a machine using the Microsoft.Update.Session COM Object. When run locally it works just fine, however when running through a remote session or through Invoke-Command I receive an access denied (0x80070005) error on Microsoft.Update.Session.CreateUpdateDownloader()

I receive the same error if I attempt to create a Downloader object directly, code to reproduce the issue:

$oUpdateDownloader = new-object -com "Microsoft.Update.Downloader" 

I am an administrator on the remote machine, and passing credentials (for myself explicitly or any other admin account) to the machine does not seem to change anything.

I've seen this error posted a number of times but there does not seem to be any information on solving the problem...

Any ideas?

com
powershell
asked on Stack Overflow Aug 16, 2011 by klyd

5 Answers

3

This is a known issue. It appears that there is a bug with the actual COM object itself, as this issue occurs when using VBScript, PowerShell, and even C#. There is a good article that discusses managing Windows Update with PowerShell that can be found here.

The workaround is to set up a scheduled task on the computer and you can invoke that task however you see fit.

answered on Stack Overflow Aug 16, 2011 by Andy Schneider
2

Use PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) to remotely execute PowerShell with a script file:

psexec -s \\remote-server-name C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe \\server\script.ps1

I used the script detailed at http://www.ehow.com/how_8724332_use-powershell-run-windows-updates.html, and I can remotely execute it using psexec to download and install updates.

answered on Stack Overflow Sep 3, 2013 by Alan Bridgewater • edited Sep 3, 2013 by Keith Thompson
1

the windows update code isn't callable form a remote machine. there are a few workarounds out on the web, including using psexec and a script (powershell or vbscript).

I used WUInstall myself and BoeProx has documented a few alternatives and has started a project PoshPAIG. I moved jobs before using this so don't know if it works.

answered on Stack Overflow Aug 16, 2011 by Matt
0

The other solution is to change Windows registry setting using PowerShell and optionally restart wuauserv for the changes to take effect.

For example in Windows Server 2008R2 AutoUpdate settings can be found at:

HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update
answered on Stack Overflow Jun 7, 2013 by sha
0

When you are in a remote PowerShell session your logon session on this remote computer is flagged as a "network" logon (Logon Type: 3). For some obscure (security?) reason, part of the Windows Update Agent COM APIs are restricted to only be usable by locally logged on Administrators.

Using PsExec and Scheduled Tasks have been suggested as workarounds.

IMO, the most seamless (and still secureable) solution is to facilitate the RunAs-style "Local Virtual Account" feature of PowerShell Session Configurations / JEA. Usually, JEA is used to "restrict" what a user can do on a remote computer PowerShell-wise, but we are (ab-)using it here to gain full access as if we were a locally logged on Administrator.

(1.) Create a new unrestricted (and persistent!) session configuration on ComputerB (remote server):

New-PSSessionConfigurationFile -RunAsVirtualAccount -Path .\VirtualAccount.pssc
# Note this will restart the WinRM service:
Register-PSSessionConfiguration -Name 'VirtualAccount' [-ShowSecurityDescriptorUI] -Path .\VirtualAccount.pssc -Force
# Check the Permission property:
Get-PSSessionConfiguration -Name 'VirtualAccount'
# Those users will have full unrestricted access to the system!

(2.) From ComputerA (local client) connect to our unrestricted session configuration on ComputerB:

New-PSSession -ComputerName 'ComputerB' -ConfigurationName 'VirtualAccount' | Enter-PSSession
[ComputerB]: new-object -com "Microsoft.Update.Downloader" # Yay!
answered on Stack Overflow Feb 3, 2020 by argonym • edited Feb 3, 2020 by argonym

User contributions licensed under CC BY-SA 3.0