Set up a policy to push the 10.13.5 update, uploaded the combo .pkg file to our repo so jamf can just prompt the user for its install without bothering them with the App Store process. But some of my test users reported that they already had the 10.13.5 update applied and were still getting the prompt. But I made sure to restrict the policy by telling jamf to only offer it to computers that the App Store flag as needing it. Suggestions?
I would set up a smart computer group with the criteria 'Operation System Version', operator 'less than' and value '10.13.5'.
You can limit the 10.13.5 combo patch to specific computer groups and select the one you've just created. Jamf won't bother anyone that's already had the update then.
For us that isn't an option @davidacland but trust me I wish it were the case. In any event I think I've locked down one issue. At some point our users were told to update their macOS via the App Store and for whatever reason the computer didn't check back in with JSS to report its version. I've identified at least three computers running 10.13.5 that JSS thinks they have various flavors of 10.12. What is confusing is the JSS is set to have computers report in every 15 min. Ideas?
I'd suspect an issue with the client's connection to the JSS. Are the affected Macs checking in at all after the upgrade?
If you run a few commands on the client, like
jamf recon and
jamf checkJSSConnection and
jamf manage, that might give you some more info.
Well your computers do check every 15 minutes whether there are any applicable policies, but I guess they report inventory updates probably once a day or once a week. So it might take a while after the updates are installed before the inventory is updated.
My last user to get 10.13.5 called me today to run the update MacOS said it required. App Store said it was needed & when checking, it went away. Checking "About The Mac" it had been applied since the system had been rebooted already. Weird bug on Apple's end.
In general, I recommend you get used to "control scripts" to manage deployments so you can add some logic to them. Installing packages without validating they are needed or installable leads to all kinds of potential issues.
You'd do this by having two policies: one policy which runs the control script, and then that control script runs a policy with an event trigger once it determines the installation is appropriate for that system. Relying on inventory data works most of the time but there are exceptions for timing (since inventory data is not live) and recon failures.
You can probably skip the —install part and just use the inventory collection settings in Jamf to include available software updates (its off by default).
You can then see what updates will be applied in the computers inventory.
I’d only use —list on one Mac running 10.11 to reassure yourself that it isn’t going to upgrade to a newer major macOS release.