Posted on 02-08-2023 11:44 AM
This might be a little long, but I'm trying figure a faster way of deploying our monthly patching apps. We currently use 2 smart groups, one listed as members that is using the Patch Reporting Application and set it to Latest version. The second group includes the members group and the deployment group like alpha, beta, etc. In the application deployment policy, we point to the update group and set it to ongoing. When it gets updated, it drops out of the list. That works fine, but I tried creating another smart group that includes the monthly patching update groups hoping it would work the same. When I look the list of groups in the console, everything looks good, but even though the update group shows 0 devices, it still pushes the application. For example, Rectangle doesn't have any devices reporting Rectangle, but it's still deploying it.
Here is how the smart groups are added.
Posted on 02-08-2023 11:54 AM
I am using this script to run the triggers for the policies that have the new apps smart group added.
#!/bin/bash
###
#
# Name: update-all-apps.sh
# Description: Cycles through all third party updates in Jamf and runs them if
# needed by the target Mac.
# Author: Emily KW
# Modified: 2019-01-23
# Notes: Results/output sent to /var/log/jamf.log.
# Does not include patch policies. The final recon, however, will by
# default check for patch policies, but will not run them automatically
# unless you configure patch policies to install automatically.
#
# Usage:
# - Set any update policy in your Jamf Pro Server with a custom trigger
# - Add all custom triggers on separate lines to the APPUPDATE section
# - Add this script to a policy with its own custom trigger and/or
# make available in its own Self Service policy for people to use
#
# Room for improvement:
# - Close each app if the update is required.
#
###
jamf=$(which jamf)
jamfLog="/var/log/jamf.log"
# currentUser=$( python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "\n");' )
timestamp () { date "+%Y-%m-%d %H:%M:%S" ; }
echo "$(timestamp) Checking for third party app updates..." | tee -a "$jamfLog"
APPUPDATE="
UpdateAdobeAcrobat
UpdateAdobeCC
UpdateAdobeReaderES
UpdateBox
UpdateWebex
UpdateWorkspaceUniversal
UpdateDisplayLinkManager
UpdateChrome
UpdateEdge
UpdateTeams
UpdateFirefox
UpdateRectangle
UpdateSnagit
UpdateZoom
updatesafari16.3
"
for TRIGGER in $APPUPDATE
do
echo "$(timestamp) Checking for update policy $TRIGGER" | tee -a "$jamfLog"
"$jamf" policy -event $TRIGGER -forceNoRecon -randomDelaySeconds 0 | tee -a "$jamfLog"
done
echo "$(timestamp) Submitting updated inventory..." | tee -a "$jamfLog"
"$jamf" recon -randomdelayseconds 0
echo "$(times
Posted on 02-08-2023 12:48 PM
@SMR1 Are your policies that respond to the UpdateWhatever triggers scoped simply to All Computers, or do they have exclusions for Macs that don't have the app in question installed? If there's no exclusion they're going to install
Posted on 02-08-2023 01:00 PM
The policies are set for specific computers and users. The new policy I created that I was trying to deploy the script to run the triggers for the, is also specific computers and users. I initially created 2 groups for each application using what I found in the link below and to deploy to test groups, we just add the test groups to them and they drop off when they're updated. Just wanted to have one policy, so we don't have to disable the policy have the apps are deployed. Was hoping to keep them ongoing, but not recurring and then just stop/start the policy that runs the trigger script.