Another method for macOS upgrades via the JSS using Self Service

[bpavlov]

I wanted to share this blog post on providing OS upgrades through jamf Pro: https://babodee.wordpress.com/2017/03/14/another-method-for-macos-upgrades-via-the-jss-using-self-se...

Feedback always welcomed.

[duffcalifornia]

I think that a lot of these things could be handled on the back end in the JSS to make the experience more customer friendly.

You could create a smart group based on current OS, free drive space, etc and cache the installer silently once it's released. Then once it's vetted by your team, you could make the policy to run the script and install the cached package, which would drastically decrease the amount of time a customer was waiting to get the new OS hotness.

[bpavlov]

The problem with relying on the JSS to gather some of that inventory information is that inventory is never going to be live. The script collects that live. Additionally, the deploying of the app installer is essentially caching (it happens silently and the user wouldn't be aware that it's being pushed). This is just not being cached in the way that Jamf Pro does it where it's in /Library/Application Support/JAMF/Waiting Room/. With this method, it is also easier to overwrite the app because you're installing the app installer (to whatever path you want).

There are a few downsides to that I'll point out if you cache using Jamf Pro's method:
1. Jamf Pro caches the app installer pkg which means when you do install the cached pkg, it would need additional space while the package temporarily expands to extract the payload. Between the time you cache the package and then install it, it's possible that the user fills up their computer drive space. Not something I'm willing to take a chance on.
2. You would need to have an additional policy to install from cache. Why? Well if you include the package (install from cache) and including the script as an After Script in that policy, what happens if the cached package couldn't install? So the process if you did go this route would be; first policy to cache pkg using Jamf's method (and you would also want to make this a custom trigger so you can call it later in case this fails), second policy to install cached package (make this a custom trigger); and third policy to run the script which would confirm that the app installer is in fact on the computer and if it isn't try to re-cache and install from cache again.
3. You are adding time to the upgrade process (unpacking a 5gb app may take a few minutes). If you deploy it in advance using my method, you don't have to deal with that.

EDIT: Clarified my point 2.

I'll admit for some people this may be overkill, why pay attention to details? But that's just how I like to do things. Try to think of every potential scenario where things might fail and avoid them where possible. In some environments it might not be necessary to consider so many details though. And that's perfectly fine too. This is a new method I'm using. I previously used the createOSXinstallPKG tool to deploy.

[mm2270]

We also use something custom for these upgrades that checks disk space and other requirements live. I agree that the main trouble with inventory for Smart Groups is that certain data is in constant flux. Disk space is one of those things that can change in a matter of an hour or less, so its not necessarily a great idea to rely on a data point that could be up to a day or more old.

[seann]

We make users open tickets to be upgraded, and block the App Store installs.

Smart groups are built based on the presence of a dummy file. Once reconned, it will be placed into the group. jamf policy then pulls down the upgrade package, as well as various other things (office update, etc.)

Haven't had great success with reliably running login/startup policies to install big things. We try to do everything prior to the upgrade (remove SEP, install latest office update, etc.) Post upgrade policies are triggered to run once per machine, on startup/login/recurring check in, to make sure they kick off. Pretty much the only thing we do via post-upgrade policy is re-apply our wallpapers, remove some icons, and turn off DisableFDEAutoLogin.

[bpavlov]

That sounds like a lot of manual work. Why not script around all that and provide a Self Service option? For example, why isn't Office updated before hand regardless of the OS update? It would be a pretty bad idea to do this as a startup or login/logout policy. Big installs like this are perfect for recurring check-in or ongoing via self service (depends on the goal of course).

[seann]

@bpavlov It does go into Self Service, after the packages are cached and ready to go.

We are very wary of auto installing any Office 2011 update. For example, the one that brought El Capitan compatibility completely broke Outlook for a few days. We can't have 3200 machines with Outlook not working. Database rebuilds are also pretty annoying, especially considering we have users with identities that can be upwards of 10 gb in size.

[perrycj]

I agree with @mm2270 and @bpavlov. We do our Sierra/MacOS upgrades through Self Service. The script we use checks HD space, etc live at that moment and that's much more reliable and accurate. If enough HD space isn't present, then the upgrade fails and informs the user why it fails. Works pretty well for us.