Understanding Cache, Install, and Install Cache

1. Yes your understanding is mostly correct. As for saving then installing, that's actually what "Install" does. It does not install the package directly from the share point, It copies down first, either over http(s) or AFP/SMB, then installs. Although Disk Images can be mounted directly from a share point, pkg installers rarely can, so they have to be copied to the Mac first, then run.

2. Yes, there is a way to install just the cached package. A lot of people get confused about this. in your policy, under the Packages section, add the package again, but change the Action menu from "Install" (which it defaults to), to "Install Cached" So basically, you're telling the policy to look for that specific package cached on the Mac and install it, instead of pulling it down from the share point again.

3. I'm not exactly sure what you mean on this, but you may want to look at using custom triggers. Meaning, have your cache policy (or whatever) run first by normal triggers such as next check in, then at the end, have it run another policy by using either a script run as "After" or by using the Execute Command under Files and Processes and enter ing something like jamf policy -id <id> or jamf policy -trigger <custom trigger>

Another method for #3 is the use of Smart Groups. In your example, you would scope Policy C based on the completion of Policy A, so that Policy C would not be available unless Policy A had completed.

You can accomplish that with dummy receipts, extension attributes, or installation of a PKG by Casper.

@ mm2270

Thanks.
1. Great. That clears up things for me regarding "Install". And makes more sense because it was also my understanding that PKGs for the most part cannot install from a network share.

1. Good to know that I can do Cache and Install in one policy. I read the documentation but it was never clear to me that you could do this. It doesn't specifically say you CAN NOT do this, but it also doesn't say you CAN (or maybe it does, I read it 3 months ago and it was a lot to take in). Didn't help either that at some point I read that you should do two policies to Cache and then Install (not sure where I read that, but that's probably the main cause of the confusion right there).

2. I'll keep this in mind. It's nothing that's applicable to me right now. It's just a thought that occurred to me.

Hi @bpavlov
Sorry, there might be some confusion and may be my fault. You can't cache and then install cached in one policy. If you want it one policy, just do "Install" since that's exactly what it does. The "Install Cached" is intended as a second policy to run after the first one caches the package.
In general how most JSS Admins use this is to have the first cache policy run silently in the background. If you use http/s it supports resumable downloads so even if an end user closes the lid of their Mac before it completes caching it should in theory pick up next time from where it left off.
Once it's fully cached, you can have a Smart Group detect those cached packages and use that group for the scope of the second policy which can be put in Self Service as an example. The user clicks "Install" and instead of waiting for a large pkg to download, it just starts installing right away. Makes for a better user experience because it appears much faster (because you already did the longer part in the background)
Does that make sense?

@mm2270

Yes that makes sense. It explains what I read previously then.
So it sounds like at the end of the day I will end up with a lot of Policies and Smart Groups. That's fine so long as they have and serve their purpose.

I usually have at least 3 Smart Groups per PKG to install:
Caching: Scoped to 2 Smart Groups to check if Not Current or Not Installed. Depending, I'll have a Smart Group to exclude certain versions if necessary (eg, needed for Microsoft Office, not necessary for Firefox).
Install Cache: Scoped to a Smart Group checking if PKG is Cached. I may create a Current Version Smart Group for Exclusions depending on the case.

One key to help your sanity is don't create a new Smart Group every time you have an update. I'll usually go in, disable the policy, edit the Smart Groups to reflect the new version numbers, and then reenable the policies.

Can anyone tell me if you setup a unique policy to "cache" an install package then another policy to actually "install from cache", do the source files (the cache'd files) remain on the client machine after the install runs?

I am checking to see how this exactly works. We have a HUGE Adobe Creative Cloud installer package and wouldn't mind just having it remain on the client system in the case we'd need to (re)install it.

@benducklow It does not remain in the cache "Waiting Room" if you have another policy do "Install from cache". But you could technically just have another policy install the pkg using an Execute command in a policy such as

"install -pkg /Library/Application Support/JAMF/Waiting Room/Adobeinstaller.pkg -target /"

You'll want to test of course. IMO, if your Adobe pkg is 20GB, that's a lot of space to take up on a drive. On a gig network it should take 5-6 minutes to download anyways and may not be worth trying to keep it cached particularly if you ever need to update the package.

Thanks @bpavlov. The reason I am inquiring about this method is because we don't have DPs at every site and we have a large telecommuter work base. The other thing I don't like about this method would be management of that installer package at a later date (deleting it for example).

Again thanks for the info. Much appreciated!