I have an application on a remote machine which spawns about 300 instances of different executable. It works fine when I double click on it, but when I try to execute the main application from a remote machine using PowerShell it does not spawn over 100 instances. One major difference is that when I execute the application through PowerShell it runs as a background process. Below is the command used.
Invoke-Command -Session $Session -ScriptBlock {
Set-Location 'C:\LatestCode'
& Start-Process -FilePath C:\LatestCode\ImageManager-Service.exe -Wait
}
It's the same behaviour when I try yo run the application using the Task Scheduler.
Related
I am trying to install an application on my Windows server.
The application needs to be installed as an Active directory user/service account.
The service account as part of all the relevant user groups.
If I launch a power shell window by running it as that service account user installation works successfully.However this task need to be automated.
To achieve this I am calling the installer from the power shell script and trying to run it as that service account user.
I have tried the inward command and the start process command to call the installer but it fails.
The workflow is
Task Scheduler > Task > Powershell Script(Run as local System admin account) > Invoke-Command OR Start-Process; calling the installer as the service account.
start-process "C:/install.exe" -Wait -Credential ($ServiceAccount_Crednetials_Object)
start-process "C:/install.exe" -Wait -PassThru -verb runas /user:NTADMIN\Service_account
Invoke-Command -scriptblock { Start-Process "C:/install.exe" -ArgumentList $Using:arguments -Wait } -Credential $mycreds -ComputerName localhost
it seems like there may be a double hop issue. But I am not sure what is happening
I'm using Azure-Pipelines for my CI. In my pipeline, I need to use multiple instances of a CMD (Windows). For example, one CMD needs to start and continuously run a server, while the other needs to then deploy an app while the server is still running.
When using the CMD task, it only uses one instance of the CMD, so when I run the server, it never finishes and never gets to running the app.
Is there a way to run multiple instances of a CMD with Azure-Pipelines?
You can start cmd.exe on the agent machine from a powershell task using Start-Process command.
So you can add multiple powershell tasks to start multiple CMD instances on the agent machine. Or you can start multiple CMD instances in one powershell task. Se below example:
steps:
- powershell: |
'Start-Process -FilePath "C:\Windows\System32\cmd.exe" -verb runas -ArgumentList {/k echo "hello"}'
- powershell: |
'Start-Process -FilePath "C:\Windows\System32\cmd.exe" -verb runas -ArgumentList {/k echo "world"}'
I'm having some trouble getting Clean Manager on Windows 10 to run remotely. I've seen a few different things were you can edit the registry and modify the /sageset or /sagerun to be specific things then run it remotely, but it seems no matter what I do the CleanMgr runs locally on my machine rather than running remotely.
I believe this is the closest I've gotten to get it to run remotely... It seems to still just run locally on my machine though.
Any ideas?
( All variables are set before this portion of the script, this is just a small portion of what's going on that I'm stuck on )
## Starts cleanmgr.exe
Function Start-CleanMGR {
Write-Host "Please provide your A-Account details to continue with this cleanup."
$creds = Get-Credential
Enter-PSSession -ComputerName $computername -Credential $creds
try {
$cleanmgr = Start-Process -Credential $creds -FilePath "C:\Windows\System32\cleanmgr.exe" -ArgumentList '/verylowdisk' -Wait -Verbose
if ($cleanmgr) {
Write-Host "Clean Manager ran successfully! " -NoNewline -ForegroundColor Green
Write-Host "[DONE]" -ForegroundColor Green -BackgroundColor Black
}
}
catch [System.Exception] {
Write-host "Cleanmgr is not installed! To use this portion of the script you must install the following windows features:" -NoNewline -ForegroundColor DarkGray
Write-host "[ERROR]" -ForegroundColor Red -BackgroundColor Black
}
} Start-CleanMGR
PowerShell always runs in the user context of the user who started the session. This is by design.
You can not run a GUI based application remotely using PowerShell. It is a Windows security boundary.
To run GUI apps, someone must be logged on, and you cannot use PowerShell to run code as the logged-on user.
You are also prompting for info, so, someone must be logged on.
If you are expecting a user to prived info, then you need to:
Create the script
Deploy the script to the user's machine or a files share from wich it
can be ran
Tell the user how to do it or create a batch file they would double
click to run the PowerShell script
Or
Set the script to run as a scheduled task at log on or at some point during the day, as the user credentials.
Variables have the scope and you cannot use local variables in a remote context unless they are scoped for that.
About Remote Variables
Using local variables
You can use local variables in remote commands, but the variable must
be defined in the local session.
Beginning in PowerShell 3.0, you can use the Using scope modifier to
identify a local variable in a remote command.
The syntax of Using is as follows:
$Using:<VariableName>
Still, the remote variable is not something you will do in your use case since you cannot do what you are after natively with PowerShell. You'll need a 3rdP tool like MS SysInternals PSExec to run code remotely as the logged-on user.
Using PsExec
Usage: psexec [\computer[,computer2[,...] | #file]][-u user [-p
psswd][-n s][-r servicename][-h][-l][-s|-e][-x][-i [session]][-c
executable [-f|-v]][-w directory][-d][-][-a n,n,...] cmd
[arguments]
-i Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the
process runs in the console session.
-u Specifies optional user name for login to remote computer.
I suggest that you use Invoke-Command
Function Start-CleanMGR ($computername, $creds) {
Invoke-Command -ComputerName $computername -Credential $creds -ScriptBlock {
try {
$cleanmgr = Start-Process -FilePath "C:\Windows\System32\cleanmgr.exe" -ArgumentList '/verylowdisk' -Wait -Verbose
if ($cleanmgr) {
return "Clean Manager ran successfully!"
}
}
catch [System.Exception] {
return "Cleanmgr is not installed! To use this portion of the script you must install the following windows features:"
}
}
}
Start-CleanMGR -computername "remotehost" -creds (Get-Credential)
As long as you execute cleanmgr.exe under a user account that has local admin rights, everything will work. Running cleanmgr.exe under the SYSTEM account, E.G. running from the Run Script Tool in SCCM/MECM will not work unless the script first opens a separate shell (DOS/PS) under a user that has local admin rights...even the cleanmgr.exe /verylowdisk will not run under the SYSTEM account.
I'm trying to create a Powershell script that will be deployed to any node that is showing bad update health to automate some of the simple tasks without having to interrupt users during their workday. The Powershell script works perfectly if ran from an elevated PS prompt. It also runs fine when the same script is deployed to a test machine via SCCM with one exception: it won't call SFC.EXE /SCANNOW.
I've tried using:
Start-Process -FilePath "${env:Windir}\System32\SFC.EXE" -ArgumentList '/scannow' -Wait -NoNewWindow
Start-Process -FilePath "sfc.exe" -ArgumentList '/scannow' -Wait -NoNewWindow
Start-Process -FilePath "${env:Windir}\System32\SFC.EXE" -ArgumentList '/scannow' -RedirectStandardOutput "C:\SFC-Out.log" -RedirectStandardError "C:\SFC-Err.log" -Wait -NoNewWindow
& "sfc.exe" "/scannow"
Invoke-Command -ScriptBlock { sfc.exe /scannow }
Again, all of these examples work exactly as intended when run from an elevated PS prompt, but fail when run from the deployed PowerShell script. When I used the -RedirectStandardOutput, I checked the file SFC-Out.log and it read:
"Windows Resource Protection could not start the repair service"
I think this is because SCCM runs programs/scripts in the SYSTEM context instead of a user context (or even an elevated user context, but SYSTEM is supposed to be higher than an elevated session).
Is there a way to accomplish this? Sorry for the bad formatting, this is my first post on this site.
A bit late but I encountered the same issue. Not sure if this is the case for you but the cause was configuring the deployment of the script with SCCM to run as a 32 bit process. The script was being deployed to 64 bit systems. When I unchecked "run as 32 bit process" in the deployment configuration SFC worked without an issue under the context of a System account.
I created a package (not an application) in SCCM and had to use the redirect using the elusive sysnative folder for x64 machines:
https://www.thewindowsclub.com/sysnative-folder-in-windows-64-bit
So it would be:
C:\Windows\Sysnative\SFC.EXE /SCANNOW
What you have will work, just missing "-Verb RunAs" to elevate permissions. So your cmdlet should read:-
Start-Process -FilePath "${env:Windir}\System32\SFC.EXE" -ArgumentList '/scannow' -Wait -Verb RunAs
I've been reading and searching online for this, the only answer so far is that It can't be run due to sccm using the system account. It's also the same behavior when trying to run winmgt.
Fast forward to SCCM Current Branch 2109 and I was able to solve this problem by using the new Scripts feature built into SCCM. Using & 'sfc.exe' '/scannow' works, and I can manually run this script against any device collection showing devices in error. Start-Process -FilePath "sfc.exe" -ArgumentList "/scannow" -NoNewWindow -Wait works too.
I use the following command to run setup_server.exe on remote Windows box:
powershell -command "$encpass=convertto-securestring -asplaintext RPASSWORD -force;$cred = New-Object System.Management.Automation.PSCredential -ArgumentList RUSER,$encpass; invoke-command -computername RCOMPUTERNAME -scriptblock {setup_server.exe} -credential $cred;"
setup_server.exe's task is to create some configuration files and start my_server.exe (some daemon process), then it finishes. And I want my_server.exe to keep running after setup_server.exe is finished.
So when I do it via CMD on local box (i.e. just run setup_server.exe from CMD) it works, but when I do it via powershell on remote host it doesn't work. Namely the my_server.exe gets started, but right after setup_server.exe is closed the server also gets closed(killed).
So the question is following:
Which powershell flags/cmdlets should I use to make the described scenario to work as in local mode?
NOTE: I want synchronously get output of setup_server.exe, so running remote command with -AsJob flag, probably wouldn't work for me, though I even don't know if it will keep the server alive after setup_server.exe's end.
The way to keep the remote PowerShell session running after the command has finished is to use a PSSession e.g.:
$s = new-PSSession computername
Invoke-Command -session $s { ..script.. }
... do other stuff, remote powershell.exe continues to run
Remove-PSSession $s # when you're done with the remote session
Generally though exes should run independently from the app that launched them.
Why are you using Invoke-Command. If you want a persistent Session, use Enter-PSSession.
$s = New-PSSession -Computername "Computername";
Enter-PSSession -Session $s;
setup_server.exe
# Once you are finnished
Exit-PSSession
With 'Enter-PSSession' you are not just Invoking some Command on the Server, you are directly logged-in like you probably know from SSH.
If you want your powershell session to keep running because you are running an exe, try using the -InDisconnectedSession switch. From what I understand, it will run the executable on the remote machine in a session that isn't actually connected to your computer. In essence, your computer will not destroy the session, when it disconnects, allowing the exe to continue to run.
invoke-command -computername RCOMPUTERNAME -scriptblock {start-process setup_server.exe} -InDisconnectedSession
If you need to do this on multiple computers. Setup an array of all the computer names.
Note: I don't believe this works with sessions that are already created.
In order to keep a powershell code running on the session exit it should be a process. And the windows way to keep the process is running a .exe or a windows service.
To keep a Powershell shell open after executing a command, I use the -NoExit switch, e.g. this script starts a remote interactive PS session on servername with user administrator
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit
-Command "Enter-PSSession -ComputerName servername -Credential administrator"
http://powershell-guru.com/powershell-tip-13-prevent-powershell-from-exiting-once-script-finished/