Occasionally someone wants to launch an application interactively on target computers. That is, they want to use BatchPatch to trigger the execution of an application that will appear on the desktop of the currently logged-on user of the target system(s). This can be both simple and not-so-simple to do at the same time. There are a few things to consider:
- These instructions were created on Windows 10 machines using PsExec version 2.40. These instructions should work with PsExec versions going back to v2.32, but versions of PsExec that are older than 2.32 behave differently. Also older versions of Windows behave differently. The instructions might have to be altered to work with older versions of PsExec and/or older versions of Windows.
- Set your Remote Execution Context (Tools > Settings > Remote Execution) in BatchPatch to be either SYSTEM or Elevated token, but leave Interactive UNticked for this operation. IMPORTANT: Normally with PsExec version 2.32 or newer you can only use Elevated token if Interactive is also checked. However, for this particular tutorial to work, Interactive needs to be UNticked, so that we can specify the Interactive -i switch manually in the command itself. If you use SYSTEM, the command will be executed as SYSTEM. If you use Elevated token, the command will be executed as the user you specify in the Alternate Credentials field for the given row in BatchPatch. If no alternate credentials are specified, the command will execute as the user that launched BatchPatch. In all cases, the user account that executes the command needs to be a member of the local administrators group of the target computer(s).
- Here is where things get not-so-simple, especially if you want to an application to be launched interactively on many remote computers. To do this, we need to know the session ID of the logged-on user of the target system. The session ID is not guaranteed to be the same for any particular computer or for any particular logon session of a particular computer, which is why this becomes not-so-simple if you want this to be successful on numerous remote computers. However, since the session ID will typically be 1 or 2, or perhaps 3, you can probably fudge it in most cases without actually looking up the session ID for each target. I’ll explain in a moment, but first if you want to identify the correct session ID, one way to do it is to look at Task Manager’s Details tab on a target computer.
Launch Task Manager and go to the Details tab, then right click on the column headers and choose Select Columns.
Then tickSession ID in the list of columns to make that columns visible.
With the Session ID visible you can now figure out the session ID of the desired user. In this case I’m logged on as testAdmin, and that account is running in session 1. Oftentimes I will find the interactive user is logged-on to session 2, but today for whatever reason it’s session 1. - In order for me to launch Google Chrome remotely with BatchPatch so that it appears visible to the interactive/logged-on user of the target system, I have to specify the correct session ID in the command that I execute in BatchPatch. In a BatchPatch Remote Command I am using the following syntax:
-d -i 1 "C:\Program Files\Google\Chrome\Application\chrome.exe"
The -d specifies that the command should be executed but that PsExec (and consequently BatchPatch) should NOT wait for the remote process to terminate. The -i 1 specifies that the command should run interactively in session 1 on the target system. Adjust this session ID number accordingly. The path to the executable has to exist on the target system. So, in this case I’m launching Chrome because Chrome has already been installed on the target system, and I’m specifying the correct path to the chrome.exe.
When this is all done correctly, the exit code you see in BatchPatch will be the process ID (PID) of the process that is launched on the target. In the case of Google Chrome there will be multiple processes launched because when chrome.exe is launched, it spawns multiple other processes.
If you see exit code 2, it likely means that you specified an invalid session ID. You can use that information to your advantage because instead of looking up the proper session ID manually for every target computer, you can probably just try session ID 1 first, and then for any commands that return exit code 2, next try session ID 2, and then finally after that maybe even try session ID 3.