I am trying to automate updating Powershell on Windows 7 using Windows6.1-KB2506143-x64.msu, and having a heck of a time. The following code works fine in a standalone ps1 file. And it works in my main ps1 file. But when run from a module it fails with exit code -2145124341. This is in PS v2, where negative exit codes are handled wrong, so that number is perhaps useless, and FWIW I have a good 40 other installers of various types that work from this module. However, this is my first attempt at automating msu files, so maybe there is a known interaction here that I haven't discovered yet? There's thousands of lines of code between the root ps1 file where this works and the module where it doesn't, so tracking down what is triggering the error is going to be a beast without some sort of trail to follow at the very least. So, anyone have an idea where I should start?
$filePath = 'wusa.exe'
$argumentList = '"\\PX_SERVER\Rollouts\Microsoft\Windows6.1-KB2506143-x64.msu" /quiet /norestart'
$exitCode = (Start-Process -filePath:$filePath -argumentList:$argumentList -wait -errorAction:stop -passThru).exitCode
Also, running wusa.exe leaves some detritus in the script folder, but only when it is run from the module. Is this an issue with the msu file, or just a bug in wusa? Or does it point at what is causing the issue perhaps?
I had hoped to get this update to work to enable some new features, but between not being able to automate and garbage being left behind, I am very close to abandoning that path and juts continuing to target v2. But hopefully someone can point me in the right direction as that is not my preferred solution at all.
a few toughts on first reading :
The ArgumentList parameter for Start-process needs an ARRAY to work well :
$argumentList = #( "\\PX_SERVER\Rollouts\Microsoft\Windows6.1-KB2506143-x64.msu", "/quiet", "/norestart" )
wusa.exe takes a log parameter : /log:c:\fso\install.log can you had it to your script for this particular package to check what happens ?
a powershell script trying to update powershell ... I'm not quite sure this is meant to work ... it's the only case in wich i'll backup on another scrpting language (people, please correct me if i'm wrong ... )
Please let me know the result of the wusa.exe /log command, thanks
Related
To preface this, I am self teaching and brand new to scripting in general, let alone powershell.
After a cumulative 12 hours, my Google fu has run out.
I had a series of programs tailored to different models of computer we support that ran a staged series of installers from a fileshare. The program would check to see if the tech deploying the software was running it as admin, if not, it used a Start-Process line to elevate and run again.
It worked flawlessly, but we wanted to see if we could remove the need for the tech to enter r to run the scripts from the share.
In trying to figure out how to add -executionpolicy bypass to the arg list for Start-Process, I've hit a wall.
It now errors on trying to call to the fileshare to retrieve the parent script, before getting to the point where I can troubleshoot the bypass can of worms.
Below is my rough framework, remember I'm self taught by googling and using tutorials point.
$principal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
if($principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
{
#usually I have a get-childitem | foreach-object loop here that runs the files from the folder one by one in a specific order,
#it also checks to see if msiexec is running or not before trying to load and install files using a if-else>do-while combo
}
else
{
Start-Process -FilePath "powershell" -ArgumentList "$('-File "\\server\dir\foo".ps1')$($MyInvocation.MyCommand.Name)$('""')" -Verb runAs
}#this calls to a script that is a 1:1 copy of the code in the if{} block
This returns an error from the -File parameter that says it can't call the file because it doesn't exist.
What am I doing wrong?
How do I pass -executionpolicy bypass as an additional arg without breaking it further?
Is there a better way to do this?
Is there a neater way to automate this?
Please help me geniuses of StackOverflow before I start gnawing on my keyboard.
I'm experiencing a weird scenario where I want to open a .rdp file and get its Process ID on a Jenkins Pipeline.
My PowerShell Script (which based from this answer):
$app = Start-Process "$env:windir\system32\mstsc.exe" -ArgumentList "C:\Users\AzureUser\Desktop\MyRDP.rdp /h:900 /w:1600" -WindowStyle Minimized -PassThru
Write-Host $app.id
When I ran this on PowerShell it works as expected. However, when I tried to execute this script on a Jenkins Pipeline, it opens the .rdp file but returns a different process ID.
Here's the screenshot of the result.
I also tried enclosing it in an Invoke-Command to make sure that it runs on a 64-bit Powershell but it did not change a thing.
I'm wondering what might be the other possible cause of this. Any help is going to be appreciated. :)
The solution is just simple. I will post my answer anyway incase anyone might encounter the same problem I have. You just need to make sure that Jenkins runs on 64-bit. That's all and worked like a charm.
I am using Powershell 7 to install .MSI application with some arguments (same installation with same arguments passed well when using for example Ansible tool).
Every time I try to run script I am getting Windows Installer pop up window which someone mentioned ( someone wrote "This pop up is the msiexec help pop up. It’s telling you it doesn’t like your command line"). I tried several different orders but always getting this failure.
I saw there was similar issue but it was completely different issue with Accepting License Terms, I do not have issue with that.
My arguments are:
$webDeployInstallerFilePath = "C:\fa_components\PRIME\SUN TEST 2020.1 (x64).msi"
$switch2 = #(
"i `"$webDeployInstallerFilePath`""
"/quiet"
"passive"
"/l* C:\tmp_installation\logs\Prime_log.txt"
"INSTALLDIR=C:\"
"FRONTINIDIR=C:\ProgramData\Front\64bit\ini\"
"FRONTINILOG=C:\ProgramData\Front\64bit\log\"
"PRIME=C:\TEST Arena\"
"ProgramMenuFolder=C:\ProgramData\"
"COMMONAPPDATA_FRONTDIR=C:\ProgramData\Front\"
"COMMONAPPDATA_FRONT64BITDIR=C:\ProgramData\Front\64bit\"
"CommonAppDataFolder=C:\ProgramData\"
)
Program requires some of it needed argumets.
I try to execute it with:
Start-Process msiexec.exe -ArgumentList $switch2 -Wait
I try to run my .ps1 script but as I mentioned I am getting only picture with windows installer and nothing happens (you can see that on following link)
windows installer picture
Thanks in advance!
Yes, a few problems.
"i" should be "/i" (note the forward slash)
"passive" should be "/passive" (note the forward slash)
Because it has a space in the path, "PRIME=C:\TEST Arena\" should be "PRIME="C:\TEST Arena\""
Examples here: https://www.alkanesolutions.co.uk/2018/07/18/install-and-uninstall-msi-using-powershell/
$switch2 = #(
"/i `"$webDeployInstallerFilePath`""
"/quiet"
"/passive"
"/l* C:\tmp_installation\logs\Prime_log.txt"
"INSTALLDIR=C:\"
"FRONTINIDIR=C:\ProgramData\Front\64bit\ini\"
"FRONTINILOG=C:\ProgramData\Front\64bit\log\"
"PRIME=`"C:\TEST Arena\`""
"ProgramMenuFolder=C:\ProgramData\"
"COMMONAPPDATA_FRONTDIR=C:\ProgramData\Front\"
"COMMONAPPDATA_FRONT64BITDIR=C:\ProgramData\Front\64bit\"
"CommonAppDataFolder=C:\ProgramData\"
)
I have a powershell Script that runs fine in the ISE, but when I run it directly from the .ps1 file it stops at this point:
Write-Host "Attempting to start FFMPEG Process with arguments:$ArgumentList::::" -ForegroundColor Green
Start-Process $SCRIPT:FFMPEGLocation $ArgumentList -Wait
I get the Write-Host printout, with the correct Argument List, but no window pops up for the start-process or anything. I made sure to use the SCRIPT scope variable for anything that is outside the function. It runs fine in ISE just not when I run it in Console. No errors either, and the $SCRIPT:FFMPEGLocation variable is a direct path to the exe to be executed.
Any help would be greatly appreciated, and if you need more let me know.
PSVersion 5.1.14393.1066
OSVersion 10.0.14393
As per comments, check the value passed to Start-Process to ensure it contains what you expect as the issue is likely to be with $SCRIPT:FFMPEGLocation.
The difference between the ISE and Console with regard to scope can be frustrating.
See this SuperUser post which explains the behaviour further
. You may also find this post helpful;
BartekB explains that F5 in the ISE actually dot-sources the script instead of calling it, and provides a function to run a clean session.
An alternative method which will also wait on the process that needs to be run:
& $EXE /arg 1 /arg 2 -etc 2>&1 | % { $_ }
This will execute the command and pass the args, redirect any errors to the output stream and then print that output (for some reason, I've had bad luck with actually getting output from commands)
Out of sudden, a colleague of mine found a script that runs during the startup of the Windows on his machine, which is found to be a powershell script.
The code is below, what I understood that it only minimizes all windows opened.
powershell -command "& { $x = New-Object -ComObject Shell.Application; $x.minimizeall() }"
I need to know if there is an impact from this code on his machine as to isolate from the network.
It doesn't seem to present a threat in and of itself. If someone is doing something unwanted, it would probably be that they're starting some other program that does something not nice, and this PowerShell command minimizes its window (possibly to the taskbar notification area where it can be hidden) so that you don't see what's going on. But the command itself appears harmless.
It only minimizes all the windows. Except that nothing else. I don't think it is harmful. If someone has kept it in the startup, I believe the reason being some other App is opening window in the startup , so it is trying to avoid that.