Use Powershell to install windows Patches - powershell

I already tried alot of tips on Stackoverflow, but nothing seems to work.
If I run this Code a Window Pops up.
The PowerShell Version is 2.0
My Code:
$PATH = "S:\User\Person\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu"
$SB = {Start-Process -FilePath 'c:\windows\system32\wusa.exe' -ArgumentList ('S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu','/quiet', '/promtrestart', "/log:S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\Update.log") -Wait}
$computer = echo (Get-WmiObject -Class Win32_ComputerSystem -Property Name).Name
Invoke-Command -ScriptBlock $SB

First off, E.D. (hehe) is correct about your spelling error. A simple syntax error can break even the most otherwise elegant/complex scripts.
You're going to a lot of additional trouble to install patches from what I'm assuming is a (remote) mapped drive. If you're trying to do this on other machines, you'll want to use something like psexec or a scheduled task to kick off the install under the machines' credentials (NT Authority\System). If you're doing this on your machine and FOR your machine.
Picking your code apart:
$PATH = "S:\User\Person\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu"
$SB = {Start-Process -FilePath 'c:\windows\system32\wusa.exe' -ArgumentList ('S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\AMD64-all-windows6.1-kb3134760-x64_d720851ef4b5a37c1c8bdd2e5bf4c77dcc625e8c.msu','/quiet', '/promtrestart', "/log:S:\User\Voss\UPDATES\Update for Windows 7 for x64-based Systems (KB3134760)\Update.log") -Wait}
$computer = echo (Get-WmiObject -Class Win32_ComputerSystem -Property Name).Name
Invoke-Command -ScriptBlock $SB
1) I don't really understand what you're doing with the $PATH variable as it isn't referenced anywhere else.
2) $SB doesn't 'REALLY' need to be delimited that way, but should work. Normally, I would just make it a single string and, when referencing other variables, utilize this syntax to get them to be evaluated first - $($PATH)
3) for $computer, you're kind of right. Lose the echo and you should be fine since you're just getting the name of the local machine ( $Env:ComputerName would work just as well and be more economical even if you're running the code on another machine, IMHO )
Addressing the use case where you might be running this code on another machine:
You seem to be assuming that you are logged on and your drive mapping is applicable. If you're accessing a network share, you'd want to make sure the remote machine has read permissions to the share so it could get to the file(s) in question and you'll also want to use the UNC path for simplicity's sake. This is a situation where psexec \ -S WUSA \UNC PATH\To\Update\File.msu would be best utilized.
Bottom line, if you'd communicate what your intent is a bit better, I might be better able to assist.

Related

[System.IO.Path]::GetTempPath() outputs local temp directory when called through Invoke-Command on a remote machine

I'm running PowerShell commands on a remote machine by the use of Invoke-Command -ComputerName. I'm trying to obtain the path of the temporary directory of the remote machine.
Depending on where I call [System.IO.Path]::GetTempPath() it either outputs the expected remote directory C:\Users\…\AppData\Local\Temp or my local temporary directory C:\temp.
This command is not working as expected:
Invoke-Command -ComputerName MyRemoteMachine -ScriptBlock {
Write-Output ([System.IO.Path]::GetTempPath())
}
# Outputs local directory 'C:\temp'
# Expected remote directory 'C:\Users\…\AppData\Local\Temp'
The problem can be reproduced with other commands than Write-Output, e. g. Join-Path.
Contrary, the following code samples all give the expected output of C:\Users\…\AppData\Local\Temp.
Invoke-Command -ComputerName MyRemoteMachine -ScriptBlock {
[System.IO.Path]::GetTempPath()
}
Invoke-Command -ComputerName MyRemoteMachine -ScriptBlock {
$tmp = [System.IO.Path]::GetTempPath(); Write-Output $tmp
}
Invoke-Command -ComputerName MyRemoteMachine -ScriptBlock {
Start-Sleep 1
Write-Output ([System.IO.Path]::GetTempPath())
}
Invoke-Command -ComputerName MyRemoteMachine -ScriptBlock {
Write-Output ([System.IO.Path]::GetTempPath())
Start-Sleep 1
}
Obviously Start-Sleep isn't a solution, but it seems to indicate some kind of timing problem.
Suspecting that the problem isn't limited to GetTempPath() I tried another user-related .NET API, which also unexpectedly outputs my local folder instead of the remote one:
Invoke-Command -ComputerName MyRemoteMachine -ScriptBlock {
Write-Output ([System.Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments))
}
How can I use [System.IO.Path]::GetTempPath() and other .NET API in a PowerShell remote session in a predictable way?
Santiago Squarzon has found the relevant bug report:
GitHub issue #14511
The issue equally affects Enter-PSSession.
While a decision was made to fix the problem, that fix hasn't yet been made as of PowerShell 7.3.1 - and given that the legacy PowerShell edition, Windows PowerShell (versions up to v5.1, the latest and final version) will see security-critical fixes only, the fix will likely never be implemented there.
While the linked bug report talks about the behavior originally having been by (questionable) design, the fact that it only surfaces in very narrow circumstances (see below) implies that at the very least that original design intent's implementation was faulty.
The problem seems to be specific to a script block with the following characteristics:
containing a single statement
that is a cmdlet call (possibly with additional pipeline segments)
whose arguments involve .NET method calls, which are then unexpectedly performed on the caller's side.
Workaround:
Make sure that your remotely executing script block contains more than one statement.
A simple way to add a no-op dummy statement is to use $null++:
# This makes [System.IO.Path]::GetTempPath() *locally* report
# 'C:\temp\'
# *Remotely*, the *original* value should be in effect, even when targeting the
# same machine (given that the env. var. modification is process-local).
$env:TMP = 'C:\temp'
Invoke-Command -ComputerName MyRemoteMachine -ScriptBlock {
Write-Output ([System.IO.Path]::GetTempPath()); $null++ # <- dummy statement.
}
Other workarounds are possible too, such as enclosing the cmdlet call in (...) or inserting a dummy variable assignment
(Write-Output ($unused = [System.IO.Path]::GetTempPath()))
Your Start-Sleep workaround happened to work because by definition it too added another statement; but what that statement is doesn't matter, and there's no timing component to the bug.

Continue powershell script execution even if a reboot is encountered

All,
I am trying to write a script that updates a program on a remote machine, however the upgrade requires one or maybe two reboots. When i run the powershell script, it triggers the upgrade and the machine is rebooted once, post reboot the upgrade doesn't resume unless any user account logs in to the machine; post a user login the upgrade automatically resumes and the upgrade process triggers another reboot post which the upgrade is complete.
Is there a way to achieve this? Below is what i am trying.
Invoke-Command -ComputerName $name -ScriptBlock { Unblock-File 'C:\temp\Install\VDAServerSetup_1912.exe'; Start-Process -FilePath C:\temp\Install\VDAServerSetup_1912.exe -ArgumentList '/components VDA', /disableexperiencemetrics, /enable_hdx_ports, /enable_hdx_udp_ports, /enable_real_time_transport, /enable_remote_assistance, '/includeadditional "Citrix Personalization for App-V - VDA"','/exclude "Personal vDisk","Machine Identity Service"', '/includeadditional "Citrix Personalization for App-V - VDA"', '/logpath "c:\becnet\xenapp"', /masterimage, /quiet, /virtualmachine, /disableexperiencemetrics, /optimize, /virtualmachine -wait}
I removed the copy code as that part works fine. The problem i face is that once the above code is triggered on the remote machine, the machine reboots as a part of the upgrade, but once the machine is back up, the upgrade gets stuck unless someone logs on to the machine. Is there a way this can be achieved unattended?
As pointed by Larry below, i had success with the Autologon enabled, however i would like to use that method as the last resort, Is there any other way this can be achieved?
You haven't quoted arguments properly. And the c$ is a typo. Here's the fixed code:
Copy-Item -Path $Source_vda_path -Destination "\\$($name)\C:\$($temp)\Install\VDAServerSetup_1912.exe" -Force
Invoke-Command -ComputerName $name -ScriptBlock "{ & Unblock-File 'C:\temp\Install\VDAServerSetup_1912.exe'; Start-Process -FilePath 'C:\temp\Install\VDAServerSetup_1912.exe' -ArgumentList '/components VDA', '/disableexperiencemetrics', '/enable_hdx_ports', '/enable_hdx_udp_ports', '/enable_real_time_transport', '/enable_remote_assistance', '/includeadditional "Citrix Personalization for App-V - VDA"','/exclude "Personal vDisk","Machine Identity Service"', '/includeadditional "Citrix Personalization for App-V - VDA"', '/logpath "c:\becnet\xenapp"', '/masterimage', '/quiet', '/virtualmachine', '/disableexperiencemetrics', '/optimize', '/virtualmachine', -wait}"

How to start a process on remote computer using powershell WMI?

We are upgrading our servers and need to stop our application before we perform update and then start it back again.
I was reading online about this and most of the links talk about remoting but some of the machines don't have PSRemoting enabled and therefore I need to stick to using wmi.
Would appreciate some pointers on this ?
To terminate the process I am using something like below:
$processes=Get-WmiObject -Class Win32_Process -ComputerName $Address -Filter "name='$ProcessName'"
foreach ($process in $processes)
{
$returnval = $process.terminate()
$processid = $process.handle
if($returnval.returnvalue -eq 0) {
write-host "The process $ProcessName `($processid`) terminated successfully"
}
else {
write-host "The process $ProcessName `($processid`) termination has some problems"
}
}
You don't say what OS and PS version(s) you are trying to deal with.
You are not saying what or if you are having issues with what you posted.
Even using only WMI, you still must have Windows WMI properly configured to do this as well as know Windows is not out of the boxed configured to let you what you are after without making all the proper WinRM, WMI and firewall manual configs.
It's far simpler just to enable PSRemoting via GPO.
Otherwise, you will need tp look toward maybe winrs.exe or MS SysInternals psexec.
winrs
Windows remote Management allows you to manage and execute programs remotely.
PsExec v2.2
Also back to my what OS and PowerShell version you are using. There is the
Invoke-Wmi​Method
Which can lead to stuff like this ---
Invoke-WmiMethod -ComputerName $TargetMachine -Namespace root\cimv2 -Class Win32_Process..."

Get status of service on a remote server

I need to find the status of a service on a remote computer. Though I can use the following command:
Write-Host (Get-Service -ComputerName "remoteServerName" -Name "serviceName").Status
which would give me correct status of service. However I have PowerShell 1.0 installed on the server where i need to run this script. -ComputerName parameter doesn't work for PowerShell 1.0. Currently I'm not supposed to install higher version of PowerShell.
Any idea how to get the status of a service in PowerShell 1.0?
First and foremost (and I can't stress this point enough): If the operating system supports it you should upgrade to at least PowerShell v2.0. No exception. If the system doesn't support PowerShell 2 or newer it's already out of support and should have been replaced/upgraded months ago.
With that said, you can use either WMI (as suggested by #vonPryz):
Get-WmiObject -Computer 'remoteServerName' -Class Win32_Service -Filter "DisplayName='ServiceName'"
or sc.exe (as suggested by #Kayasax):
& sc.exe \\remoteServerName query 'ServiceName'
Of these two WMI is the more PoSh approach, as it doesn't require parsing text output.

Second hop authentication in vmware vco workflow

I'm writing a flow that suppose to copy files from the Netapp storage to one of my VMs, but i have a problem regarding Second Hop authentication.
I found a way to enable a second hop functionality using powershell -CredSSP, but that option does not exist in vco powershell plugin
Are any other way to do that? Or some way to enable cressp in the plugin..
Thanks =)
One workaround that I've used is to deceive the second hop by not using the second hop. First I copy the files that I want each computer to run to the local computer before remoting and running the command. You can accomplish this by using Windows administrative shares. By default, Windows shares their local drives (\\ComputerName\c$ or \\ComputerName\e$). So my script sorta went like this:
$Computers = Get-Content Computerlist.txt
$File = \\Server1\applications$\file.exe
foreach($Computer in $Computers){
copy $file "\\$Computer\c$"
invoke-command -ComputerName $Computer -ScriptBlock {& 'C:\file.exe'}
del "\\$Computer\c$\file.exe"
}