Mac Admin

Submit Jamf inventory update on OS changes

Over the years, Apple have released a number of new and helpful profile payloads such as PPPC, System Extensions and the like. Each of these had a minimum OS required for them to work. Mac Admins soon realised that if these settings were deployed on an OS that doesn’t support them, they’ll often not take affect if the device was updated until they were redeployed.

What was needed was something to flag and trigger the installs as soon as the device was updated. In this post, I’ll share a short script I used to achieve this with Jamf Pro.

The problem

It seemed this was an issue with an easy answer: scope the deployment of OS-specific profiles to smart groups of devices that meet that OS. For example, to deploy a PrivacyPreferencesPolicyControl payload to only macOS 10.14 or newer devices, I would set a target smart group that selected those devices. Rinse and repeat for any other OS-specific payloads.

Simple right? Well not quite.

Until very recently, Jamf Pro only used OS version data collected by their jamf agent for version comparison in smart groups. This meant the device would need to be updated / upgraded, then submit an inventory whenever the next trigger was hit before it received the profiles. These profiles could manage a variety of items including some to suppress and affect the user experience, and others that are required for security tools to operate. You’d really want these down ASAP!

Most Jamf Pro customers have their Jamf inventory submission (or “recons”) set to once per day, or once per week. So you could be waiting anything from almost 24 hours, to almost a week for this profiles to be deployed (depending on your configuration).

This isn’t great for many enterprises…but there are a few possible options to get around this:

Option 1: Submit an Inventory on the recurring check-in

So one solution would be to have all of your devices submit an inventory update on the recurring policy check-in – by default this is every 15 minutes. This is considered a very bad practice for many reasons, including:

  • The inventory submissions are not hugely intensive (depending on what Extension Attributes you have written) but they will take up some extra resource as they run. Having this happen every 15 minutes would make for a poor experience for your users
  • The inventory submissions do collect a fair amount of data (again, this can vary depending on what Extension Attributes you have written) and so having these run so frequent will grow and bloat the database, causing performance and stability issues.

TL;DR – Don’t do this

Option 2: Have an Inventory submission at every start up

This is not a bad option, as devices can’t install an OS update without a reboot*. However it is possible that this might be missed if the device doesn’t have network/Internet access very shortly after boot. This means there is no guarantee it’ll complete when you need it. Additionally this can submit lots of unnecessary inventory updates – how many times does a device restart and not install an update (and therefore not need to let Jamf know of a new OS version)?

This is a pretty good idea if you’re aware and happy to work with the limitations above.

Rich Trouton has a great blog on configuring this to work around most of the above issues which can be found here. Their blog was also what inspired me to get off my backside and complete this write up!

Option 3: Crack out the scripting tools!

So I ended up knocking up a Launch Daemon and script to solve the problem for us.

The Launch Daemon simply triggers the script at every boot. The script itself will:

  1. Create and update a logfile at /Library/Logs/Management/updateJamfOnOSChange-1.0.log
  2. Check a local file (/Library/Preferences/org.macadmins.macoscheck.plist) for the “LastOSChecked” key:
    • If this is present and matches the current booted OS, exit the script nicely
    • If this is not present, or differs in any way from the current booted OS, continue.
  3. Use the Jamf binary’s checkjssconnection option to try to contact the device’s Jamf Server for up to (roughly) 5 minutes
    • If this fails to get a positive connection within 5 minutes, exit the script with an error (exit 2)
    • If this connection, continue
  4. Submit a Jamf recon / inventory update and collect the exit code
    • If this fails, exit the script with an error (exit 3)
    • If this is successful, update the local file’s “LastOSChecked” key with the current booted OS
  5. Exit the script

This process:

  • Allows the script to exit very early on in the vast majority of cases (normal device boot not following an update)
  • Wait for roughly up to 5 minutes for a valid connection to the Jamf server (allowing some time for the devi e to get a connection, but not forever)
  • Check if the recon is marked as successful or not
  • If any of these fail (Jamf server is not contactable, or the recon fails) the local file is not updated, meaning the script will be triggered again on next boot.

This has proved helpful with our Mac estate for the last 6-9 months and so I thought it’d be worth sharing!

Where can I find this?

I have uploaded a copy of the script to my GitHub page here. I have also uploaded an example of the Launch Daemon I’ve used here.

You may have noticed the layout of this error of my repo is a little unusual. That’s an attempt to make it a little easier to build a deployment package out of! Some assembly required:

What about Declarative Management?

So with the release of macOS Ventura, macOS devices enrolled in an MDM can push information updates to the MDM solution without being requested. One of these items is the current OS version. Jamf Pro added support for this in version 10.42. More on this can be found in Jamf’s documentation here.

Now this would cover the use case I’ve detailed above, however we continue to use our solution as:

  • We have had this in place before the release of macOS Ventura and Jamf Pro 10.42
  • Our solution will submit an entire inventory, not just a few items that Declarative Management can currently do
  • Our solution is separate from the MDM protocol and so acts as a second redundant tool in the event that the MDM Declarative Management option doesn’t work as needed.


In this post, I’ve been able to share a solution to running Jamf inventory submissions as quick as possible after an OS change but only if required.

A reminder from my last post: A special note to say that I will be speaking at 2023’s MacADUK conference, being held in May in the lovely Brighton, UK. No I’m afraid I won’t be resuming my Adobe sessions but something a bit different. Grab your tickets here! I’ll do my reasonable best to buy anyone a drink there who mentions they got to this point in this post.  

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace in Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

* – Ignoring the new Rapid Security Response!


One thought on “Submit Jamf inventory update on OS changes

  1. Stephan Peterson says:

    I love this, first of all. Looking through the source though it seems to key off of productVersion versus buildVersion. It would seem to me that using buildVersion would be more future-proof in that when we get to the place where the productVersion doesn’t change but the buildVersion does, the script wouldn’t be as effective. I’m thinking of the situation we had with Catalina where 10.15.7 was the version for quite some time, and still is, but the Security Updates would increment the build version.


Comments are closed.