thank you @AndreasRumpl and @rtrouton for doing the heavy lifting for the community!

Thank you!

Working 100% here.

I've been considering doing something similar for machines that are not on the proper firmware version per OS. ( See: our large fleet of imaged Macs that haven't been getting firmware updates for years now... )

If anyone would want to do this a different way, given Jamf doesn't recommend so many criteria in a Smart Group, I have an extension attribute to get the Latest OS Supported per Model and Current OS Version.

https://github.com/MLBZ521/MacAdmin/blob/master/Jamf%20Pro/Extension%20Attributes/jamf_ea_LatestOSSupported.sh

Supports El Capitan to Mojave.

Like @MLBZ521 states, having that many criteria items in one Smart Group is not advisable. While I'm sure it "works", it also creates a lot of stress on the server during Smart Group calculation, which happens a lot more frequently than most people realize - basically every time a machine checks in with new inventory, and some other times as well.
Using an EA that simply creates a Supported/Not Supported result is more efficient. It offloads the work onto the client during a recon. You could also have a one time policy run on each Mac that runs a script to determine Mojave eligibility, and then either drops the result into a file that an EA can pick up easily, or even an API script to write the result into a pop up menu style EA. Any of the above would be better than creating a Smart Group with 59 criteria items in it in my opinion.

I'm not so sure if this really causes such troubles for the database like you said. We all use a lot of smart groups for all kind of things and yes, in this smart group are 59 criteria BUT they are just "connected" with OR. So there wouldn't be much difference between one group with 59 criteria or 59 smart groups with one criteria. And in any bigger environment the amount of ~60 smart groups doesn't seem to be unrealistic. I guess an even higher amount would be totally normal.

I agree, the solution with the extension attribute is an elegant way to solve this, but I don't see any real problems if you go the smart group way. If something like this really stresses your database in a critical way, I think it's time to check the database(-host).

And no matter if you do the EA or the SG way, after your environment upgraded to Mojave and/or you got rid of all the clients that are too old, you can stop to monitor this anyway, so it is just temporary.

We've been having some pretty noticeable performance issues in our environment and when I reached out to Jamf, they specifically said:

We normally don't recommend over 10 criteria for smart groups as you will then see some performance issues

The other thing would be, what are you using this Smart Group for? We teach to our Site Admins that Smart Groups are not for Reporting purposes. If they're only creating the Smart Group to see the number in the group, and not using the Group in a Scope some where, we highly request they do not do that.

Our server side environment, resource wise, has more than the recommended resources for the quantity of managed devices (or at least we believe based on what support provided me). Still, if you're not going to use it, it would be better to create an Advanced Search out of the criteria.

Also, for my EA, I have a use for it outside of this as well. I have an macOS Upgrade workflow (script) that can be used to provide a "Self Service" Upgrade to users and/or push a forced upgrade as well. So a Site Admin can scope the Policy to the status of that EA essentially.

Using @MLBZ521's script, but it's showing Mac Pro 2013's as incompatible...
i just looked at a 2013 model, and "/usr/sbin/system_profiler SPDisplaysData" doesn't show metal support, but it's a using AMD Fire Pro GPU's, so i know it's supposed to work.... gonna have to look at script to see if i can tweak...
machines like that show 'High Sierra / OS Limitation,GFX unsupported'

trying to avoid the complex smart group, since it hammers jamf pro to calculate for every machine that checks in

Update: i think i know why--- OS is lower than 10.13.6 on some mac pro 2013's, so it considers it too low... my guess is that this is accounting for firmware patch level?

I use a Smart Group for this but with regex for each model identifier to keep my criteria cleaner and more manageable.

@kstrick

Eh, I didn't specifically test on a MacPro 2013....

Just tested and I see what the issue is for "GFX unsupported". These models report different results on Sierra and High Sierra/Mojave, as well as reporting for each GFX Card installed.

10.12 Sierra:

Supported Supported

10.13 High Sierra/10.14 Mojave:

Supported, feature set macOS GPUFamily1 v3 Supported, feature set macOS GPUFamily1 v3

For the OS Limitation issue, this is caused by the logic I added for the Mac Pro Mid 2010/Mid 2012 models. For MacPro 6,1 (2013/Trash Cans), these should be supported no matter the existing state, since they wouldn't be compatible with any OS that is too old, nor have incompatible hardware. So they shouldn't run through the logic for those older systems.

Updated my EA to reflect. Let me know if that doesn't resolve it for you.

FWIW...

#!/bin/bash

# Check if computer supports Mojave (https://support.apple.com/en-us/HT201475). 20190129 DM



outputFile="/tmp/.tempMojaveTestFile.txt"

