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.
Toolkit Version:3.9.3
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)
serviceui.exe syntax:
.\serviceui.exe
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.
Examples:
serviceui %windir%\notepad.exe
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
I had to run psexec and accept the eula, before running that line. If I didnât do this and keep it in the original command it would immediately exit out with [-1].
I think (personally) Iâd move the `" to be after -accepteula -s as I think it reads more clearly - it âmayâ also make the need to accept the EULA twice, go away, e.g.
Try to use $($variable) to get rid of issues getting your vars translated to its actual value, this way you get it right using single or double quotes.
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:
Coming back to this 1 month later from a mention in other threads (and also with a fresh pair of eyes), have you tried using @Zeltoâs suggestion, so your code would now look like:
