Cache or install the macOS installer app

[tcandela]

I want to put the macOS installer app in the application folder on certain computers that can support that particular macOS version. So if a mac can only upgrade no higher than macOS High Sierra or macOS mojave (or whatever macOS version it can be), i want to have a policy to put that macOS installer .app in the macs /Applications folder.
Then afterwards the user can simply upgrade on their own from that installer.
Do i set the policy to 'install' or 'cache' the installer .app?
With el Capitan i used to cache it first, then had a self service policy for users to install cached el capitan (so 2 separate policies). Could this same procedure be done with high sierra and mojave?
Is cacheing the macOS installer .app different than creating a policy to just install the macOS installer .app in the /Applications folder?

[sdagley]

@tcandela If you 'cache' the package then you'll have to have a 2nd policy that installs the cached package before it'll be available in the Applications folder (if that's where your installer .pkg puts it). Since it sounds like you allow your users to run the installer app on their own it'd probably be easier to just have one policy that does an 'install'.

You really should do yourself a favor and look at @Rosko's macOSUpgrade script. I've used it for upgrading users to High Sierra, Mojave, and Catalina. It really makes the process easy.

[tcandela]

@sdagley I'll take a look at that script. I don't want to use --eraseinstall, this will be in place upgrades. Are the images that the script pulls up for the user to see included?

If i go the Self Service route I want to have the installer in place prior to the user upgrading through Self Service, i don't want the policy to also have to do that.

[mm2270]

The simplest way to understand this is that when a policy uses the 'Cache' action, the package payload(s) in the policy get downloaded into /Library/Application Support/JAMF/Waiting Room/ and will sit there, waiting for some additional action later to run the installations, such as another policy that uses the 'Install Cached' or 'Install All Cached' actions, or a script calling the jamf binary, etc.

In the case of 'Install' as the action, the policy downloads the package(s) into /Library/Application Support/JAMF/Downloads/ The difference is the policy then directs the jamf binary to run the packages or DMGs to install the contents immediately after, then removes the files when finished (success or fail).

If you want to "cache" a macOS installer to /Applications/ for your clients, the easiest way I've found to do this is to create a new pkg in Composer. First, place/copy your macOS installer into /Applications/, then in Composer, just drag the installer .app file into Composer's sidebar, where it will create a new source, and copy the installer in along with the path in Applications. From there you can adjust permissions on the .app to match the rest of the Applications folder (always a good idea) and then build the package or DMG. Then upload and deploy it using the 'Install' action, NOT 'Cache'. This will download the .pkg or .dmg into /Library/Application Support/Downloads/, run the pkg or dmg and "install" it's contents, which in this case is the macOS installer app, into the Applications folder, and finally do a cleanup.

Hope that makes sense and clears things up. FWIW, I see this type of question asked very frequently here. It seems to be a consistent point of confusion about how best to get macOS installers onto devices into the right location.

[sdagley]

@tcandela macOSUpgrade has no requirement for --eraseinstall. Unless you're planning on having your policy that caches the installer run on check-in and download in the background, there's effectively no difference in the user triggering a download policy, or initiating the upgrade via Self Service. And macOSUpgrade is smart enough to use a macOS installer previously downloaded to /Applications if you go that route.

[tcandela]

@mm2270 @sdagley yes, I just want to get the appropriate macOS installer .app (high sierra, mojave, or catalina) for the particular macs installed in the macs /Applications folder. Thats it!!

with that in place, either the user wants to manually do the in-place upgrade or if i use the script to have it upgrade via self service (to avoid having the script needing to download the .app)

lines 111 thru 116 of the script is the 'eraseinstall' section, so 0 argument will just in-place upgrade while 1 will erase drive and install fresh OS. I want 0 which is default value

Just was not 100% clear on the location of 'cache'. I new about the waiting room but was not clear if the 'cacheing' made it visible in the /applications folder, which looks like it doesn't.

[sdagley]

@tcandela You're really over thinking this. macOSUpgrade has the option to do an --eraseinstall option, but it's an option not the default so you don't need to worry about it. Cached does not mean installed, so if installing a .pkg puts something in /Applications you shouldn't expect caching that .pkg to do the same thing.

[tcandela]

@sdagley i understand fully. don't take my last reply as not understanding the difference

[sdagley]

@tcandela Agreed. And I have edited my earlier post where I used cached to mean a previously downloaded macOS installer in /Applications to remove the ambiguity with a Jamf policy to cache an installer in the Jamf Waiting Room

[nsbickhart]

I believe it's recommended to cache for large packages. Big Sur is 12GB, so I have it set to cache and it works pretty good. Has anyone heard of any issues mass deploying a policy to cache the installer? Wondering if anyone has seen a negative impact for users, especially users on a crappy internet connection.

[#11]

In our environment, we use a policy that has the pkg file for the macOS. I simply create a policy and scope it to a specific OU based on what OS version they are running. Staff will receive a notification and I also send an email communication that the upgrade is available for install.

I also revoke access to software updates and the
app store.