Extension Attribute - Troubleshooting.

bump - anyone had any experience with this. I'm working with JAMF support, and there is a debug mode for the jamf binary, which provides further info on overall processes kicking off, but not specifically EA's, so short of disabling all the custom EA's that have been added in the environment, would really like to be able to view the success/failure status of each when they run during a recon.

@RJH Any idea if EAs are run in alpha name sequence or by ID? If it's by name you could brute force this by having all of your EAs use the defaults command to write their completion status to a .plist, and then have a final EA that captures the info in that .plist

I don't know that there's any specific commands or tools you could use for this, other than what you already outlined, which is to test each EA separately against new applications and/or OS releases. But even testing them outside of a jamf kicked off recon may not be 100% accurate. I've seen instances of scripts that run ok when executed locally, but can fail for various reasons if run within the jamf binary context.

The only other option would be to write your own code for this. Meaning you could add a function to each and every one of your EAs to write the script exit status out to a local log file on the Mac. The log could contain the EA name and date that it ran, and what the exit status was. Of course, that means checking logs on local machines and not in the Jamf console, so it's not the most convenient, but it could enough if you're ok with it being at the client level.
If you really wanted to get fancy, you could have a separate policy that runs once a day that uses the API to put that log file up into the Attachments section of each machine so you could at least pull those down from within the Jamf console to look at them.

Edit: Heh, @sdagley basically had the same idea I did but beat me to it. :)

Edit #2: Based on what I've seen in the verbose mode with jamf recon, it does look like it runs the EAs in alphanumerical (or at least alphabetical) order. It's hard to know for sure since the jamf binary is multi-threaded, so tasks get a little jumbled up in the output, but it does seem it works that way.

@mm2270 thx for the suggestion. I was hoping I could get this info without making any further changes to the environment (and policies/ea's) given our current issues we are seeing, but thats an option worst case. You mention that you have been able to detect the order based on the verbose mode with jamf recon. Can you elaborate ? I have the jamf binary in verbose mode (sudo defaults write /Library/Preferences/com.jamfsoftware.jamf.plist global_log_level DEBUG) and when running jamf recon, I dont see that level of detail either from terminal output or in jamf.log. Doesnt appear to be a jamf recon -verbose or similar option either, so really keen to understand where you are seeing the EA's execute in alphabetical order. and thx @sdagley - your suggestion could also be an option, as above, if it comes to that worst case.

@RJH I based that on running sudo jamf recon -verbose several times on my system. Each time I noticed in the verbose output that the Extension Attributes seem to run in alpha order. I could be wrong and it could just be that the jamf binary simply displays them that way in the Terminal output. But in my tests they always show in alpha type order. Here's an example output:

sudo jamf recon -verbose | grep "extension attribute"
Finding extension attributes...
 verbose: Running script for the extension attribute Active Network Interface
 verbose: Running script for the extension attribute Battery Cycle Count
 verbose: Running script for the extension attribute Catalina Compatibility
 verbose: Running script for the extension attribute DEP Setup Completion Status
 verbose: Running script for the extension attribute Full Model Name
 verbose: Running script for the extension attribute Last Boot Time
 verbose: Running script for the extension attribute mozilla-firefox
 verbose: Running script for the extension attribute PatchManagement - Cached Packages Count
 verbose: Running script for the extension attribute PatchManagement - Cached Packages List
 verbose: Running script for the extension attribute Verify MDM Enrollment

The above just filters out the extension attribute lines.

Why not keep them in a repo and run them locally against new OSes?

@RJH Unless your system configurations vary enough that you feel only testing on a baseline system isn't sufficient I think @tlarkin's suggestion might be the simplest. Just make sure that whatever PPPC permissions are granted to the Jamf binary are enabled for Terminal on your test system so EAs running there have the same access they'd have in real life.