Run policy after other has completed

Are you talking about step by step installs of things? we do that by doing policy step 1, and then it's got a "Files and Processes" option selected which then executes

/usr/local/bin/jamf policy -event Step2

and once that runs, if need be, we do it again for Step 3, and so forth

/usr/local/bin/jamf policy -event Step3

In the above workflow we run step 1, and then it's set up to execute the custom trigger of the next policy.

EDIT - without writing a workflow script to install all your packages in order, I believe this is the most effective way.

Hi. If you're running a script post cache to check for the cached package, then technically you don't need to have a separate install cached policy set up. The jamf binary has the ability to install all cached packages on it's own. In fact, the 2nd policy with the "Install All Cached" option checked is probably just instructing the jamf binary to run the exact command to do that.

In your cached package checking script, simply have a section where if the cached pkg is detected, run this

/usr/local/bin/jamf installAllCached

That avoids needing a separate policy that just has that option checked in the GUI.

But taking a step back here, what is the purpose of caching the package and then installing it right after? Why not simply have the "install" option enabled in the 1st policy, which downloads and installs it in one shot? I'm not seeing the advantage of doing the install right after it's cached. You're just reinventing the wheel with that it seems, because that's exactly how the standard install option works right now. It just doesn't place it into the Waiting Room folder.

Hey Folks,

Thanks for suggestions. easyedc good stuff!

mm2270 question: " I'm not seeing the advantage of doing the install right after it's cached."

This is exactly the problem, we want to cache package and then keep prompting for a user to install it.

The best way I found so far for step 3 is "Policy with Install Cached function + ability to deffer under "User Interaction Tab". But this policy has to be ran only AFTER step 1 is complete, thus requiring step 2 (check if package cached).

I was suggested to user smart group with Criteria to check "Cached Pachage has....", but this criteria is completely not working as I have 8 machines cached and group is empty.

I was suggested to user smart group with Criteria to check "Cached Pachage has....", but this criteria is completely not working as I have 8 machines cached and group is empty.

Are you performing a recon (inventory collection) after the package is cached? Because the only way Smart Groups get populated with cached package data is during an inventory collection. If you aren't gathering inventory that would explain why you're not seeing those machines in the Smart Group. Because traditionally that is the way this has been accomplished. 1. Cache pkg in one policy, collect inventory right after in the same policy 2. Smart Group gets populated with machines with pkg cached 3. Second policy installs or prompts user to install cached pkg.

So if you're looking to "prompt" users to install, maybe take a look at the JAMF Helper.

/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper

And you can display HUD windows to get users attention. We use it for some critical "HEY! This is about to happen this or needs to be done!" messages.

mm2270: Are you performing a recon (inventory collection) after the package is cached?

Under same Package Cache policy we have Maintenance-->Update Inventory enabled. So I believe it should send info to server (kind of confused, would it send inventory update after policy finished?). Also did/doing jamf recon on one machine, which doesn't help, and clearly have package cached in /Library/Application Support/JAMF/Waiting Room/

Ok, so you're saying you have the Maintenance > Update Inventory enabled in the same policy that caches the pkg. If so, it sounds like something is definitely broken. Using the Cached Packages criteria, it should be gathering the machines that have the items in /Library/Application Support/JAMF/Waiting Room/

Let me ask - you aren't using any kind of custom caching mechanism are you? You're using the built in caching option in the policy I assume? Just want to be sure. If you are, and I assume you are, then something isn't working as designed. What version of Jamf Pro are you on? Have you opened a support case with Jamf about this yet?

easyedc:
Yes, that jamfHelper would be alternative, but still would need Smart Group with criteria "package is cached for these macbooks" OR step2 policy which checks if package cached and triggers jamfHelper & step3 policy which make "Install Cached" policy available in Self Service.

mm2270:
Yes, built in caching. Nothing fancy:
Computers-->Policies-->PolicyName-->Packages-->Added package with option Cache.

Logs under that policy look alrigh.

I'll talk to support.

Thanks a lot for you help!!

@othernamen One last question regarding the Cached Packages criteria for the Smart Group. Are you manually entering the pkg name in the field or are you choosing it from a list after clicking the (…) button in the interface? If you clicked that button and it showed you the pkg name(s), then that would show us that the Jamf console is aware of at least one machine with that pkg cached, otherwise the list to choose from would be blank. If it was blank and you manually entered it, double check it to make sure it has the right package name, including the .pkg or .dmg extension. I believe it has to be an exact match for that to work.

If that all checks out, let us know what the result is after working with support. I'm curious to know if something is in fact broken with regard to capturing cached packages.

Lastly, if all else fails, you could create an Extension Attribute that would capture the names of packages in that Waiting Room folder. That would at least get you by until whatever isn't working gets addressed.