Show-ADTInstallationWelcome v4.1.8 Noticed errors

[Tropheusman]

Something changed between v4.1.7 and 4.1.8 regarding the Show-ADTInstallationWelcome cmdlet. 4.1.8 runs better than 4.1.7, but still not as it should.
With 4.1.7 the install would fail completely (explained here PSADTv4.1.7 - Show-ADTInstallationWelcome Error - The Toolkit / General Discussion - PSAppDeployToolkit Community).

With 4.1.8 everything works fine if the process is running as the logged on user. Often times we must elevate processes and this is where the issue arises. If I run a simple script that looks to close Notepad, running with elevated rights (not with the Logged On User account), and I use AllowDefer = $true in the $saiwparams, the install pops the message up, but it doesn’t list the process to close.

Defer works and Install work.

If I do the exact same thing, but instead of AllowDefer = $true, I change that to AllowDeferCloseProcesses = $true, the script closes the process, but doesn’t provide the popup. When the install completes, I do see the completion popup.

This is what strikes me as strange, the log entry:
[Pre-Install] :: Force closing application(s) ['Notepad'] that the user had no permissions to close.
Why would the System account not be able to close a process running as System?

Here is the full log…

I am not pointing the finger at the Toolkit as the source of the issue. I don’t believe it is.
Does anyone have any ideas on what could be in my environment that could cause this sort of behavior? I have already removed or disabled our security tools.

[Tropheusman]

It looks like in the psm1 I am going down this path…

The question is why is it that we can identify running processes that need to be closed, but we don’t ask the user to close them or defer? I would think you would want to popup the Show-ADTInstallation Welcome prompt if the processes will be closed regardless of the account used to open them.

I have not run through the entire logic here, so I do not know the reason for running the install interactively with processes running, but not prompting the user to close the processes, but still forcing closed the processes silently.

[mjr4077au]

The processes are closed via the client/server client and it runs as the user, as highly privileged as possible. If the user is an admin, it'll run elevated. It sounds like your user account is now and their it's running as a standard user. As such, it won't have visibility of other user processes to close, hence that fallback code for remaining processes that are still open, which we simply terminate.

[Tropheusman]

Yes, you are absolutely right. Our logged on user accounts do not have the necessary rights. But these same users could, and often do, have secondary accounts that do have admin rights.

I would think that we would want to address this scenario, since it is a common practice.

So these users have enough rights to elevate with an alternate account, but simply because their logged on user account doesn’t have those rights, the Toolkit, which we use with MECM, which would run the install as SYSTEM, cannot close elevated processes? This is not the experience we saw in 3.10. Maybe your reasoning is to secure the toolkit from malicious code, but that seems unlikely, since you just terminate the processes anyway.

I am just trying to understand what is gained by doing it this way. I certainly see the downside of it.

For now, I have written a function to deal with this scenario. It checks if any processes are running that are not running as the logged on user, then uses the Show-ADTInstallationPrompt to alert the user that the processes are running elevated, and gives them the option to close the processes and continue the install, or to display the Show-ADTInstallationWelcome, to allow for deferral. This is less than optimal, since it adds an additional touchpoint for users in this scenario. For any processes that are running under the logged on user account we use the $saiwparams standard method, along with the AllowDeferCloseProcesses parameter.

I do thank you for responding already to my somewhat silly messages. I’m sure they often come off as low-level ramblings.

[mjr4077au]

@Tropheusman

I would think that we would want to address this scenario, since it is a common practice.

It might be a common practice in your environment, but this is the first report I've seen of such a situation. Usually the only problem that's arisen from the new client/server setup is people placing services in the CloseProcesses list, which if you think about it is silly as why would you ask the user to close something they have no chance in hell of being able to do.

@Tropheusman

So these users have enough rights to elevate with an alternate account, but simply because their logged on user account doesn’t have those rights, the Toolkit, which we use with MECM, which would run the install as SYSTEM, cannot close elevated processes? This is not the experience we saw in 3.10. Maybe your reasoning is to secure the toolkit from malicious code, but that seems unlikely, since you just terminate the processes anyway.

I am just trying to understand what is gained by doing it this way. I certainly see the downside of it.

There's many reasons for the client/server refactoring:

1. Intune users have never had a "Allow users to view and interact with the program installation" like ConfigMgr does, so people have relied on things like ServiceUI. This utility can be rather dangerous, and now is hard to find since MDT has been required.

2. ConfigMgr's "Allow users to view and interact with the program installation" option is simply just as dangerous as it's basically a built-in version of ServiceUI, and offers all the same perils and pitfalls. Imagine allowing an interactive install of Git so users could pick their settings, only to leave "Open a Git terminal" option at the end of a deployment, giving them a SYSTEM-running interactive command prompt. Ideally you want this checkbox unchecked at all times and in 4.1.0 or higher, you can.

3. The toolkit can now be used on more platforms with ease, and certain platforms where we've never been able to provide support. Omnissa Workspace ONE is a primary example where ServiceUI never worked, but our client/server process does. This is a massive win for that community and unlocks new customers.

