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

7

11

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?

Uke answered 16/8, 2011 at 13:30 Comment(1)
What's the updated code? can you share it here please @UkeSirajuddaula
S
5

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.

Slusher answered 16/8, 2011 at 14:52 Comment(2)
I'd understood it was by design as a security "feature" - wondering if i was being a little gullible now!Codel
feature / bug ... its all relative :)Slusher
M
8

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? sell SCCM?) 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!
Manard answered 3/2, 2020 at 19:41 Comment(2)
Double hop don't seem to work with JEA VirtualAccount, so downloading patches will not be possible.Hearth
This not the classical double hop, where your initial connecting account is also used to connect to the final target server (Microsoft download or WSUS in this case). Instead, you impersonate the Local Virtual Account on ComputerB and should thus show up with the computer account on the final target server.Manard
S
5

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.

Slusher answered 16/8, 2011 at 14:52 Comment(2)
I'd understood it was by design as a security "feature" - wondering if i was being a little gullible now!Codel
feature / bug ... its all relative :)Slusher
M
4

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.

Moskowitz answered 3/9, 2013 at 0:42 Comment(1)
Using psexec might be considered a security risk and is flagged by some security solutions.Hearth
C
2

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.

Codel answered 16/8, 2011 at 14:53 Comment(0)
T
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
Timi answered 7/6, 2013 at 21:30 Comment(1)
What will this change do?Hearth
H
0

Thanks to argonym and questioner: I made the script based on the solution argonym gave, with a little chage that worked for me to use it from a script file and not command prompt:

$script = {
            write-host "Hello from remote target"
            #filepath is in Remote/target host
            $job = Start-job -FilePath c:\Windows_Update_2.ps1 -Verbose -Credential $cred
            echo $job
            Wait-Job $job
            $output = Receive-Job $Job
            foreach ($item in $output){
                              write-host $item
                                }
            }


$session = New-PSSession -ComputerName $computerName -Credential $cred  -ConfigurationName 'VirtualAccount' 
Invoke-Command -Session $session  -ScriptBlock $script

the complete example to run it is here: script example on github

Hawk answered 13/6, 2023 at 9:4 Comment(1)
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From ReviewDeterrence
D
0

An example using the task scheduler to get around access denied over remote powershell, using a script that uses the Microsoft.Update.Installer object like the windows_update_2.ps1 one on github. This could take over 30 minutes.

# windowsUpdateRun.ps1

# windows_update_2.ps1 copied to remote machine first
# $s = new-pssession (1..3 | % tostring comp000)
# $s | % { copy windows_update_2.ps1 $home\documents -tosession $_ } 

$taskname = 'windowsUpdateRun'

$action = New-ScheduledTaskAction -Execute powershell -argument "-executionpolicy bypass $home\documents\windows_update_2.ps1 *> $home\documents\windows_update_2.log"
Register-ScheduledTask -action $action -taskname $taskname -user system -force > $null
Start-ScheduledTask -TaskName $taskname
while ((Get-ScheduledTask -TaskName $taskname).State -ne 'Ready') {
  Write-Verbose -Message 'Waiting on scheduled task...' }
Get-ScheduledTask $taskname | Get-ScheduledTaskInfo | select LastTaskResult
$s = new-pssession (1..3 | % tostring comp000)
$s | % { copy windows_update_2.ps1 $home\documents -tosession $_ } 
invoke-command $s windowsUpdateRun.ps1
Demolish answered 14/8, 2023 at 20:27 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.