Powershell - How to use Start-Process to call file from share/pass args in single line - powershell

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.

Related

Jenkins PowerShell: Start-Process with Passthru returns a different process ID when executed in Jenkins but not on PowerShell

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.

Powershell - run .MSI installation with arguments but Windows Installer pops up and nothing happens

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\"
)

start powershell.exe inside a ps1-script with a predefined variable

so this is my first post here on stackoverflow :-) hm,... would think i operate with powershell as an "experienced beginner", written some nice-working scripts for OS-automation in the last 2 years. no programming-skills, only little bit of scripting to make my life as sysadmin easier.
currently i have a tricky problem - excuse me in case this was already solved in another thread, but didn´t find a solution to it.
here the purpose of the code:
enable a normal windows-user (not member of local admin-group) to execute some scripts with administrative rights.
switch current user to a user with admin-rights >> solved. created a pscredential-object ($pscreds). works good.
start an elevated powershell-session to have the ability to do admin-stuff >> solved. powershell.exe -verb RunAs bla bla. works good.
launch a fix-named script with admin-rights >> solved.
problem itself:
script-name is not always the same one.... i want to enable the code to use the path and name of current running script ($Myinvocation.Mycommand.Definition).
$x = $myinvocation.MyCommand.Definition
Start-Process powershell.exe -Credential $pscreds -ArgumentList {
Start-Process powershell.exe -Verb RunAs -ArgumentList {
start-process powershell.exe -ArgumentList (-file "$x")
}
}
how to modify the code that the variable $x at -file "$x" takes the value defined in first line?
i found a workaround by myself write the path & scriptname to a temp-file and read it back to $x with "get-content". but i didn´t like this ugly solution and hoped solve this in a better way.
thanks for help and best greetings from germany
Ralph
I think that without getting into a whole host of Windows Auth issues doing that inside one script, I'd stick to what you are already talking about as a kludge - Try letting the non-admin edit that $x value in a file they have access to. Then run a script on schedule with an admin account that reads the file.

Create new process or use Start cmdlet in Powershell

I was messing around with a script that I found on the internet that will check to see if you are running the current Powershell console under the Admin role and, if not, start a new instance of Powershell and close the former window.
The part that checks it isn't really the issue, I just have a question on how it starts a new instance of Powershell.
This is how it is performed in the script:
$newProcess = New-Object System.Diagnostics.ProcessStartInfo "Powershell";
$newProcess.Arguments = "& '" + $MyInvocation.MyCommand.Name + "'"
$newProcess.Verb = "runas";
[System.Diagnostics.Process]::Start($newProcess);
Exit;
This is a rather well-known and regularly used script (empirically, it is scattered all over the web in myriad websites).
As most Powershell-savvy folks know, you can bring up Powershell and have it run as Administrator from the command line (within a Run prompt, Command shell, & Powershell) by typing:
Start Powershell -ArgumentList "& '$scriptpath'" -Verb runas
And anyone that is familiar with scripting can see that these will do the exact same thing--they even seem to resemble each other!
Between these two ways of starting a new instance of Powershell and running a called script, what are the differences? Which is recommended and which is not? Is one more correct (appropriate) than the other?
As I am self-taught and I generally learn as I go, best practices, advice, and what is deprecated\superseded is often overlooked.
I don't really have a background in the .NET framework or C#, so, if the answer is obvious from that standpoint, you'll have to forgive me.
Thanks.
Start is an alias for Start-Process, which is basically a wrapper around [System.Diagnostics.Process]::Start (it actually returns a System.Diagnostics.Process object). You can use either of them, but the former is more PoSh since its syntax follows PowerShell conventions.
See also this comprehensive Technet article for an overview of ways to run executables from PowerShell.

wusa silent install error

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