4. The client/server approach is paving the way towards better support of multi-session environments, something we've never supported well. You might have multiple users on a terminal server or AVD device. In older releases, some lucky user would get the dialog, hit the "Close Programs" button and kill off everyone's app on the host. That's completely unacceptable and is a real problem that requires resolving. We've got a lot on our plate for 4.2.0 so we may not get there with this, but we're working really hard.

The whole example around Git alongside "Allow users to view and interact with the program installation" is the real big one in terms of security. It's something Microsoft should have never provided and unless you're experienced in developing against Win32 APIs, simply wouldn't understand how it works except for the fact that it does work and achieve the result it sets out to do. With our toolkit not requiring that be checked anymore, we're doing our part to secure your deployments and environment by not requiring you opt into it anymore.

The last part where we simply close out processes that we cannot ask the user to close is not ideal at all, however it really is a stop-gap until we get that multi-session environment support going, which will help with your current requirement also.

@Tropheusman

I do thank you for responding already to my somewhat silly messages. I’m sure they often come off as low-level ramblings.

The silliest messages of all are the ones never typed and asked. You've got a legitmate use case that's not working as it did previously and you want to know more. There's nothing silly about that at all.

[Tropheusman]

@mjr4077au

It might be a common practice in your environment, but this is the first report I've seen of such a situation. Usually the only problem that's arisen from the new client/server setup is people placing services in the CloseProcesses list, which if you think about it is silly as why would you ask the user to close something they have no chance in hell of being able to do.

“It might be a common practice in your environment, but this is the first report I've seen of such a situation. “ - I am unsure how you have not seen this before. I could be wrong, but I think either in your documentation or in a thread somewhere I read that you must initiate the toolkit as SYSTEM, which is elevated. Having one account to logon, that has very little rights, and one to elevate, is a way of securing the environment. If my logon account was compromised, the malicious actor would not be able to do much. They would also need my elevated account and credentials, which doesn’t have logon rights, to do any real harm. The likelihood of getting both would be slim.

I would ask you confirm these findings from my testing.

So, my thought process here was what would happen if the user had say Notepad running elevated, but not at all running as the logged on user. What would happen if I opened another instance of notepad as the user, then ran the installation from a system command prompt (pwsh -ExecutionPolicy Bypass -file .\Invoke-AppDeployToolkit.ps1) using the Show-ADTInstallationWelcome cmdlet (Show-ADTInstallationWelcome -CloseProcesses $adtSession.AppProcessesToClose -AllowDefer -DeferTimes 50). When I chose “Close Apps & Install”, low and behold, it close all instances of notepad, not just the ones as the user. So for me, in my testing your comment did not hold true. The user, in this scenario, indeed was able to close elevated, and their own, notepad instances. And, if this holds true for you as well, then why not change the Show-ADTInstallationWelcome cmdlet to prompt the user for elevated processes as well.

So, the way I could make the Show-ADTInstallationWelcome to work as I need it to, is to check and see if the process is not running as the user, but running elevated, then use Start-ADTProcessAsUser to open a new Notepad process as the user, but hidden, then just running Show-ADTInstallationWelcome as normal. This would close the user process and the elevated process for Notepad.

Hopefully that all made sense, and hopefully you, or someone else, can confirm what I am experiencing.

[mjr4077au]

@Tropheusman

I am unsure how you have not seen this before. I could be wrong, but I think either in your documentation or in a thread somewhere I read that you must initiate the toolkit as SYSTEM, which is elevated. Having one account to logon, that has very little rights, and one to elevate, is a way of securing the environment. If my logon account was compromised, the malicious actor would not be able to do much. They would also need my elevated account and credentials, which doesn’t have logon rights, to do any real harm. The likelihood of getting both would be slim.

Just to clarify on this, it's not that I haven't seen people running elevated processes as another account, that in of itself is quite common. What isn't common in my opinion is end users doing this. Usually it's something relegated to admins who run daily driver accounts but elevate management tools, etc.

@Tropheusman

So, my thought process here was what would happen if the user had say Notepad running elevated, but not at all running as the logged on user. What would happen if I opened another instance of notepad as the user...

It wouldn't work in the way that you think. The code retrieves processes via [System.Diagnostics.Process]::GetProcesses() and you can only retrieve process information for processes you can access (either your own, or if you're admin, anything). It'll allow you to close your own notepad.exe process, but not every other notepad.exe process.

You'll probably have to wait for [Feature] Improve client/server experience on multi-session operating systems (terminal services, AVD, etc). · Issue #1536 · PSAppDeployToolkit/PSAppDeployToolkit · GitHub to do what you want to do, as the rework we have intended for this will solve your issue also because we'll likely move process closing code back to the SYSTEM process, then have the SYSTEM process tell the client what to display for closure. That way, even if it's an elevated process, SYSTEM will get it and if it's in your session even if running as another user, we'll be able to show it.

The above is earmarked for 4.2.0 and the desire is there as I really want to get open issues as close to zero as possible, however I'll be honest it's not the highest priority issue on my list to solve and I'm probably reaching a level of burn out for this release. We'll have to see how we go but if it's not in for 4.2.0, it'll be in for 4.3.0.