Skip to content

01 Creating a UEX Policy

Ayla Abbott edited this page Feb 16, 2020 · 2 revisions

Basic Principles

  • With the conversion to running UEX from the Jamf server there are several benefits:
    • All UEX Policies utilise the same scripts
    • The behavior is dictated by the parameters provided
    • Self Service and deployment refer back to the same UEX Trigger/Recipe
    • The Policies can install multiple packages
    • As new features release, all UEX polices will have them automatically

1) Creating the Recipe Policy

  • Create a policy scope to all computers
  • Set the Frequency to Ongoing
  • Check and set the Custom Event Name to something that works for you
  • Add the script 00-UEX-Jamf-Interaction-no-grep.sh
  • Configure the settings required

2) Script settings

All script parameters are Limited to 256 Characters due to a limitation within Jamf Pro

Vendor;AppName;Version;SpaceReq

  • Identify the Policy with vendor name of app and version
  • This is the vendor, name, version number, and space required for for the applicaiton to install.
  • Must be separated by a semicolon **;** with no spaces between the variables.
  • There can be spaces in the variables themselves.
    • Good example: Microsoft;Office 2016;15.30
    • Good example: Google;Chrome;55.13.123
    • Bad Example: Microsoft_;Office 2016; 15.30
    • Bad Example: Microsoft :Office 2016; 15.30
  • Now with v4.1+ you can add the number of GB as in integer to this parameter. more info
    • For Example "Apple;macOS Mojave;10.14.4;20"
    • Another example "Adobe;Illustrator;19.2;5"

Checks

  • Not case sensitive
  • This is where the actions are set for how the UEX will behave.
  • There are many combinations for the UEX behavior depending on the requirements for the changes.
  • See 09 Checks...All the Options for UEX for more information as well.
  • Must be separated by spaces
    • Good example: Quit Restart ssavail
    • Good example: Restart power
    • Bad example: Quit;Restart ssavail
    • Bad example: Restartpower

Apps for Quick and Block -- (only if quit or block are options)

  • Case Sensitive
  • This is the list of applications that require interaction for successful changes.
  • Used for Quit & Block checks
  • Must be the name of the .app
    • Good Example: Safari.app
    • Bad Example: Safari
  • Each application be separated by **;** with no spaces before or after the **;**
    • Good Example: Google Chrome.app;Safari.app;Firefox.app
    • Bad Example: Google Chrome.app_;Safari.app;_Firefox.app

InstallDuration - Must be integer

  • This is the time in minutes for how long it takes to complete the changes.
  • Measured by the duration that it takes to install on a hard disk drive based Mac.
  • A slow VM is also sufficient for measuring.
  • Must be rounded down to the nearest integer. No decimals.
    • Good Example: 15
    • Bad Example: 3mins
    • Bad Example: 4.5
  • As of v5.0 there is an option to halee the time for installation automatically if the computer has an SSD. If you want to leverage this you can set the setting halveInstallDurationForSSDs to true in the script halveInstallDurationForSSDs
    • Primary use case is if you have a mix of older and newer Macs.

MaxDefer;DiskTicketLimit

  • The first number is the maximum number of general Postponements.
    • This is the number of times that the user can delay changes on their computer requiring interaction.
  • The second number is the number of times you want the user to be notified they have insufficient space before the chosen service desk ticket workflow is kicked off. (optional)
  • Must be an integer
  • Recommended defaults should be 3
  • The critical check will override the the number of deferals to 0.
  • Using 0 with the check notifycan be used to just give an acknowledgement messages or notices

Packages separated by semi-colon -- (only if there are packages to install)

  • Case Sensitive
  • These are the PKG file names that are cached before the changes that install after the user approves the changes.
  • Must be the full file name
    • Good Example: Google Chrome-55.0.2883.75.pkg
    • Bad Example: Google Chrome-55.0.2883.75
  • Multiple PKG files must be separated by a semicolon **;** with no space before or after the **;**.
    • Good Example: Google Chrome-55.0.2883.75.pkg;123GetIP.pkg
    • Bad Example: Google Chrome-55.0.2883.75.pkg;_123GetIP.pkg

Trigger Names separated by semi-colon

  • To mirror the native Jamf Pro Policy considerations...With v4.1 This is NO LONGER CASE SENSITIVE
    • Everything is turned into to lower case in the processing of the parameter.
  • This is meant for the Custom Event name (aka trigger name) of the UEX policy.
  • Can have additional triggers added to trigger additional policies once the user approves the changes.
  • For example, change to the dock or other policies.
  • The first trigger name must be the UEX policy.
    • Good Example: uexpolicy;firsttrigger
    • Bad Example: firsttrigger;uexpolicy
  • Multiple triggers must be separated by **;** with no spaces before or after the **;**
    • Good Example: uexpolicy;firsttrigger
    • Bad Example: uexpolicy;_firsttrigger

Custom Message -- (optional)

  • Used to add additional messaging to the UEX Dialog
  • Example: This software is a browser
  • Example: You are awesome
  • A great use for this is to make custom messages for login or other interactions the user might need to do like setting up an app. See the checks custom and notify for some examples.