I open PowerShell as admin and use the following line of code to run an offline file for windows updates. It works fine
Start-Process 'wusa.exe' -ArgumentList 'C:\Temp\windows10.0-kb5032189-x64_0a3b690ba3fa6cd69a2b0f989f273cfeadba745f.msu' -verb runas
But now I am trying to somehow use this same code to run the file on remote computers. The windows update file has the same name and the exact location on the remote PCs
I came up with this code below which first gets admin credentials and passes it to the the invoke-command. Then the invoke-command runs the Start-Process code.
$Username = 'username123'
$Password = '84fWfghnsf&5Fh'
$pass = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $Username,$pass
Invoke-Command -ComputerName 8HPF31J7V6.domain.local -Credential $Cred -ScriptBlock {Start-Process 'wusa.exe' -ArgumentList 'C:\Temp\windows10.0-kb5032189-x64_0a3b690ba3fa6cd69a2b0f989f273cfeadba745f.msu' -verb runas}
Problem is, when I do this, nothing happens on the remote PC
I also don't get any errors when running
Any ideas on what I am doing wrong, or any other solutions besides this?

Add
-Waitto your remoteStart-Processcall to ensure thatwusa.exeruns to completion before returning from the remoteInvoke-Commandcall.-ComputerNameparameter, theStart-Process-launched process is automatically terminated when theInvoke-Commandcall returns.Code executed via PowerShell's remoting runs invisibly on the target machines, so the use of
-Verb RunAsis pointless:If the remote process already is elevated, it has no effect. Note that remote processes are automatically elevated if the user identity running the remote command is an administrator on the target machine.
If it isn't (this would only happen if you explicitly gave non-administrative users permission to use PowerShell remoting), the call invariably fails, because no UAC dialog can be presented.
Caveat:
While the information below in this answer is correct in principle, js2010 notes that in order to successfully run
wusa.exeremotely, i.e. in order to install Windows Updates, running in an implicitly elevated remote session alone may not be sufficient.This ServerFault answer provides background information, and third-party module
PSWindowsUpdatemay provide a solution, if used with its scheduling features.Therefore, with synchronous execution:
Read on for an asynchronous alternative. Note that the
(Start-Process -PassThru …).ExitCodetechnique shown below, for reporting the remote process' exit code, can equally be used with the synchronous approach above.Asynchronous execution:
If you don't want the
Invoke-Commandcall to wait for the remotely launched process (wusa.exe) to terminate, you have two options:In the simplest case, add the
-AsJobswitch to the call above, which makesInvoke-Commandreturn a job object that can be queried for output and completion later, on demand, withReceive-JobandWait-Job, as shown below.Create a remote session explicitly, via
New-PSSession, and pass it toInvoke-Command's-Sessionparameter. Such a session stays open until it is either explicitly removed withRemove-PSSessionor times out due to inactivity.-WaitwithStart-Process, and track the lifetime of the process in the remote session, by adding-PassThruto output a process-information object that you must capture in a variable, and consult again in a laterInvoke-Commandcall with the same-Sessionargument.Asynchronous variant with
-AsJob, which additionally demonstrates how to report the remote process' exit code: