Skip to content
Branch: master
Find file History

Readme

A Kinder macOS Update

*******************************************************************************************
A workflow for more user intuitive macOS updates.  Allowing the user to defer updates to 
a more convenient time after updates become available, while allowing for greater assurance
that security updates are being applied to IT.
*******************************************************************************************

This script is designed to be used with Jamf pro, a Self-Service policy, and a local 
launchd agent to ensure updates are checked for daily.

**Requirements:

   • Jamf Pro
   • A logged in user
   • MacOS Clients 10.13 or later (testing prior to 10.13.4 has not been performed)
   • Composer

**Why I built this:

Jamf, at the time of this writing, did not have a good deferral process for 
Apple OS updates in my opinion.  Not only had Apple introduced a new reboot state 
into their post-update reboots that Jamf had not integrated yet, but Jamf's baked in
deferral process only allowed a user to defer up to a date. Requiring a Jamf Pro admin to 
go out and set up a new deferral date when the next update became available.  These scripts
work as 2 halves to a solution. Both parts assume you have Jamf Pro to make it work.  
If you are using another MDM some shimming to match their features will be required.  Each 
time the deferral script is run it checks if there are any updates available and, if 
updates are found, the deferral script will nag the user to allow the updates to be installed.  
As any IT person can attest though, there needs to be some teeth so the deferral script allows
for only a set number of deferrals before enforcing the updates anyways.  The updates are 
installed by triggering a second Jamf policy that uses Apple's command line OS update tools.

**Configuring the process:

1. Pick a place to store the local components.  (example: the logs and icon)
   a. I chose /Library/Application Support/MyOrgName, but you can pick anywhere that launchd
      can reach.
2. Pick a place to store the logs for both the deferral script and the update script.
   a. I choose /Library/Logs/MyOrgName but as long as it is a permanent location that you can
      remember to look back to when/if something goes wrong then it should work for you.
3. Pick/make an icon to be used by the hud windows.
4. Pick a custom trigger name to input into your deferral script. (I used AppleUpdateScript)
5. Edit both scripts’ variables section to record your homes for the above. (Logs, Deferral 
   script location, icon location).
6. Package up all pretty in Composer the icon and new log folder.  This package will need 
   to be pushed to all Mac's running the script or else the icon and logging won't work as
   you expect.
7. Upload your edited SoftwareUpdate4.sh and AppleUpdateDefer1.sh scripts to your Jamf Pro server.
8. **Optional** Create a smart group in Jamf Pro based on available updates.
   a. The condition for group membership should read: "[Number of available Updates] is [greater than] [0]"
      • This will let you scope the daily policy to only machines that need updates.  This is kinder
        to your MySQL database and will help keep your logs smaller on ther Jamf server.  It however
        may delay deployment of the defer script until after the machine updates it's inventory to be
        evaluated into the smart group.  This is dependant on the frequency of how pften you update 
        computer inventory.
9. Create 3 policies in Jamf Pro.
   a. Software Update Script execution policy.
      • It should have a custom trigger that is input into your deferral script
      • This policy will execute the SoftwareUpdate4.sh script.
      • You should consider letting this policy be triggered from Self-Service as well.
        Allowing it to be executed from Self-Service will allow users to start the updates
        whenever they want (aka when it is more convenient), not just when the nag annoys 
        them mid-morning.
      • Scope this policy to "All Computers"
   b. A policy to push and install the .pkg you packaged earlier in composer.
      • This policy should be set to run once per computer at check-in.
   c. A policy to run the defer script daily.
      • The Execution Frequency should be set to "Once every day"
      • It should execute the AppleUpdateDefer1.sh script.
      • You should consider client side limitations based on day and time.  This will prevent
        updates from kicking off over night on mac check-in if a user leaves their computer
        on overnight thus missing the 4 hour nag prompt.
      • You should consider scoping it to the optional smart group above.  Otherwise use "All Computers"

**Stuff I am still working on:
   • Getting the script templatized correctly to accept config changes from a profile 
     distributed from Jamf Pro.  The deferral script is almost there, AppleUpdate4 is not.
   • Bug testing
   • Inserting API work into the deferral script to update JSS that the script is failing.
   • Getting the Deferral LaunchAgent working as a Daemon with bash detecting if a user is logged in and
     behaving in predictible manners.  
   • Also hope to add the ability to clobber and reboot macs with AFK users while still providing deferral
     for logged in users in the LaunchDeamon conversion.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
You can’t perform that action at this time.