Prompt user to close program

[mmelkersen]

It would be very helpful to have a function to prompt the user to close a certain program.
Feel free to look into PowerShell App Deployment toolkit how it does that, and use e.g. ServiceUI.exe to prompt outside the system context. https://www.youtube.com/watch?v=2rKVq482nz0

[Romanitho]

Hello, thanks :)
But I wanted to have a tool only based on PowerShell scrpits that everyone could understand. I don't want to user third part tool like ServiceUI cause it would require users to get it as well.
But it can be something we can implement if requested :)

[KnifMelti]

Better with only one command to rule them all 👌
But C:\ProgramData\Winget-AutoUpdate that is static and could be changed when installing...
[Parameter(Mandatory = $False)] [Alias('Path')] [String] $WingetUpdatePath = "$env:ProgramData\Winget-AutoUpdate"

[Romanitho]

Sure, it is an example. It will be configured via the reg settings 👍🏻

Using serviceUI.exe could also make things easier to implement approval feature...

[Romanitho]

This thing is, if ServiceUI becomes an option, should we import it inside Github repo (as it is only 73KB) or should we select the option to install MDT, copy ServiceUI.exe in a safe place and uninstall MDT?

[Romanitho]

https://github.com/Romanitho/Winget-AutoUpdate/tree/ServiceUI

[KnifMelti]

[Convert]::FromBase64String("") maybe...

[AndrewDemski-ad-gmail-com]

..or..
there could be a WinForms-based popup launched via a Task Scheduler executed for BUILTIN\Users, which would present the prompt to close specific processes (with a looped re-check). That implies that someone will need to maintain the list of installdirs.

It can be created purely in PS with some effort.

[Romanitho]

a lot of effort.
It should be written in the winget app manifests. That would be even easier

[michaeljbailey]

I am re-opening up this discussion because this is a huge disruptor for my organization's technical team.

In my opinion, it's unacceptable to have a script that will blindly kill open user programs without at least attempting to ask the user to either close the program, or defer the upgrade to a future time.

Reviewing the options:

• "AllowList" and "BlockList" seem nice, but that just kind of defeats the purpose of this script IMO.
• Changing the time of day or frequency is a non-starter IMO because it's kicking the can down the road. At least for my org, people can be working at any hour of the day.

I see there's concerns about level of effort, which I'm reading as "it's going to take a long time for me to figure out how to do this and I don't have the bandwidth".

That's fine. This is business critical for me, so I'm going to fork, work it out, and open a pull request to upstream the feature.