modelIdentifier=$( sysctl -n hw.model )

folderPath="/Library/COMPANY/SearchResults"

dateString=$( date '+%Y%m%d-%H%M%S-%Z' )



# Create folder if it doesn't exit



mkdir -p $folderPath

chown root:admin $folderPath



# Create temp file



cat << 'EOF' > $outputFile

iMac10,1

iMac11,1

iMac11,2

iMac11,3

iMac12,1

iMac12,2

iMac4,1

iMac4,2

iMac5,1

iMac5,2

iMac6,1

iMac7,1

iMac8,1

iMac9,1

MacBook1,1

MacBook2,1

MacBook3,1

MacBook4,1

MacBook5,1

MacBook5,2

MacBook6,1

MacBook7,1

MacBookAir1,1

MacBookAir2,1

MacBookAir3,1

MacBookAir3,2

MacBookAir4,1

MacBookAir4,2

MacBookPro1,1

MacBookPro1,2

MacBookPro2,1

MacBookPro2,2

MacBookPro3,1

MacBookPro4,1

MacBookPro5,1

MacBookPro5,2

MacBookPro5,3

MacBookPro5,4

MacBookPro5,5

MacBookPro6,1

MacBookPro6,2

MacBookPro7,1

MacBookPro8,1

MacBookPro8,2

MacBookPro8,3

Macmini1,1

Macmini2,1

Macmini3,1

Macmini4,1

Macmini5,1

Macmini5,2

Macmini5,3

MacPro1,1

MacPro2,1

MacPro3,1

MacPro4,1

Xserve1,1

Xserve2,1

Xserve3,1

EOF



if [[ -e "$outputFile" ]]

then

    if grep -R "$modelIdentifier" "$outputFile"

    then

        echo "$dateString SupportsMojaveNOT" > "$folderPath"/SupportsMojaveNOT.txt

    else

        echo "$dateString SupportsMojave" > "$folderPath"/SupportsMojave.txt

    fi

else

    echo "$outputFile does not exist."

    exit 1

fi



rm "$outputFile"



exit 0

Anyone have anything like this for Catalina yet?

All Macs that run Mojave can run Catalina - except for MacPro5,1.

@sbirdsley I've added preliminary support for Catalina in my extension attribute.

https://github.com/MLBZ521/MacAdmin/blob/master/Jamf%20Pro/Extension%20Attributes/jamf_ea_LatestOSSupported.sh

@MLBZ521 After creating the extension attribute from the script you provided, how does one use that in JAMF to get the results?

@remus
Every extension attribute becomes an available criteria item in Advanced Searches and Smart Groups. So you can build logic around the EA through those.

Does that answer your question?

Thanks, @MLBZ521!

@MLBZ521 Thank you for taking the time to explain it to me!
Still trying to get my head around Extension Attributes… I want for example a list of the Macs that cannot run Catalina.

What do I use for Value in this case? If I use what the script outputs in the terminal… for example Catalina in the Value field I get Macs from 2017. That cannot be right.

@remus

For Macs that are not compatible with Catalina, you'll need to use two criteria:

1. <EA> is not Catalina


2. <EA> is not ^(?!s*$).+

Criteria 1 gets devices that have reported they are not compatible with Catalina.
Criteria 2 gets devices that have not submitted inventory with the value of it is compatible or not.

Criteria 2 is likely why you're seeing 2017 devices in your search. Until a device submits inventory, the EA will be blank. The EA script has to run on the local device after it is added into Jamf Pro for the value to be reported. EA scripts do not run within Jamf, but instead, are ran on the local device. So my method is different from others in here due to the desired functionality. cbrewer's Smart Group method would be the approach I would take if I wanted the logic ran in Jamf Pro, however, it would require a one Smart Group per OS Version and......I don't want any more Smart Groups than I have to currently. We use Sites and have way to many Smart Groups as is.

