To get the installer app version, click once on the installer and simply press spacebar to do a quicklook. You might be OK with any version of the installers being on the system in which case you would change the criteria to not look for the application version. must have latest AV, must have FileVault enabled, etc.). You may have additional criteria you need computers to adhere to before they can get this installer (e.g. Again, this is just one way to create the smart group. It would also target computers that may not have the app installer at all. The Application Version criteria in this case should make sure that your app installer is the version you want to make sure you want on the system (in this screenshot, the installer app version is for 10.12.3). You may have specific requirements that you want to meet before deploying the installer, but at the very least this should be in your criteria. Go into your JSS and create a new smart group. The first smart group would be used for the first policy to target computers that do not have the macOS installer app. For the first smart group we are going to create, I will go into a few things you will need to consider. You can target individual computers, computer groups, limit to specific networks, and so on. See Smart Group/Scope section for more details.
Once you’ve got the package, upload it to your Jamf Pro Distribution Point through Jamf Admin.
You can use this script by Greg Neagle to download the Install macOS app.You can use device-based VPP to download the macOS installer app to the client using your MDM service (in this case Jamf Pro).Grab the original package installer from Apple as described in this post by Rich Trouton.You can manually download from the Mac App Store and then package the app up using your packaging tool of choice.You do have the choice of running just the second policy and skipping the first policy (downloading/deploying through a JSS policy), but you would need to ensure that the macOS installer app is already downloaded to /Applications folder through some other mechanism.ĭownloading the installer is the first part we want to take care of. The second policy is meant to run the actual script that will ultimately kick off the upgrade. The first policy is a custom trigger policy that deploys the macOS installer. There are two policies that this process was designed with in mind, but you can do this in one policy if you want. But do keep in mind that older versions of the Jamf Pro may not have support for the newer versions of macOS. Perform a jamf recon immediately after upgrade.īefore we begin, note that the following script was designed on Jamf Pro v9.97 initially and continues to work through Jamf Pro v10.16.Make sure that the macOS installer app does not have expired certificates.Allow use of an install package that can be used with macOS 10.13+ installers.Provide logging to see where failures may appear.Make use of Jamf Pro script parameters to allow for customization and potential re-use for future operating systems releases.Provide dialogs to give the user feedback such as a time estimate and dialogs on what to expect next.
Provide a way for the end user to do FileVault authenticated restarts if possible.Confirm that the volume is not presently undergoing encryption/decryption.Ensure the user is plugged into a power source.
With that in mind, here are some of the requirements I came up with that the upgrade script needed to solve: There are quite a few scenarios that need to be accounted for to avoid running the upgrade in a situation where it would ultimately fail. Since the script I wrote has changed, I thought a new post was deserved to account for the changes I’ve made.Īt my organization, we leverage the macOS installer app from Apple which has a neat little command line tool called startosinstall. Back in 2017, I released my script that I use to do macOS upgrades in my organization through Self Service.