4.1.3 - Trying to display a command prompt using ServiceUI

The Toolkit General Discussion
1

Hi,

There's been a similar post recently, and this is my attempt at implementing it.

I need to install features such as Active Directory Users and Computers with Intune.

One of my problems is that the time it takes to install a feature can vary a lot, and may look like nothing is happening.
The best way I have found is to use dism.exe and have its command prompt window opened to show the progress bar.

But of course I'm running as System, so I have to use ServiceUI.

My latest attempt looks like this:

Start-ADTProcess -FilePath "$($adtSession.DirSupportFiles)\ServiceUI_x64.exe" -ArgumentList "-Process:explorer.exe C:\Windows\System32\cmd.exe /C C:\Windows\System32\Dism.exe /Online /Add-Capability /CapabilityName:Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0" -WindowStyle 'Hidden'

Which works a treat when I run PSADT locally, but from Company Portal it fails with error -1 (which sounds very generic).

I've been through a few iterations, so I can't see the wood for the trees. Is there something I am missing?
Or is there a better way to achieve what I am trying to do?

Thanks!

... Alex ...

2

Why not use something like Show-ADTInstallationProgress -StatusBarPercentage 10 to show a progress bar?

Try to stay away from ServiceUI.EXE

3

If you add -CreateNoWindow onto the command line instead of -WindowStyle Hidden, at least stdout would be captured Start-ADTProcess, which will write it to the log file and will help you debug this.

I do have to completely agree with @That-Annoying-Guy though as you're foregoing so much security just to display a console window indicating the current process of an operation. In addition to exposing a command prompt running as SYSTEM to end users, users can simply just close it and break your entire deployment.

It'll be hard to use our progress percentage stuff as part of Show-ADTInstallationProgress since the dism.exe call will be blocking, but you can at least show our progress window indicating to users that the process will take ~10-15 minutes to complete.

Lastly, why dism.exe at all? You should be using Add-WindowsCapability for this, which is part of the native PowerShell modules shipped with Windows.

4

Hi both,

Thanks for chipping in.

Due to the nature of dism, the progress bar is shown in the command prompt window, so using Show-ADTInstallationProgress would not be representative of the actual progress. In my tests, it can take from a few minutes to 20 minutes, and the PSADT progress window does not give a sense to what's happening. I also need to install 2 features in this package.

I have read the other thread about ServiceUI and understand the risks, but right now I don't know how I can install this while giving meaningful feedback to the end user, and given that it's not a required app I think that's important. At least, if they try to abort dism the command prompt window will close, they can't take it over for other purposes.

Thanks for the tip about -CreateNoWindow, I'll try that to get more info.

I did try Add-WindowsCapability, but again it did not provide me with a sense of progress, at least not that I remember of.

Thanks!

5

I'm going to be a little bit blunt, but if you've read everything and still want to proceed in this way, then I don't think you truly understand the risks at all. You're presenting a command prompt window, running as SYSTEM, the highest privilege user in Windows, to a user, just to show progression information. Its not just about the user being able to control and close the window, its that the user could potentially hijack the command prompt and do whatever they wish with it.

I would recommend just showing our progress dialog and advise in the messaging that the deployment will take between 5-15 minutes. You should not be showing them the SYSTEM-running command prompt just to try and give them more visiblity.

6

I don't understand how that prompt can be hijacked (happy for someone to explain though), but I'll take your advice. I have spent far too much time on this anyway.

7

Just on your initial issue that you've reported, I've done some testing and was able to replicate. I've got a fix for 4.1.4, which hopefully we can release next week.

It's more likely for this to occur if the command line is messed up rather than the user doing something surreptitious, but its still incredibly dangerous even if everything is lined up properly, and real-world exploits have occurred from ServiceUI utilisation.

What you do is your prerogative of course. It'd just be remiss if I didn't discourage this due to the known dangers of such a setup, especially when you're trying to do something not because of a need, but because of a desire.

8

I haven't tried to start ServiceUI via Start-ADTProcess, but can call out the fact I was seeing 'Access Denied' errors calling it via Start-ADTProcess, which led to me simply relying upon & to execute it in Invoke-ServiceUI.ps1 back in v4.0.x:

PSAppDeployToolkit/examples/ServiceUI/Invoke-ServiceUI.ps1 at 4.0.x · PSAppDeployToolkit/PSAppDeployToolkit

9

Start-Process could have been used if .WaitForExit() was used on the PassThru process rather than the -Wait parameter as PowerShell uses a job object to track the process, and processes in a job tree can't have differing Session Ids.

I've only come to know all this from the work that's been put into 4.1 as the issue was closely related to why we were having the same error/issue while testing the toolkit via task sequences during development.