windows - Open Excel on Jenkins CI

Question

I am working on Windows 7 (logged in as session no.1), my Jenkins CI is running as windows service in session 0. My problem is.. I want to open an Excel file through Jenkins CI in session 0, but want to display its GUI on session 1.

I know that session 0 is isolated in Windows 7, but is it possible to run a process in session 0 and then output in another session? please help.

Answer 1

Edit:
Took a little trial and error, but this is what finally worked for me (Windows 7 64-bit).

• Download PsTools from Microsoft site
• We only need psexec.exe, but you can extract everything. Extract to some location accessible by Jenkins, preferably without spaces in the path.
• Open elevated command prompt: type cmd into Start's quicksearch, right click cmd.exe, select Run as Administrator.
• Type C:pathopsexec.exe -accepteula and press enter.
• Type C:pathopsexec.exe -i 1 cmd and press enter. (If you see a command prompt appear, all is good, close it now)
• In Job configuration, configure Execute Windows Batch command step
• Write the following:
  C:pathopsexec.exe -accepteula && C:pathopsexec.exe -i 1 cmd /c start C:PROGRA~2MICROSO~1pathoexcel.exe

Where:

• C:patho is your full path to psexec.exe, unless it is in your %path%
• -i 1 is the session ID that you want to launch in.
• C:PROGRA~2MICROSO~1patho is your full path to excel.exe without spaces. Since most Office installations are going to be under paths with spaces, like "Program Files (x86), you have to figure out the short path, or place it somewhere without spaces.
• Having excel.exe under %path% and working from regular command line was not enough.

A little explanation for those that care:

• psexec needs to install a services first. For that, it needs to be run from elevated command prompt for the first time. This is a one-time installation step.
• To make psexec work, you need to accept the EULA prompt. This is done per session/user. So even if you run psexec -accepteula in your command prompt, it doesn't help when Jenkins service (running as Local System in session 0) tries to use it. Therefore, you have to place that into the Jenkins job, along with the command. Technically, it only needs to be there once, and can be removed afterwards, but it definitely doesn't hurt to keep it there.
• I've used cmd /k and running this command from my local cmd prompt to debug. This is what made me realize I couldn't find a way to escape the spaces (tried various quoting), so had to resort to short file names. Note that short file names are not required, this is just to escape spaces.