Our application is installed on devices where the user will typically not have administrator permissions.
We are currently using a system task to allow updates, but if the user has the program open it can cause a reboot and can cause issues by modifying resources we are using which is undesirable. Forcing the application to close is not the path forward we would like to take and using suppress reboots will still cause the strange behavior when the user is still using the app.
As a mitigation, I have added a small powershell script which will wait for the program to close before continuing and failing the install if it's been open for an hour so as to not waste resources. (As a side note, the updater does not appear to fully close after failing in the powershell script, so the user has to reboot before it will try again. Is this expected?)
Is there a better way to wait for the user to stop using the app?
Can we wait for user input/display progress and status, or does a system task have no way of communicating with the user?
We are currently using version 15.6 with an Enterprise license.
Our update process is to uninstall the previous version, then install the new version.
Suggested Articles
-
JohnCountouriotis
- Posts: 1
- Joined: Mon Dec 23, 2019 7:14 pm
Re: Undesirable behavior with system task updates
Hello and welcome to our forums,
When launching the updates setup under System account I am afraid that there is no way to get user input nor to interact with the user. Thus I am not aware of any other better approach than the one you already tried to implement. Using a script during the installation that will check your application process state and continues or fails the installation accordingly should be a correct approach.
In what regards the updater keeps running after your updates process fails behavior, this is not the expected behavior. The only case I am aware when this behavior occurs is if your updates setup triggers any UI while running under System account. This way the process of your updates will hang indefinitely waiting for user input (but no user input could be propagated to System account) and thus the Updater process will hang too waiting for your updates setup to finish its process.
To check if this is the case, you can run a silent installation command for your updates under an administrator account on a test machine while your application is open and make sure no UI is spawned.
Let me know if this helped.
All the best,
Daniel
When launching the updates setup under System account I am afraid that there is no way to get user input nor to interact with the user. Thus I am not aware of any other better approach than the one you already tried to implement. Using a script during the installation that will check your application process state and continues or fails the installation accordingly should be a correct approach.
In what regards the updater keeps running after your updates process fails behavior, this is not the expected behavior. The only case I am aware when this behavior occurs is if your updates setup triggers any UI while running under System account. This way the process of your updates will hang indefinitely waiting for user input (but no user input could be propagated to System account) and thus the Updater process will hang too waiting for your updates setup to finish its process.
To check if this is the case, you can run a silent installation command for your updates under an administrator account on a test machine while your application is open and make sure no UI is spawned.
Let me know if this helped.
All the best,
Daniel