"Cache" and "Install Cached" keep swapping resulting in policy failures

McAwesome
Valued Contributor

I have several larger updates that we prefer caching before pushing out. We accomplish this by adding the package twice to the same policy. The first one is set to cache and the second one is set to install cached. I've started noticing that the order on several of them keeps changing from caching first to installing cached first. This results in a failure to install a package that doesn't exist yet followed by that package being downloaded. On some policies I can just pop in and fix the order. On others, it immediately resets the order to Install Cached and then Cache. I can't figure out a rhyme or reason for it.

Can anyone help me determine why some policies are reversing orders and others are not?

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

@McAwesome I'm actually not sure what it is you're looking to avoid or really accomplish, since packages always get downloaded to the Mac first, then installed. They don't install directly off a mounted share that I'm aware of, though we don't use AFP/SMB distro points here (all HTTP) so I'm not completely sure how they behave in the former setup. Caching and installing from cached in the same policy sounds like duplicating the same process the jamf binary currently uses. It should be downloading the packages into /Library/Application Support/JAMF/Downloads/ and then installing them from that location anyway.
In the case of caching, it places them into /Library/Application Support/JAMF/Waiting Room/

Many of the items you've mentioned above, like FlashPlayer, Silverlight, Reader etc are all fairly modest sized package installs. Is there really a need to cache and then install? Can't you just do one policy to download and install in one shot for those at least? I guess what I'm asking is, have you seen a large amount of evidence that installing directly in one policy results in lots of failures?

View solution in original post

5 REPLIES 5

mm2270
Legendary Contributor III

I don't think most Casper admins accomplish what you're after by doing this in the same policy. Best practice is to maintain two policies. One that is strictly for caching the package, then collecting inventory on the Mac. The second policy does the install from cached, but does so by being scoped to a Smart Computer Group that gathers Macs which have the package cached on them (using "Cached Packages" criteria).

Generally, this avoids any issues of a policy trying to install something that isn't cached on the Mac. Of course, inventory being a static capture in time, its still possible for the JSS to think something is cached that is no longer there on the Mac, but that shouldn't happen often.

EDIT: Meant to add that, yes, I do understand that its a pain and a burden to need to keep 2 policies around for each "install from cached" type policy you want to have, but currently there isn't really a good workaround. As you've seen, trying to do both in the same policy will lead to odd results, or items being done out of order. I'm not sure if there's an existing feature request to make this process of cache and install from cached a bit more reliable and not need the dual policy approach. If there isn't one, there probably should be.

McAwesome
Valued Contributor

@mm2270 I considered that approach, but opted against it since it increases complication significantly. Currently I just have one smart group(Flash-out-of-date) and one policy(Push-Flash-Update) per update pushed, which is easy to track in the dashboard. With the other approach, I need at least two of each(Flash-Out-Of-Date and Flash-Cached groups, Cache-Flash and Install-Cached-Flash policies) and a harder to read dashboard tracker. That's fine for one update, but factor in Office, Flash, Silverlight, Reader, etc and it becomes a massive number of things to keep up with and an unreadable dashboard tracker. Also, for some reason, the only package that has ever been available in the ellipsis menu for the Cached Packages field has been our quick add, which isn't exactly helpful.

Is there a way to apply your approach without at minimum doubling the number of policies and groups needed? I've considered swapping over to a cache packages as singular policies and then having an ongoing Install Cached policy, but I've gotten a lot of failures when I tested that approach.

mm2270
Legendary Contributor III

@McAwesome I'm actually not sure what it is you're looking to avoid or really accomplish, since packages always get downloaded to the Mac first, then installed. They don't install directly off a mounted share that I'm aware of, though we don't use AFP/SMB distro points here (all HTTP) so I'm not completely sure how they behave in the former setup. Caching and installing from cached in the same policy sounds like duplicating the same process the jamf binary currently uses. It should be downloading the packages into /Library/Application Support/JAMF/Downloads/ and then installing them from that location anyway.
In the case of caching, it places them into /Library/Application Support/JAMF/Waiting Room/

Many of the items you've mentioned above, like FlashPlayer, Silverlight, Reader etc are all fairly modest sized package installs. Is there really a need to cache and then install? Can't you just do one policy to download and install in one shot for those at least? I guess what I'm asking is, have you seen a large amount of evidence that installing directly in one policy results in lots of failures?

McAwesome
Valued Contributor

@mm2270 That changes things a bit. I was under the impression that "Install" was running it from the share, not downloading it locally first. So it's pretty much just the "Cache, then install" approach I was wanting to use. I tried avoiding it because of our weirdly set up Box share since it can't really mount as AFP/SMB. I think that answers my question.

I only listed those because they were off the top of my head examples of programs we push updates out to.

mm2270
Legendary Contributor III

@McAwesome Hopefully I'm not leading you astray with my advice! I would do some tests to verify that your particular setup isn't doing anything unusual. I know in the case of at least .pkg type installers that these must be downloaded to the local machine before being run. Package installers can't be installed from a mounted share point. I'm not 100% sure about .dmg's but I believe these follow suit in that they get downloaded first.

The most common scenarios of when caching first, then installing is used is when:
a) the installer package is very large, think Adobe CC or something like that, where its useful to first make sure the entire installation makes it onto the target system before then trying to install it.
Or b) with some Self Service policies. Example: Cache the Office 2016 pkg first, then collect inventory to make the Mac land into a Smart Group that is scoped to the actual install Self Service policy. The user sees it, runs it from Self Service and it installs quickly because there is no download to take place first. (the pkg is already on their Mac) which makes for a good end user experience. We use this method with our 10.10.x Combo Update installs users can run on their Mac, since the combos tend to weight in pretty large.

In the case of not seeing those cached packages show up when clicking the ellipses button, make sure the "Collect package receipts" box is checked under Computer Management > Inventory Collection > General. The description for that box reads:

Collect a list of packages installed or cached using the Casper Suite, or installed by Installer.app or Software Update

So its important that is checked before anything will show up. Also, your caching policy should be running a full inventory collection immediately after running so it can update the JSS with new information.

Hope the above is helpful.