I also understand that people may be hesitant about giving the keys to users to control updates (who hasn't seen users defer Windows Updates for weeks on end?) so I'm going to design this to be a configurable opt-in configuration that you need to explicitly account for.

If you like it, great - use it. If you find it problematic with users - just don't enable it (selectively or in whole).

For context, this is what I'm going to look to do once I find a sensible place to hook this in:

1. Before a program is updated, we should check for any running application instances.
2. If an instance is detected, we should enumerate the users who have this program running.
3. Whomever has the active logged in user session (ideally this is only 1 user for 99% of cases, but edge cases are important). should receive an interactive prompt that their program is going to be updated.
4. We can give them the option of either skipping the upgrade, or proceeding with install.
5. Some verbiage would also be added to notify the user that they can choose to close the programs, or if there's other users logged in (disconnected state?) They can try to get them to close the program before proceeding.

Step 1 is going to be painful part since every program under the sun uses a different "main program" (or even multiple sets of processes and/or services). If it's not feasible, an alternative is to just add the simple prompt logic of "Proceed with install, yes/no?" regardless of running processes.

If there's concerns about this being too burdensome with prompting too many times, a further enhancement could be to either operate in a "default prompt all" or "default prompt none", with optional config to specify programs that shouldn't prompt (in the default all) or should prompt (in the default none).

[michaeljbailey]

I have a proof of concept working for this.

Below are the details.

TL;DR: You can see the changes on my branch michaeljbailey@02b6d59

Disable re-launching via ServiceUI

ServiceUI attaches to the same user context as a running instance of explorer.

First off, I find this a bit problematic because it's unclear which instance of explorer it picks. I couldn't find any definitive documentation indicating which process it picks to select the right user session. For most use cases, that's fine. Better would be to use something like "query user" and searching for who has the "console" session active and picking a PID that user is running. But - that's not the problematic point!

The problematic bit is that once ServiceUI attaches and launches that new session, it loses SeDelegateSessionUserImpersonatePrivilege.

So my quick & dirty fix (this is a Proof of Concept after all) is to just pretend ServiceUI doesn't exist (lines 112- 113 in my patched Winget-Upgrade.ps1) so that WGAU remains in the process running as SYSTEM with SeDelegateSessionUserImpersonatePrivilege.

Add RunAsUser and the script for prompting the interactive user session

Using https://github.com/KelvinTegelaar/RunAsUser, I inlined https://github.com/KelvinTegelaar/RunAsUser/blob/master/Public/Invoke-AsCurrentUser.ps1 and https://github.com/KelvinTegelaar/RunAsUser/blob/master/runasuser.psm1 into the script Get-UserPromptYesNo.ps1.

This one new script presents a new function Get-UserPromptYesNo which accepts a title and a message to display an old school Windows Forms prompt.

RunAsUser has some pretty cool functions, including running an elevated process in the current logged in interactive user session or as a non-elevated process (I elected for the latter for security purposes).

My use case? I just wanted to display a simple yes/no prompt to ask the user a question. This machinery allows us to present interactive dialog boxes, even with WGAU running in a non-interactive, privileged, console session. Technically, I have the same exact problem I was harping about "picking an interactive session to present a GUI". I have no idea how it selects it, and I suspect it suffers from the same issue that ServiceUI does.

There's some special magic with RunAsUser where I'm using the ExpandStringVariables to allow variables from the process running as SYSTEM to "pass" through to the new process running as the end user. That's all hidden from the API callers of Get-UserPromptYesNo so they just worry about the title, message, and get back whether the user click "Yes" or "No".

Wire up Update-App to give users a choice before updating.

Lines 4 - 19 have my added code to ask the users if they want to allow the specified application to update (and give them time to close it before they click "yes"), or skip the update for now.

Final Results

And that's it... I have to figure out how to manually install my updated version of WGAU from my branch. I originally developed the (3) changes on WGAU 1.21.13 (what my org is currently running) and applied the change diff against the head of my fork.

You can find my changes right here: michaeljbailey@02b6d59

I'm not making a pull request with my current branch, because it's a super raw proof of concept that should have a ton of other considerations.

I'm just putting this up here so I can open up the discussion with @Romanitho if they would even consider going in this direction and merging this functionality in (after some re-work on my side).

If not, I'm going to continue maintaining this fork and will be deploying this as a monkey patch in my org's Intune deployment, since the lack of the feature is causing major pain for our technical teams.

Follow-up considerations

If we were to take this seriously, I'd consider some of the following before submitting a pull request it:

• Adding a mode for "opt-in ask-by-default" (i.e., every update needs user to OK it) with an optional ignore list for packages where it's safe to auto-update.
• Adding an opt-in "prompt me before I update this package" list, so existing users can just selectively pick business critical programs that would be disruptive to their workflow to be auto-updated without asking first. Using this would basically be the same as existing WGAU with certain exclusions
• Inject this somewhat more intelligently and being mindful of the existing "AllowList" and "BlockList" features.
• Test the whole thing and adjust how we maintain the original SYSTEM process -- because I'm pretty sure brute force ripping out ServiceUI (like I did) breaks a bunch of features you added that depend on it. It would probably be better to maintain all functions under the root process and only spawn off individual instances of ServiceUI on an as-needed basis for the features that require it.

Again, I'm putting this out for consideration from the core maintainer here. If there's no interest at all, I'll just keep this privately maintained for my organization.

[KnifMelti]

It looks really promising (tested and verified) if one's desire is to notify users about updates!

I think @Romanitho introduced ServiceUI with this in mind, however ServiceUI drops some bits of computing as we've come to learn (symlink creation and now this SeDelegateSessionUserImpersonatePrivilege) forcing us to make workarounds.
This RunAsUser seems to handle things much better!

So, +1 from me!

But saying this; I'm coming from a large site running WAU now a couple of years where we don't have any problems with our curated included_apps.txt (85+) keeping the applications up to date with Level of notifications: None.
Sure, som application restarting but no lost work (i.e. ServiceDesk haven't logged a single incident over the years, and I as the introducer of WAU would directly have heard).

I think the original problem is the applications themself; being updated with their own installation source should be handled better!
Take UltraEdit as an example. It doesn't matter if it's being updated or not, the session users have open continues to be open.

WinGet could (and maybe has the option now) to check for running processes (but it would be a wild guess as long as the Manifests doesn't require an exe name)

[KnifMelti]

check for running processes

BTW: In #970 I have an Added functionality to skip apps based on running processes in mod templates.

[KnifMelti]

Added functionality

And, in #972 I have added the option to Abort or Postpone WAU before anything is done.
In _WAU-mods.ps1 you could then write your own check if critical applications are active and there's an update for any of them, postponing WAU (or Abort all together).
I recognize the need for something like what you've done, just want to point out possibilities 👍

[panreyes]

I've just heard about Winget-AutoUpdate and I'm surprised this wasn't a part of the core program, as I consider a big issue to have the applications being closed while the user is using them. It might not occur oftenly, but we can't take risks like that. There are many softwares out there: imagine a 50GB Thunderbird Mailbox file being damaged for force closing Thunderbird.exe.

I like the idea of prompting the user, although I would prompt only once for all updates and inform the user that the updates have been completed. I might even end up doing a fork of your fork :)

[Romanitho]

First of all, apologies for my long absence from the project — I’ve had a lot of other things going on recently.

Thanks @michaeljbailey for this very interesting PoC. To answer your underlying point: yes, ServiceUI was originally added to ensure that any GUI prompts (even with silent switches) would still be visible to users. It was a workaround for installers that don’t fully respect silent or quiet modes.

It’s also worth noting that WAU supports “Mods”, which allow custom pre- and post-update actions. This gives admins the ability to tailor update behavior based on how each application behaves in their environment — especially since winget doesn’t currently expose running process info, which makes it difficult to natively detect what's actively in use.

That said, I'm absolutely open to replacing ServiceUI with something better, as long as core functionality is preserved. One idea I’ve also had in the past was to prompt users when updates are pending, giving them the option to proceed or defer — and letting administrators decide whether to delegate that choice to the user or enforce it silently.

In short, I'm open to moving in this direction, as long as we maintain a good balance between automation, user awareness, and administrative control.

Thanks again for the contribution and the discussion.

[darkvoit]

This would be cool to have as Admx template. If program is open, ask user to close it because there will be an update.
In theory is cool but users never approve closing things or even know what they see on the screen and click X button
Most of the time i don't want user interaction and force things up. For example no matter how much time sccm asks for restart, they don't want to restart and i've forced it to ask only a couple of times and then force restart after countdown. If i don't, people won't restart for months.... This is also maybe good approach to ask user for example 3 times and if they click no to force close and update. And the dialogue window to have count how many retries left.
My bad experience with force close is updating openvpn where it drops your connection and you don't know why because i stopped the notifications for updates, but for me is better to be updated, no matter the frustration of closing programs. Maybe if updating a program cause work to be lost but we never had a problem with that for now. Only a little frustrated users xD