Our SecOps team is asking us to create a method of displaying a message to users that the user would have to "ok" on to signal it has been read. Now we all know that doesn't mean it was actually read, BUT hey... that's what they want.
I know there's a fairly basic way of invoking jamf helper, but I can't find it and I'm not remembering. It would be nice if the script can be changed easily in a policy as they are wanting it to be updated weekly. Anyone know?
There's both jamfHelper and the Jamf binary itself that can do this. The latter is more simplistic and you have less control over how the dialog looks, but scripting it is a bit easier than jamfHelper (not that jamfHelper is hard to use mind you)
Here's how to do it with the Jamf binary:
/usr/local/bin/jamf displayMessage -message "Hello"
It looks something like this-
With jamfHelper, you can do something like the following:
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType utility -description "Hello" -button1 OK -defaultButton 1
Which would look like this-
Thing to keep in mind is that the icon for the jamf binary message can't be changed, at least not easily. With jamfHelper you can add an image which could be something like your org logo, to make it look official. To see all the options and how to use them, run:
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -help
The jamf binary message looks so generic, that if your end users are properly trained to avoid spam/malware clicks, they may not even click ok because it might look suspicious to them.
EDIT: I forgot to add that for the second part of your question, most of the items in the jamfHelper message could be replaced by variables that get populated by script parameters, so all you'd need to do is change the script parameters to reflect any differences in the message you might want. For example, the "description" can be assigned to $4 or $5 or whatever in the script and then in your policy, just change the text out. There is one caveat, which is that there is an upper limit to the number of characters a Jamf parameter can have. I forgot now the exact number, but I think it's 256 or something like that.
Another couple of points to keep in mind. I would test out any messages a few times locally before deploying anything. I say this because jamfHelper is notoriously inconsistent in how it resizes the window to accommodate text. It can display in some funny ways at times.
Also there's no guarantee it will even display all the text. I've run into issues where text for the message gets truncated and there doesn't seem to be any real rhyme or reason as to what causes it. For that reason, it's best to keep the message as short and to the point as possible. Short text never really gets chopped, but longer strings of text sometimes do.
Another couple of points to keep in mind. I would test out any messages a few times locally before deploying anything. I say this because jamfHelper is notoriously inconsistent in how it resizes the window to accommodate text. It can display in some funny ways at times. Also there's no guarantee it will even display all the text. I've run into issues where text for the message gets truncated and there doesn't seem to be any real rhyme or reason as to what causes it. For that reason, it's best to keep the message as short and to the point as possible. Short text never really gets chopped, but longer strings of text sometimes do.
THIS. I've had many occasions where created/tested locally these dialogs only to have people calling complaining about various glitches with them when delivered from the JSS. Maddening, like many things.
Below is how we assist our users with a "nag" to run their updates, but we have adapted it for many other uses. Call and kick off a policy, Notification, Run a small script. Possibilities are endless. I just wanted to make a popup box that made a user click something and if they didn't have time today, I scope it to hit them daily with an exclusion of whatever the the desired outcome of said action would be if they click run, ok, yes etc... Also pre-deploy your company logo into the path and it will give use that when it pops up for the users.
#!/bin/bash loggedInUser=$(stat -f%Su /dev/console) jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper" windowType="hud" description="There is a critical security update available for your Company issued computer. To perform the update, select 'UPDATE' below and the security update will begin to run. This update can take upwards of 35 minutes. If you are unable to perform this update at the moment, please select 'Cancel' to be prompted again tomorrow. Want to install the updates on your own time? Navigate to System Preferences --> Software Update *Please quit out of open applications and save all working documents before selecting 'UPDATE.' If you require assistance, please contact the Helpdesk by phone at (***) 867-5309 or by email at helpME@derp.com." button1="UPDATE" button2="Cancel" icon="/Library/Application Support/JAMF/JamfCustomApps/Company_logo.png" title="Critical: Apple Security Update Available" alignDescription="left" alignHeading="center" defaultButton="2" timeout="900" # JAMF Helper window as it appears for targeted computers userChoice=$("$jamfHelper" -windowType "$windowType" -lockHUD -title "$title" -timeout "$timeout" -defaultButton "$defaultButton" -icon "$icon" -description "$description" -alignDescription "$alignDescription" -alignHeading "$alignHeading" -button1 "$button1" -button2 "$button2") # If user selects "UPDATE" if [ "$userChoice" == "0" ]; then echo "User clicked UPDATE; now downloading and installing all available updates." # Install ALL available software and security updates softwareupdate --install --all # Present user with 60 second countdown to restart computer; user may opt out of restart osascript -e 'tell app "loginwindow" to «event aevtrrst»' # If user selects "Cancel" elif [ "$userChoice" == "2" ]; then echo "User clicked Cancel or timeout was reached; now exiting." exit 0 fi