Is ServiceUI.exe actually being used?

[obuolinis]

RunInSandbox.ps1 mentions a contribution from @Joly0 "Added ServiceUI in favor of psexec", however I can still see psexec being used in the code for the PS1System profile, while ServiceUI doesn't seem to be used anywhere at all. Was it ever changed?

Run-in-Sandbox/Sources/Run_in_Sandbox/RunInSandbox.ps1

Line 343 in be67c90

$Script:Startup_Command = "C:\Users\WDAGUtilityAccount\Desktop\Run_in_Sandbox\PsExec.exe -accepteula -i -d -s powershell -executionpolicy bypass -file $Full_Startup_Path"

As far as I can see a fork by @Joly0 actually uses ServiceUI, not psexec, so I'm really confused here. Could you clarify what was the intention? Was it a mistake?

[Joly0]

Hey, so this wasnt a mistake, but rather an issue i tried to solve but only half way through, so the changes regarding ServiceUI have been reverted. I am working on a solution that actually uses both.

[obuolinis]

Hey @Joly0, so I did some testing and I strongly believe ServiceUI is not the right tool here. It works kinda the other way around than is needed for running something in System context.
To my knowledge for that purpose you can basically utilize either psexec or a scheduled task.

Talking about the psexec way of running PS1 scripts in Sandbox in System context I was initially having trouble with that since the builtin command line (referenced above) didn't seem to do anything. Running it manually from within the sandbox I was getting "The network path was not found" error and I couldn't figure out why. I noticed that each such failed run generated a windows event under Microsoft-Windows-SMBClient/Connectivity log that said:

The server name cannot be resolved.
Error: The object was not found.
Server name: 4F25F4FC-592E-4

The sandbox actual hostname is always in the GUID format that psexec seems to truncate to 15 characters (which is NETBIOS name standard) when connecting to. I'm not sure whether it's psexec limitation or something in my environment. Does it work for anyone at all?

What eventually worked for me was adding \localhost and omitting -i and -d switches, like this:
psexec \\localhost -s powershell ...

When you mention you're working on a solution that uses both psexec and ServiceUI, do you mean something like running a powershell script using ServiceUI from a "psexec -s" shell? I tried that to achieve an interactive window running powershell as System but didn't succeed.

[Joly0]

Yes, i found the same solution and for me -i still worked, not sure why it doesnt work for you.
And yes, i mean running serviceUI through psexec for an interactive view. I got this to work for intunewin already, as its quite handy to have an interactive view on the install process while it still being run under system context.
I am working on getting this to work for ps1 as system aswell, but i havent had any time yet to get this implemented. I will try in the next few days and will make a pr when i am finished.

Too close this, i initially thought serviceUI allowed to run as system with interactive window, but it was only to allow system processes to be visible to the user context. That was my mistake but i still think both systems together might really help, especially when troubleshooting.

[Joly0]

You can take a look at my fork here https://github.com/Joly0/Run-in-Sandbox/blob/master/Sources/Run_in_Sandbox/IntuneWin_Install.ps1
I have already commited the changes for the intunewin script and it works for me. And thats the way i got it working correctly "without any" issues

[obuolinis]

Having visibility while running powershell scripts is a big bonus, totally agree, and therefore I was eager to make all PS1 options interactive. As soon as I wrote my last post, I found a way to combine psexec -s and ServiceUI. Goes like this:

PathTo\psexec.exe \\localhost -accepteula -s PathTo\ServiceUI.exe -session:1 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoExit -NoLogo -File C:\Users\WDAGUtilityAccount\Desktop\ScriptFolder\script.ps1

Notes:

• ServiceUI apparently wants a full path to powershell.exe
• -session:1 because sandbox user always runs in session 1
• With -NoExit powershell window stays open after execution, handy for catching errors
• -NoLogo removes the startup banner
• there's an open-source psexec spinoff called paexec, i found it works more consistently for me (no \localhost needed, -i works too)

I have also added interactivity for other two PS1 options, I can share them separately if you want.

[Joly0]

Ye, my approach is quite similar and i found paexec aswell, but not sure if its safe to use. Psexec is by microsoft (or sysinternals/Mark Russinovich to be more precise) and therefore a trusted developer imo. Paexec is by PowerAdmin, which is a well-known Company. But if i had to decide between open source aspect and a more trusted publisher, i'd trust microsoft more with psexec, but thats just my point of view.

[damienvanrobaeys]

Hi, sorry for the delay, i was a but busy with work.
I will update the full project

[Joly0]

Btw, this issue is fixed in my fork and therefore in my PR