I am building a kiosk type config script on low-spec hardware.
At the end of the script, it runs the various apps for the user to interact with. I currently use a plain Invoke-Command "path\to\app.exe". I want to get the interface up and running as quickly as possible. I want to launch the apps asynchronous.
I know there is start-job, and the -asJob flag in Invoke-Command, but they don't seem to work with launching visual apps. Is there a way to do this?
Windows subsystem (visual) EXEs start asynchronously by default. And you don't need Invoke-Command to invoke an exe. If you exeute notepad.exe like so:
PS> Notepad
PS>
Note that the PowerShell prompt returns immediately while notepad is still running. The same applies in a script.
Related
I'm trying to run my software on Hyper-V VM using powershell Invoke-Command, without success. Host OS -Windows 10. Guest OS - also Windows 10. VM Generation 1.
I did some simple experiments and found out this:
If I run
Invoke-Command -VMName MY_VM -Credential $Cred -ScriptBlock { calc }
then I can see launched calc.exe on the guest system right with UI.
But if I run mspaint or any non-Microsoft program, nothing happens. The program just hangs in the VM TaskManager without any effect.
I also tried to run several different programs using CLI calling Invoke-Command several ways, but got the same result.
What could be the problem?
The basic answer is that powershell remote connections (or any remote connection like rdp, ssh, etc) take place in a separate logon session, and can't really interact with each other.
There are two reasonable ways to do this:
Use PsExec - part of the microsoft sysinternals tools group.
# List sessions - note the session ID of the session you want the process to start in
quser /server:$computername
# Run a process remotely, specifying the logon ID
PsExec.exe -s -i $ID notepad.exe
Use a scheduled task that runs when you are logged in and is visible. You can do this with powershell's various New-ScheduledTask commands to create one, or follow this guide by Scripting Guy! using WMI Win32_ScheduledJob methods.
See use powershell to start a gui program on a remote machine for more details on both options, and a well-written description of why it's hard to do in windows.
Is there a was for a Powershell script to be launched from Scheduler and run full ISE window and close when done.
I am using ZeeDrive to map a SharePoint Drive but running the Script in Scheduler, it cannot see the Drive. Yet if I open in ISE and run, it finds it fine. What I got back from ThinkScape :
'Zee Drive needs to run in a Windows session. It is designed for end users – if it is running as a service, or “headless” i.e. no Windows session, or being accessed from a different Windows session it won’t work.
We don’t support Zee Drive running as a service or for service type workloads – it is designed for end users working with documents'.
Any help would be greatly appreciated.
Thanks
The only way I can think of, would be to add your script to the Microsoft.PowerShellISE_profile.ps1 and then start ISE with the scheduler and your file as parameter, like this:
powershell_ise .\Check-Process.ps1
In your profile you would want to make sure, that the script only runs, when you open that file:
if($psISE.PowerShellTabs.Files.FullPath -eq '\\fileserver\path$\to\my\Powershell\Check-Process.ps1')
{
& '\\fileserver\path$\to\my\Powershell\Check-Process.ps1'
}
But be carefull! The script runs now everytime you open it in ISE unless you use the switch -noprofile.
So far I did not find a way to close the ISE window with the profile script.
I am trying to run and .exe in C:programfiles(x86)
I can launch it directly from the filepath. If I run in powershell just closes. No feedback.
Running powershell 5.1.17134 Rev 590
Start-Process -FilePath "C:\Program Files (x86)\App\App.exe"
I tried running powershell -NoExit and then start-process but it returns without any feedback.
If I run it on same machine in Powershell 6.1.0 preview - it runs fine. No issue. How can I track down whats causing this to 1) not run 2)close powershell.
Thanks,
This answer makes a general point. It doesn't solve your problem, if using Start-Process truly crashes the calling PowerShell window.
If C:\Program Files (x86)\App\App.exe is a console application that you want to run in the current console window, do not use Start-Process to invoke it.
Instead, invoke it directly.
Given that its path contains spaces and special characters (( and )), you need to:
quote it
invoke it with &, PowerShell's call operator.
PS> & 'C:\Program Files (x86)\App\App.exe'
Note:
The use of & with a command specified in a quoted string and/or via a variable reference is a syntactic necessity, given that PowerShell has two distinct parsing modes - see about_Parsing.
Invoking a console application directly:
ensures its synchronous execution
That is, control isn't returned to the caller until the application has terminated.
connects its standard output streams - stdout and stderr - to the equivalent PowerShell streams.
That is, you can capture or redirect the application's success output and/or error output, as needed.
You have an interactive shell. You spawn this new process - then your shell closes?
Clearly it is terminating its parent process, and clearly pwsh is doing something different.
I don't think this is truly a powershell question, it's a windows internals one. The suite of tools to use is Sysinternals. The first thing I'd try - and I'd do this on cmd, powershell and pwsh to establish a basis for comparison - is run Process Monitor with a filter on your app's path. Something in its last actions may prove illuminating. Process Explorer may also be useful.
Are you in a corporate environment? I have agents on my machine that kill processes based on heuristics. That can do things like this.
There may be a workaround based on how you invoke the app;
try mklement0's suggestion
try invoking through WMI; this does not provide your powershell process as a parent process: Invoke-WmiMethod -Class win32_process -Name create -ArgumentList "PathToApp.exe"
try invoking via cmd.exe if you are constrained by what's on your target machines
I do think this is off-topic, though.
I have a handful of PowerShell scripts which use the IE COM Object to open Internet Explorer and log into a web site and download a number of PDF files.
I would like these scripts to run on a production server and furthermore am wondering if its possible for them all to run at once, side by side without interruption. Or on the other hand, if they indeed must be kicked off sequentially, one by one.
Anyone have experience with this?
This is how I am calling the scripts, and it appears to me as though COM can only handle one at a time, regardless if they are in separate processes
Start-Process PowerShell "S:\pathtoscript1.ps1"
Start-Process PowerShell "S:\pathtoscript2.ps1"
Start-Process PowerShell "S:\pathtoscript3.ps1"
Have you tried?
Each com-object launch their own iexplore.exe process so it should work AFAIK.
A bit of background:
I'm trying to start and stop some performance counters remotely at the start of a test, then stop them at the end of the test. I'm doing this from an automated test framework from a Win2003 machine, the test framework executes commands without launching a console, some of the system under test is running Win2008. I've written scripts to choose the performance counters based on roles assigned to the servers.
My problem(s):
logman can't start or stop counters on machines that run a later version of the OS.
psexec can be used to run logman remotely, but psexec likes to hang intermittently when run from the test framework. It runs fine manually from the command line. I'm guessing that this is because the calling process doesn't provide a console, or some similar awkwardness. There's not much I can do about this (GRRRR)
I wrote a PowerShell script that executes logman remotely using the WMI's win32_process and called it from a batch script, this works fine. However, the test framework decides pass and fail scenarios based on the %ERRORLEVEL% and the content of stderr, but WMI's win32_process does not give me access to either. So if the counters fail to start, the test will plough on anyway and waste everyone's time.
I'm looking for a solution that will allow me to execute a program on a remote machine, check the return code of the program and/or pipe stderr back to the caller. For reasons of simplicity, it needs to be written in tools that are available on a vanilla Win2k3 box. I'd really prefer not to use a convoluted collection of scripts that dump things into log files then reading them back out again.
Has anyone had a similar problem, and solved it, or at least have a suggestion?
For reasons of simplicity, it needs to
be written in tools that are available
on a vanilla Win2k3 box. I'd really
prefer not to use a convoluted
collection of scripts that dump things
into log files then reading them back
out again.
PowerShell isn't a native tool in Windows 2003. Do you still want to tag this question PowerShell and look for an answer? Anyway, I will give you a PowerShell answer.
$proc = Invoke-WmiMethod -ComputerName Test -Class Win32_Process -Name Create -ArgumentList "Notepad.exe"
Register-WmiEvent -ComputerName test -Query "Select * from Win32_ProcessStopTrace Where ProcessID=$($proc.ProcessId)" -Action { Write-Host "Process ExitCode: $($event.SourceEventArgs.NewEvent.ExitStatus)" }
This requires PowerShell 2.0 on the system where you are running these scripts. Your Windows 2003 remote system does not really need PowerShell.
PS: If you need a crash course on WMI and PowerShell, do read my eGuide: WMI Query Language via PowerShell