I want to run a script from a USB drive that installs software on the computer the script is run on.
The problem is one of my programs is on the USB drive itself, but the drive letter changes on every computer I plug it into so the path for the file also changes.
Is there a way I can get the script to check what drive letter the USB drive has been assigned?
$out = "Z:\Pc\Powershell Script for maskiner utenfor domenet\Software\SMART.msi"
Start-Process -filePath "msiexec.exe" -ArgumentList "/i $out /quiet /norestart /l c:\SMARTinstallog.txt"
If you have PSv3+ you can use $PSScriptRoot as this contains the fully-qualified path to the directory that contains the script file.
If your script and software locations were:
Z:\Pc\Powershell Script for maskiner utenfor domenet\script.ps1
Z:\Pc\Powershell Script for maskiner utenfor domenet\Software\SMART.msi
$PSScriptRoot would be Z:\Pc\Powershell Script for maskiner utenfor domenet as this is the root folder for the script.
Using this your command would be:
$out = "$PSScriptRoot\Software\SMART.msi"
Start-Process -filePath "msiexec.exe" -ArgumentList "/i $out /quiet /norestart /l c:\SMARTinstallog.txt"
Related
I am trying to run a batch file from remote computer but it also doesn't work locally
Invoke-Command -ComputerName $remoteComputer -ScriptBlock {
Start-Process "C:\Users\Administrator\Desktop\version\Installer\Installer.bat" -NoNewWindow -Wait
} -Credential $credentials -ErrorAction Stop
There is no errors but nothing happens
The installer.bat is located under C:\Users\Administrator\Desktop\version\Installer
The batch file contain setup.exe that also located at the same folder.
I am searching for hours the solution
For local I used this:
Start-Process "cmd.exe" "/c C:\Users\Administrator\Desktop\version\Installer\Installer.bat" -NoNewWindow
Seems that its working locally when i am going to the right folder (cd c:..)
and run
Invoke-Expression -Command 'cmd.exe /C C:\Users\Administrator\Desktop\version\Installer\Installer.bat'
So how can i do it remotely (I mean to go to the right path first)
When I enter the command
Start-Process powershell -WorkingDirectory "D:\folder"
it opens new PowerShell window with D:\folder location set.
But when I enter the command
Start-Process powershell -WorkingDirectory "D:\folder" -Verb RunAs
it opens new PowerShell window with admin rights but with C:\Windows\system32 location set.
How can I open new PowerShell window with admin rights and my own location determined?
I also had the same problem and solved it with this command:
Start-Process powershell.exe -verb runAs -ArgumentList '-NoExit', '-Command', 'cd D:\folder'
Once you run the above command, Windows will launch with admin authority and the specified directory.
Here's another example which can be used for opening CMD from PowerShell as an administrator into the current folder:
Start-Process cmd -ArgumentList ("/k cd {0}" -f (Get-Location).path) -Verb RunAs
if used within a script you can use
Start-Process cmd -ArgumentList ("/k cd {0}" -f $PSScriptRoot) -Verb RunAs
If you want to open a new elevated PowerShell session from the current one which is not elevated you can use:
Start-Process powershell.exe -ArgumentList ("-NoExit",("cd {0}" -f (Get-Location).path)) -Verb RunAs
or
Start-Process powershell.exe -ArgumentList ("-NoExit",("cd {0}" -f $PSScriptRoot)) -Verb RunAs
when used inside scripts
When using Start-Process with -Verb RunAs, a -WorkingDirectory argument is honored if the target executable is a .NET executable; examples:
pwsh.exe (the PowerShell (Core) CLI) does honor it.
cmd.exe and, curiously, powershell.exe (the Windows PowerShell CLI) do not, and invariably use C:\Windows\System32.
The problem exists at the level of the .NET API that PowerShell uses behind the scenes (see System.Diagnostics.ProcessStartInfo), as of this writing (.NET 6.0.0-preview.4.21253.7).
Unless you know that you're invoking a .NET executable, a workaround that changes to the desired working folder in the new process is therefore required; to offer a more robust alternative to ふゆな's helpful answer:
$dir = $PWD.ProviderPath # use the current dir.
Start-Process -Verb RunAs powershell.exe #"
-noexit -c Set-Location -LiteralPath "$dir"
"#
The embedded "..." quoting around $dir ensures that paths with spaces are also handled correctly. (To use the current directory without an intermediate variable, replace "dir" with "$($PWD.ProviderPath)".
Using a here-string (#"<newline>...<newline>"#) isn't strictly necessary, but simplifies the embedded quoting; with a regular expandable string ("..."), the embedded " must be escaped as `" (or "").
Using $PWD's .ProviderPath property ensures that a file-system-native path is used (based on drive letters also seen in cmd.exe, for instance), given that the calling session's current location may be based on a PowerShell-only drive (see New-PSDrive) that the elevated process may not have defined (at all or not based on the same root location).
Caveat: If the native path is on a mapped network drive, this won't work, because elevated processes do not see the same drive mappings; in that event, pass the underlying UNC path.
Workaround for launching a GUI application elevated from a given working directory:
Since changing to the working directory must happen in the new, elevated process, a helper shell process is needed to perform this operation, which is best done via cmd.exe (for better performance):
$exeToLaunch = 'Notepad.exe' # may include arguments
$dir = $PWD.ProviderPath # use the current dir.
Start-Process -Verb RunAs -WindowStyle Hidden cmd.exe #"
/c cd "$dir" & $exeToLaunch
"#
Once you run Powershell as administrator;
user the push-location command like so:
Push-Location -Path C:\
or put it into your script and run the script from the elevated Powershell prompt.
I just ran your code example and it opened correctly for me at the WorkingDirectory location. Ensure the directory exists before you run the command. I tested against a drive on C and secondary drive as well and both worked.
I've been learning powershell just for a bit and i was wondering if let's say for example in "D:\installers" folder where i have let's say 15 installers(all inno Setup) it would be possible to run a silent install of all of those exes?
So far i've learnt how to run just one installer on silent which works perfectly fine. I just dont know how i would do it with multiple exes
Start-Process -Wait -FilePath 'D:\Installers\Installer.exe' -ArgumentList '/silent' -PassThru just for one installer
$installers = get-childitem "D:\Installers" -Filter "*Driver*.exe"
foreach($inst in $installers)
{
Start-Process -Wait -FilePath ($inst.FullName) -ArgumentList '/silent' -PassThru
}
Get-Childitem can be used to get the installers, and with foreach you can go through the results
You may modify the path follow yours and copy it to powershell (ensure to run as administrator).
Powershell will run them in sequence one after another.
Start-Process -FilePath 'D:\Installers\Installer1.exe' -Wait
Start-Process -FilePath 'D:\Installers\Installer2.exe' -Wait
Start-Process -FilePath 'D:\Installers\Installer3.exe' -Wait
When I enter the command
Start-Process powershell -WorkingDirectory "D:\folder"
it opens new PowerShell window with D:\folder location set.
But when I enter the command
Start-Process powershell -WorkingDirectory "D:\folder" -Verb RunAs
it opens new PowerShell window with admin rights but with C:\Windows\system32 location set.
How can I open new PowerShell window with admin rights and my own location determined?
I also had the same problem and solved it with this command:
Start-Process powershell.exe -verb runAs -ArgumentList '-NoExit', '-Command', 'cd D:\folder'
Once you run the above command, Windows will launch with admin authority and the specified directory.
Here's another example which can be used for opening CMD from PowerShell as an administrator into the current folder:
Start-Process cmd -ArgumentList ("/k cd {0}" -f (Get-Location).path) -Verb RunAs
if used within a script you can use
Start-Process cmd -ArgumentList ("/k cd {0}" -f $PSScriptRoot) -Verb RunAs
If you want to open a new elevated PowerShell session from the current one which is not elevated you can use:
Start-Process powershell.exe -ArgumentList ("-NoExit",("cd {0}" -f (Get-Location).path)) -Verb RunAs
or
Start-Process powershell.exe -ArgumentList ("-NoExit",("cd {0}" -f $PSScriptRoot)) -Verb RunAs
when used inside scripts
When using Start-Process with -Verb RunAs, a -WorkingDirectory argument is honored if the target executable is a .NET executable; examples:
pwsh.exe (the PowerShell (Core) CLI) does honor it.
cmd.exe and, curiously, powershell.exe (the Windows PowerShell CLI) do not, and invariably use C:\Windows\System32.
The problem exists at the level of the .NET API that PowerShell uses behind the scenes (see System.Diagnostics.ProcessStartInfo), as of this writing (.NET 6.0.0-preview.4.21253.7).
Unless you know that you're invoking a .NET executable, a workaround that changes to the desired working folder in the new process is therefore required; to offer a more robust alternative to ふゆな's helpful answer:
$dir = $PWD.ProviderPath # use the current dir.
Start-Process -Verb RunAs powershell.exe #"
-noexit -c Set-Location -LiteralPath "$dir"
"#
The embedded "..." quoting around $dir ensures that paths with spaces are also handled correctly. (To use the current directory without an intermediate variable, replace "dir" with "$($PWD.ProviderPath)".
Using a here-string (#"<newline>...<newline>"#) isn't strictly necessary, but simplifies the embedded quoting; with a regular expandable string ("..."), the embedded " must be escaped as `" (or "").
Using $PWD's .ProviderPath property ensures that a file-system-native path is used (based on drive letters also seen in cmd.exe, for instance), given that the calling session's current location may be based on a PowerShell-only drive (see New-PSDrive) that the elevated process may not have defined (at all or not based on the same root location).
Caveat: If the native path is on a mapped network drive, this won't work, because elevated processes do not see the same drive mappings; in that event, pass the underlying UNC path.
Workaround for launching a GUI application elevated from a given working directory:
Since changing to the working directory must happen in the new, elevated process, a helper shell process is needed to perform this operation, which is best done via cmd.exe (for better performance):
$exeToLaunch = 'Notepad.exe' # may include arguments
$dir = $PWD.ProviderPath # use the current dir.
Start-Process -Verb RunAs -WindowStyle Hidden cmd.exe #"
/c cd "$dir" & $exeToLaunch
"#
Once you run Powershell as administrator;
user the push-location command like so:
Push-Location -Path C:\
or put it into your script and run the script from the elevated Powershell prompt.
I just ran your code example and it opened correctly for me at the WorkingDirectory location. Ensure the directory exists before you run the command. I tested against a drive on C and secondary drive as well and both worked.
I'm a complete newbie when it comes to scripting Powershell but have a reasonable experience with writing Bat files.
I have a powershell script that unzips a bat, a reg file and a msi, the powershell script then launches the bat file, I dont think this is the best way to do it, is there a way to just get the powershell script to unzip and then install the msi and reg files rather than running a seperate bat file?
Here are the 2 files:
BAT:
#echo off
echo Installing Teamviewer, please wait...
msiexec /qn /i "C:\Temp\TeamViewer.msi" /passive
echo[
regedit /s C:\Temp\TeamViewer_Settings.reg
Pause
exit
PS:
$BackUpPath = "C:\Temp\Install.zip"
$Destination = "C:\Temp"
Add-Type -assembly "system.io.compression.filesystem"
[io.compression.zipfile]::ExtractToDirectory($BackUpPath, $destination)
Start-Process "C:\Temp\installer.bat"
Is there a way to just run the powershell script and extract and install the required files?
Many thanks and be kind, this is my first Powershell script.
you use start-process to run the bat file so just use the same to run the msi file instead.
Since there isnt a powershell cmdlet to import regitry files you can use regedit.exe to import the reg file.
Start-Process -FilePath 'msiexec.exe' -ArgumentList "/qn /i 'C:\Temp\TeamViewer.msi' /passive" -Wait
Start-Process -Filepath 'regedit.exe' -ArgumentList "/s 'C:\Temp\TeamViewer_Settings.reg'"