API help requested

[blackholemac]

Given a random package (either by ID number or name) in the JSS, I would like to get an output report of what policies in the JSS already contain said package.

That alone would be wicked cool, but I know some of the folks on here have push the API truly to the max..so I’ll issue a challenge...what I would really out and out LOVE is if I could take the output of the above and the ID number of a new package (already uploaded through Jamf Admin) add it to each of these policies and remove the old one.

I don’t have an answer, but I have a conceptual scheme of how it would work...

1. It would prompt the admin for the old version package ID that they want to replace. In my example we would target package 156, labeled “OldPackage.dmg”. It would then prompt the admin for the package ID of the new package, in this example, I would use package 257, labeled “ReplacementPackage.dmg”.

2. It would then loop through all policy IDs numbered 1-<a large max number>
   For each policy that is set to install the old package, I would out replace the first snippet of the policy output below with the second snippet below

<package>
        <id>156</id>
        <name>OldPackage.dmg</name>
        <action>Install</action>
        <fut>false</fut>
        <feu>false</feu>
        <update_autorun>false</update_autorun></package>

<package>
        <id>257</id>
        <name>ReplacementPackage.dmg</name>
        <action>Install</action>
        <fut>false</fut>
        <feu>false</feu>
        <update_autorun>false</update_autorun>
      </package>

It is assumed that multiple policies would have this particular package in it. It is also assumed that I want to leave everything else in policies alone.

This is a lot to take in so I understand if no one has the time to help me write crazy API scripts.

Any help given will be very much appreciated.

Blackholemac

[mm2270]

There are already several scripts and some standalone tools that will show you what policies a package is used in, maybe Jamf Admin configs also. Or an output of all your packages and showing the relationships. I have an old one knocking around somewhere on my github page, but there are much more efficient scripts written since then that I would look at.

I don't know of anything that would locate and replace one package with another package inside policies. Sure, it could be done, but since the API doesn't have a single "view" of packages and where they are used, this could be a tall order. As far as I know, any such script would probably need to loop over every single policy to see if the package id is being used in it, and then do the replacement. That could take some time to run, even with a script.
If Jamf gave us a single API view, or resource, of packages and what they relate to as far as policies, configs and so on, then it would be much easier. But alas, such a single API resource that shows all that doesn't exist.

[blackholemac]

@mm2270 I was worried this might be the case. If not someone would have likely wrote a script to do this already.

I'll supply some background. Up until very recently, we used Casper Imaging, but given that I have a summer and the desire to start fresh in a different JSS after building up 6 years of cruft, I am retooling our provisioning workflow to remove imaging from the entire equation.

Now that I've got that out of the way, there is one thing in Casper Imaging that I cannot replace well. It used to be, I could take a piece of software, let's say Flip4Mac, upload VLC player, save it and then replace Flip4Mac in all configurations with VLC Player. That would immediately update the imaging configuration so it's just a matter of find and replace. Sure I'd have to write a policy to do that for all existing machines, but with new machines, I could just deploy VLC player and be done with it.

When I move to DEP workflow that relies solely on new technologies to get the software on the Mac, I would have to replace Flip4Mac in each of my provisioning policies manually (and remember where I had it) and then rely on patching or other policies to update it.

Somewhat tedious process. There is a feature request that is under review here: Replace in All Configurations Should Also Mean in Policies too
https://www.jamf.com/jamf-nation/feature-requests/548/replace-in-all-configurations-should-also-mean-in-policies-too

Implementing this in Jamf Admin would be a godsend, but being the crazy guy I am, I sat down to figure out how I might do something like this using an API script. Still open to ideas. One I've ruled out is naming each of the packages with simple version agnostic name and then writing over the top of the old one with Jamf Admin. I could do that, but that's awkward at best.

Any food for thought on this topic would be wonderful.

[chris_kemp]

Our approach for this is to maintain a single Software category, that simply installs whatever pkg we consider current, and assign it a custom trigger, e.g. 'install_VLC'. So when we set up configurations, or Self Service tools, all policies simply call the install_X trigger. When we update a .pkg we only need to update the Software policy with the new pkg.