Policy to check for JSS group membership at login

Your "checking for membership" occurs at the policy level already. If you scope a policy to a smart group, the JSS knows if it's in or out of the policy's scope. It'll run the policy at the appropriate trigger.

For example, let's say you want all machines to run an update of Flash Player upon login. Your smart group will be something like "flash plugin is not 11.4.xyz." This gives you the group of computers that you're targeting.

Next, create your policy with your updated Flash package and scope it to the "flash plugin is not 11.4.xyz" group. Your frequency would be "once per computer" and the trigger would be "login." Make sure you run inventory at the end of the policy. This will ensure that after the installation the machine is re-inventoried and then will immediately fall out of the "flash plugin is not 11.4.xyz" and thus the policy won't hit it again (though it shouldn't because it was once per computer anyway).

Follow?

That's how I'm doing it now. What I am more interested in is creating a bunch of smart groups and having an overarching smartgroup that is something like "updates available" that doesn't do any actual updates but would check for membership in other smartgroups that do actually do updates. Those policies would be manually triggered by that overarching policy.

The overarching policy would handle inventory scan, jamfHelper, etc. I can do this now by always triggering these update policies, but I want it to be smarter about that.

Here's a smaple of those code I am writing:

/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -windowType hud -heading 'American Greetings ISD is updating software on your computer' -description 'We are now updating your Mac System software. This update should not take longer than 30 to 45 minutes, depending on how many updates your Mac needs. If you see this screen for more than 45 minutes, please call our helpdesk at X4949. Please do not turn off this computer. This message will go away when updates are complete.' -icon /Library/Application Support/JAMF/EndUserSupport/AGRose.icns > /dev/null 2>&1 &

    ## In case we need the process ID for the jamfHelper
    JHPID=`echo "$!"`

    /usr/sbin/jamf policy -trigger FlashPlayerUpdate
    ## Get the Process ID of the last comand run in the background ($!)
    FPUpdPID=`echo "$!"`
    wait $FPUpdPID

    /usr/sbin/jamf policy -trigger Flip4MacUpdate
    ## Get the Process ID of the last comand run in the background ($!)
    FlipUpdPID=`echo "$!"`
    wait $FlipUpdPID

<more code here>

I'm looking for something more of an

if [ <membership in JSS> ]; then
/usr/sbin/jamf policy -trigger Flip4MacUpdate
    ## Get the Process ID of the last comand run in the background ($!)
    FlipUpdPID=`echo "$!"`
    wait $FlipUpdPID

Ahh, you're looking for "Group Membership" as a criteria item for other Smart Computer Groups, yes? If so, unfortunately that doesn't exist, but it is a feature request, so I suggest voting this up if you haven't already.

https://jamfnation.jamfsoftware.com/featureRequest.html?id=25

Ah okay. Wow I was way off. haha

Yes, that part is correct - about wanting smart groups to be criteria for smart groups. that way I could target JUST Macs that are members of the "updates available" master group, but I also want to be able to query the JSS from the command line as to what groups in the JSS the computer is a member of, since being a member of 1 or more update groups does not necessarily mean that a Mac is a member of ALL update groups.

My end goal is to have a login policy scoped to this master update group to run a script that checks for membership in the subgroups that would be manually triggered. It would have to able to read group membership from the JSS, and if membership is found, it triggers the policy for that sub-group.

Then all I would end up doing is creating the master group once to include these smart groups and add the name of each smart group as a variable to be passed to that policy. The script it runs would read in those variables and extract each trigger from them (naming standards are a wonderful thing for automation :D). Since we have a standard set of core software I would only have to maintain the criteria for each subgroup, and once in a while add or delete a smart group for updates.

At least that's the game plan. I can always "simulate" this by checking each software titles version string, but that's a lot more work in the long run since I'd have to edit that script every time :(

Job security?

EDIT: My enfeebled mind forgot i already voted that feature request up! Hopefully JAMF listens in Casper 8.7. *holds breath*

Well the only way I could think of to check all the memberships you're looking for other than the way described in the feature request) would be to use the JSS API to pull up the data on a Mac based on its name or JSS ID. The latest JSS version adds some additional items you could pull up such as computer group memberships, but its still a bit complicated to parse through the results when its pulled down via curl.

I would take a look though. You may be able to run a curl command to read through the groups and if all required ones are found, it returns a positive result.