Casper - Third-Party Software Patching Deployment

Deploying

These software packages allow updating a live application. This is not recommended as it could result in data loss or cause a program to become unresponsive. This section will guide you through utilizing a script that will first check to see if an application is closed before installing the related update.

Step A: Cloning the script for use in your DLC

Navigate to the scripts section located within the Full JSS site in Casper and locate the script called ThirdPartyUpdate.

Press the Clone button to clone the script into your specific DLC site. You will need to change the name and category of the script. It is recommended to use the related DLC acronym as a prefix in the name (i.e. DLCThirdPartyUpdate).

Step B: Creating a Smart Group for Scope

Smart groups are used to allow you to target which computers will be receiving the updates. This example below is for Microsoft Outlook. It is recommended to use the related DLC acronym as a prefix in the name (i.e. DLC Office 2016 – Outlook Update)

This helps to ensure that computers which already have the patch installed do not receive the software update again. It also helps to ensure that users running a newer patch do not receive a lower version.

Step C: Creating the Policies

This involves creating three (3) policies per Third-Party Software Package.

Policy 1: Configure the software package install

Create a new policy within your DLC

Under General set the name of the policy and set the category.

For the Trigger select Custom. Enter a Custom Event name for the trigger. This name will be used in policies 2 & 3 to install the package. It is recommended to use the related DLC acronym as a prefix in the name (i.e. dlcupdateoutlook). Execution frequency should be set to Ongoing.

Under the Packages payload add the related third-party update package and select install under Action.

Configure the Maintenance payload to Update Inventory

Set Scope using the Smart Group created in Step B

Optional: Restart options will be created automatically in Casper using the default options to restart if a package requires it. You can adjust or remove restart options if necessary. You can also use the User Interaction section to provide messages to the end user before and after the policy runs.

Policy 2: Set the script to run automatically

Create a new policy within your DLC

Under General set the name of the policy and set the category.

For the Trigger select Recurring Check-in and set the preferred Execution Frequency. (Once every day is recommended). Optional: You can also set client side restrictions if you only want this policy to run during certain times.

Under the Scripts payload select the script you cloned in Step A.

The priority of the script can be set to either before or after since the script is the only item in this policy.

Under Parameters Values you will need to enter the Process Name of the application you are updating. This name can be easily found using Activity Monitor within macOS.Note: The process name is case sensitive. There is an exception to this with the Firefox browser. Within Activity Monitor Firefox will be displayed with a capital “F.” For a policy using Firefox you will want to enter the Process Name as firefox all lowercase. You can also specify multiple programs in this parameter using the pipe (|) separator. i.e. firefox|Safari will check if either firefox or Safari is running before applying the update package. This can be helpful for updates such as Adobe Flash etc.

Under Custom Event enter the name you established in Policy 1 step 3

Set Scope using the Smart Group created in Step B

Optional: Restart options will be created automatically in Casper using the default options to restart if a package requires it. You can remove restart options.

The policy in this example will then check in once every day to see if the application that needs to be updated is running. If it is running nothing happens. If you were to check the logs you would see the following:
If the application is not running the script will trigger the custom event name you specified in Policy 1 and install the update. A successful installation will be displayed in the logs. Since Policy 1 was set to update the inventory after the package is installed, the computer will now be removed from the smart group.

Policy 3: Set the script to run via Self Service

Clone Policy 2

Under General set the name of the policy and set the category.

Uncheck all Trigger options and set the Execution Frequency to Ongoing

Set Scope using the Smart Group created in Step B

Within the Self Service tab check to make the policy available in Self Service and setup things like button name, description, icon, and category assignments.

Optional: Just as in policy 2 the default restart options can be removed.

The reason this third policy is created is to allow the updates to always be available to end users in Self Service. Policy 2 allows us to set things like client side restrictions and once every day for execution frequency. If we combined the polices using these options, the Self Service installers would only be available during those times. This policy performs the same tasks as policy 2 to check if an application is running before applying an update.

Policy Maintenance

Note: Best practice is to always test newly uploaded packages in a test environment before updating your department’s production environment.

As new software updates become available and have been successfully tested, you will only need to adjust the following items in Policy 1:

Remove the older update package and add the new update package

Update the smart group to reflect the new update version numbers so computers are added back to scope for the new update.

Rarely will you need to adjust Policies 2 & 3. You will only need to adjust polices 2 & 3 if you want to change scope, trigger, or execution frequency/restrictions. You will not need to adjust the Parameter Values of the script unless you change the custom event name set in Policy 1 or the third-party vendor changes the process name of the application.