We are currently using an Invoke script to launch PSEXEC, using ServiceIU to display Deploy-Application UI to the user as the application is installed. This all works flawlessly with one exception, that is if $scriptParentPath has a space in it. To try and resolve the issue I have attempted to add Quotes to the existing command to deal with the spaces. But this then causes an issue with Deploy-Application. I have checked the formatting of the various quotes but running another application (with a space in the path) such as notepad++.exe with the same format works as expected. From testing the issue doesn’t appear to be the command itself but rather Deploy-Application.exe exiting as the exit code is showing as 0. It is exiting out the same second that it is launched and doesn’t create any log. Normally this isn’t an issue as MECM (SCCM) doesn’t have any spaces in its ccmcache paths, but sometimes our technicians will run the package manually on a machine from a path that has a space, I just wanted to head the issue off.
PowerShell Version: 5.1
I have posted on the GitHub Issues but thought I would also try here for visibility.
As a colleague of Adi-R, I’ll give a bit of a background of why we are invoking “psexec with parameters of serviceUI and deploy-application.exe”. This does work 100% fine - just as long as you don’t have spaces in your $scriptParentPath (which to be fair isn’t typical but is something we noticed)
The reason we don’t run ServiceUI directly from SCCM is because we want a single package and Deployment Type that can run “whether or not a user is logged on” AND also displays interaction for logged-on users including RDP session users.
If we run ServiceUI directly from SCCM’s command line this does not work for Remote Desktop (RDP) sessions, and we have quite a few of these to consider. The interaction (e.g. dialogue boxes) are not displayed and will timeout, causing negative results.
Our “invoke script” will gather whether or not a user is logged on.
If “no user logged on” we execute-process “Deploy-Application.exe $DeploymentType”
If a user is logged on then we execute-process “psexec > serviceui > deploy-application.exe $DeploymentType”
Although technically only RDP or disconnect-RDP sessions need to run PsExec with ServiceUI, by doing this for all user-sessions we are “InTune-Ready” (where ServiceUI will be required for interaction).
Why are we using PsExec? Without it, we found SCCM deployments would fail. If we manually ran the same line from an administrative PsExec command prompt, it worked fine! So we added PsExec to call ServiceUI and this works 100% and we now have a SINGLE package solution.
Adi-R has only raised this question because we discovered that IF $scriptParentPath has a space in the path then it will fail and this only appears to be only a problem with “Deploy-Application” and works fine with spaces when testing against other apps such as NotePad++.
While I completely understand your reasoning for using psexec (it’s a great utility after all), but be aware that some modern antivirus / malware prevention tools will block the use of psexec as it is often used by malicious users to wreck havoc on devices, might be worth having a read, here is some background reading:
So it may be worth considering if you could negate the use of psexec… as you are already using ServiceUI, you could specify your ServiceUI.exe command to run the install command in the System context e.g. serviceui.exe -session 0 rather than running in the user context serviceui.exe -process explorer.exe (explorer.exe will always run in session 1 as it does not run in the system context)
Execute program interactively in target session. Must run from
SYSTEM context. If no session is specified, program will run
in session connected to keyboard/mouse (console).
Usage: serviceui [-nowait] [ [-session:<sessionid>] | [-process:<process.exe>] ] program [arg(x)]
-nowait Don't wait for program completion. Exit
code will not be captured.
-session Specify session number to launch in.
-process Search for process; program will
launch in same session.
program Name of application to execute.
arg(x) Argument(s) for program.
serviceui -session:1 %windir%\notepad.exe
serviceui -process:calc.exe %windir%\notepad.exe "\"my file.txt\""
serviceui -process:calc.exe "%windir%\notepad.exe" "\"my file.txt\""
Exiting with [-1]
A useful guide on using ServiceUI.exe:
As this is to have a single install that you can run on physical devices and machines with RDP sessions, you may need to detect if the machine is running RDP sessions.
Thankfully WIndows ships with two tools named QWINSTA.exe and RWINSTA.exe for querying and resetting Remote Desktop Services sessions (Who knew?!), this may help solve your challenge
Just a bit of a curve ball for your thought process
Just to update this with the final solution. The quoted paths in the post above were all working fine…… until we tried to do a required install via SCCM(available was fine). I am still not 100% sure why this is different from available(maybe someone here knows?), but it was causing the script to fail out. We re-tested with the un-quoted line and a required install, and it worked. Then a colleague let slip there maybe spaces in Intune paths!
So back to the drawing board….
There were 2 issues to fix:
PsExec -accepteula not being accepted on the command line.
Allow spaces in the paths.
After looking at it with a fresh pair of eyes this is the fix I came up with: