Open Apfelpom opened 9 months ago
Can you check out if the new deferrals and AAP-Activator script may help you out?
@Apfelpom , with the latest version 2.0.3
there will be an additional check for the installed app version. For your workflow may I suggest to re-run discovery each time, you can set the interactiveMode
to 1
so the user will only be presented with the apps that indeed need updates at the time of discovery. You can keep prompt_user
as the blocking process since you can now pass in your own Installomator labels into a Jamf Pro Script parameter.
The deferrals and the APP-Activator-script, as well as all additions since version 2 are great. Thank you all for your work! (and sorry to be late)
If, as you recommend, we do not perform discovery interactively and installation interactively, users will have to wait until the closed applications that do not require interaction are updated. Hence the idea of running AAP silently and a second time interactively when the user has really to take a decision and click a dialog.
Moreover we want the discovery phase to run as little as possible, as it takes up time and energy. During our first run of APP, all applications that are closed are updated without interaction. Open applications still need their update.
If we start AAP a second time without discovery and with interactiveMode 1, all already installed updates of closed applications are run through. This is fast, because Installomator determines the last version beforehand, but it takes more effort than necessary and on screen time.
Hence the desire to fully evaluate the results of the first run and obtain a list of applications that really need updating, which updates can be run interactively in a second run of AAP.
The https://github.com/robjschroeder/App-Auto-Patch/issues/48 issue shows that I'm not the only one who wants to run discovery and silent patching. I think it would also be an improvement for APP-Activator to know that after a silent run, the list of applications to be updated has been cleaned up, so that a new discovery or an interactive run is not necessary.
BTW: To speed up APP (significantly), I have been toying with the idea of reducing the list of Installomator labels to the actual list of our software. This could also be an option of APP to ignore Installomator labels of never installed software, provided APP has already run once.
With the goal of inconveniencing stressed employees as little as possible with app updates, we consider running AppAutoPatch twice.
In the first run, we update all apps that are not open with the options
interactiveMode="0"
(completely silent),discover="true"
andBLOCKING_PROCESS_ACTION="silent_fail"
. During the discover phase, the labels are written to the plist that Installomator runs.The second pass is to update only the apps where Installomator aborted the installation because there would have been user interaction. This time, so that interactive patching can be started at the push of a button, we choose
interactiveMode="1"
,discover="false"
, andBLOCKING_PROCESS_ACTION="prompt_user"
. But the plist still contains all labels, even the ones for which Installomator has applied the update.Hence my suggestion to include an option that removes labels with
"All done!"
from the AppAutoPatch.plist. This way the second pass would only bother the user to install opened applications.