Smart Group based on policy

Your smart group needs to identify the difference between a computer that has run your script and one that hasent. If nothing jumps out at you, then I tend to create a plist as part of my script

defaults write /Library/Preferences/com.toddco.plist scriptWasRun -bool YES

Then an extension attribute to read in the plist, and a smart group based off of that EA.

status=`defaults read /Library/Preferences/com.toddco.plist scriptWasRun`
if [ $status == "1" ]; then
    echo "<result>YES</result>"
elif [ $status == "0" ]; then
    echo "<result>NO</result>"
fi

No, there isn't. Well, technically there is, but it would involve knowing what specific changes (additions/removals, etc) the policy in question should be doing to the Mac, and then building a Smart Group based on that inventory information.
In the example of a package install. you can build a Smart Group that would look for the existence or absence of the package receipt, assuming its something that is unique and wouldn't be previously on the systems.
As your policy runs a script, I can't say exactly how you would do the above. It really depends on what the script in question is doing. If its intended to make some kind of change to the Mac, then maybe that can be picked up in an Extension Attribute.

That's really the only one I can think of doing this right now. Policy status or policy logs are not available to use as criteria for Smart Groups or advanced searches. These aren't available via the JSS API either, so there's no way to query the computer record off the JSS to get this data either.

The script is changing the jamf.plist. I could always just scope it to all Macs with run once per computer. The problem is keeping track of which machines ran the policy, and phasing the policy out once it is no longer needed.

It just seems inefficient to push the policy to everything, keep checking until all machines run it and then kill the scope.

OK, so what is it actually changing in the jamf.plist? Curious on this, because in general, I don't know that its a great idea to be touching that plist. That is managed by the JAMF tools on the Mac.

But, if its legitimately something you need to change, there's no reason you can't pick up the change in a simple Extension Attribute script and then use that output as the basis for a group of Macs that have not run the script.

Altering the JSS URL as part of the steps necessary to change the JSS FQDN.

So create a second script, push that to all Macs, and then create a smart group based off those results?

I have never created an Extension Attribute script before. Is that what thoule posted above, or something else?

Thanks for all the help. :)

Yes, what @thoule posted above is an example of an Extension Attribute. Here's how you would get the JSS URL from the jamf.plist in an Extension Attribute

#!/bin/sh

jssURL=$(defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url)

echo "<result>$jssURL</result>"

Create the above EA in your JSS, set the output type to "string" when creating it. Then that gets added to the inventory collection for your Macs.
Once your main policy runs on them to change the JSS URL, it should collect that information into the EA, like "JSS URL" or whatever you decide to name it. Use that as the basis for the Smart Group, as in

JSS URL | is not | https://your.jss.address.com:8443/

That should pick up any Macs not already pointed to the new URL and run the script against them. Once the change is made and new inventory is collected, they will fall out of the Smart Group.