This EA will report compatibility, including reasons why it may not be compatible, such as device doesn't have enough available resources (drive space), if the Graphics Card doesn't support Metal 2, or if the current OS is limiting the maximum OS level that the device could upgrade too (aka, get the latest compatible OS, you'd have a two step OS upgrade process).

Thanks @MLBZ521

@MLBZ521

Since you really only need this to run one time on an endpoint, I would suggest converting this to a Policy that stores the value in a plist on the system. Then you can use an EA that reads the value in from the plist. Much less heavy on the system during an inventory update since EAs run every time a recon happens.

#!/bin/sh



plist_path='/some/path/to/yourplist.plist'

plist_value=$( /usr/bin/defaults read ${plist_path} your_key )



if [[ -z ${plist_value} ]]; then



    echo "<result>No Data</result>"



else



    echo "<result>${plist_value}</result>"



fi

exit 0

Obviously you'll need to edit the plist path in that script and set the your_key to whatever key you store the value in in your plist.

We use a plist file to store all sorts of info we need like AD Computer name, AD groups, email address of user, city the machine was provisioned to (we ask this during build), and other data. That way when we run recon we simply pull the values from their respective keys in the plist. Much lighter weight.

Also, by placing No Data in there, you have an easier method to find systems that do not have data yet.

However, nice script and I'll probably put it in play in our environment. I was playing around with a bunch of regex values last night (before searching for this post) and was just going to use that in an advanced search/smart group (still may).

Since you really only need this to run one time on an endpoint

Not technically:

• Each new OS Version will require this to run again


• What if the endpoint OS is 10.7 (which has can only upgrade to Sierra max) and is upgraded to something newer; it could then be compatible with macOS 10.13


• Also, my script checks if the hardware is compatible, so RAM and disk space availability or graphics card changes, the EA value will report accordingly

Some may not care about the last point and some may not have these older OS versions running around in their fleets to care about the stepped upgrade process and that's perfectly fine. I included these to cover all points. Feel free to adjust to your needs.

Obviously, this value probably doesn't change all that often, and I understand that. But the script takes less than half a second to run (in my, possibly not very scientific, testing -- and it may could be improved), so I don't think that's going to affect the inventory/recon time significantly.

I'd rather the machine do this once on inventory than I would want the JSS constantly recalculating the Smart Group each machine every time it submits inventory. Also, depending on how you design the Smart Group criteria, Jamf does not recommend more than 10 criteria per smart group. And...you'd need one smart group per version of macOS, correct?

We have a very heavy usage of "Sites" (which we're working on consolidating) and I have to provide solutions that work for all Sites without relying on my Site Admins knowing how to this. I also want my JPSs' doing as little as possible given the performance issues we have.

It's all preferences for the most part. I'm just providing food for thought. Not saying you're wrong in any sense. I have been considering a plist "store" of information that can be used by different automated processes. So I do like that idea.

@MLBZ521 wrote:

Not technically:

Each new OS Version will require this to run again

Would guess a new script and policy would be needed to test for Death Valley (or whatever 10.16 will be called). :)

@MLBZ521

You make a valid point about systems that are hardware capable but not OS capable. I'll admit that I hadn't looked deep into your script before posting that, so I didn't realize you were using OS version as part of the compatibility check.

I guess I am very hesitant to run scripts that have to make calculations like that as an EA. We are well over 15,000 devices with close to 100 sites, so the thought of something going wrong in an EA gives me shivers.

Even if this needs to run more than once, you could run it as a policy set to Once a Month, or some other repeating schedule. At least then the heavy lifting is done via policy and not via EA.

I'd rather the machine do this once on inventory than I would want the JSS constantly recalculating the Smart Group each machine every time it submits inventory

Won't you still need a Smart Group to capture systems that can run a specific OS? I agree that re-calc is a major problem as you get to scale, but unfortunately some Smart Groups are unavoidable.

The SG that I am working on is only 8 criteria, all using regex, like the one posted above.

But hey, more than one way to skin a feline.

Oh, and we are also working on a consolidation of sites. We do not have site admins, so the sites are simply there as a way to organize our business units. We're utilizing plist info now to do that organization.

That makes sense.

What would be different with this EA vs any other EA? All EAs are performing some type logic on the device.
We don't have that many devices today, about a 1/3 (though we have multiple Jamf instances, which some may consolidate in the future -- and we know of plenty of devices that still are not managed). But we, until recently, had over 120 Sites -- we're down to 99 as of today.

The once a month is an idea. And not a bad one at all. Just depends on how other supporting logic is built around it (could be a month until that updates...though inventory may not be super up to date either, depending on your environment).

Won't you still need a Smart Group to capture systems that can run a specific OS?

Technically, yes. But that's up to the Site Admins today, if they wish to use them. (Most do not so far.) We'll probably build logic off this in the future though from the "full admin-level".

Yeah, the regex method above is great. Unfortunately, Site Admins can't take advantage of the Smart Groups outside of their Site...and then we'd have 100+ Smart Groups doing this work. (Do not want!)

Very true, multiple ways to do things that still can be 100% correct and acceptable.

The EA script for "highest supported OS" looks interesting but how to account for "purgeable" free space? I ran it on a machine with 54 GB free (40 GB purgeable) and of course, the script returns "insufficient resources" because diskutil only sees 14 GB free and the EA script sets a 20 GB threshold.