Best Practice for OS X Upgrades

roethelbc
New Contributor III

In our environment, up until this point whenever a user wanted to go to a new version of OS X (ex. 10.9.x to 10.10.x) our department would have to copy the users data to a network share, reimage it, install all the users software again, and then bring the data back down. As you can imagine this has made the entire process slow and painful for both the technician as well as the user. We have recently started talking among ourselves about using the Self Service to allow users to upgrade there machines if they are eligible (our definition is if they are running 10.9 they can go to 10.10, anything older than 10.9 will be blocked).

Here is the issue that we are running into. The process itself works, however many in our group are worried about how the upgrade will effect the machine in our environment. Data is the biggest issue that we have. Does the upgrade touch the Users data? Whats the risk of the data being lost? Questions like these.

Other concerns are how our macs are configured. We use Active Directory accounts and work heavy off network shares. (we a primary Windows environment). Has anyone experienced any large or small issues with doing in place upgrades in an environment such as ours. Who is using this method of in place upgrades or does anyone have other suggests?

On a side note, we only have about 400 Macs and only three technicians that work on them. With Apple moving to a new OS a year, security concerns have started to rise in our department.

Thank you everyone who provides input!

12 REPLIES 12

sanaumann
New Contributor III

I'm also interested in using in-place upgrades. We have always had to reimage machines to go to the next OS because certain items in our image were overwritten when the upgrade would be laid over the image itself.

+following.

alexjdale
Valued Contributor III

We've been doing user-driven in-place OS upgrades (we send users to the App Store) since 10.8 was released without any real issues. User data is not a concern, since it is not touched. Application compatibility is a concern, though. Users may have apps that no longer run, and you may have apps (like AV) that need updates to work on the new OS version.

We do encourage users to back up their data before upgrading because Apple encourages it as well. If the upgrade fails (which is rare), then you fall back to a reimage and data replacement. We have thousands of Macs so we can't realistically perform a reimage for every single Mac.

If you want to get creative, you can track operating system version history with scripts/policies/extension attributes and create policies to reinstall/upgrade apps as needed, reacting to the user's upgrade.

mm2270
Legendary Contributor II

We also do a fair amount of in place upgrades here, although we do it through Self Service and not directly from the App Store. In either case though, user data shouldn't be a concern any more than it is if a home user goes to the Mac App Store and upgrades that way. That is to say, the risk of data loss is more or less the same. Although in our case its not a requirement that the user back up their own data, we do encourage them to do it. We have an in-house company supported back up solution to a cloud infrastructure. One of the "enrollment and check" scripts we run when a user starts the upgrade cycle checks to see if their data has recently been backed up to that solution. If not, we alert them to this so they know about any possible risks. It doesn't stop them from doing the upgrade however.

For us, the more important checks are system compatibility (is this Mac too old for this upgrade?) application compatibility, disk health (checking S.M.A.R.T. status) and disk space (since we are caching the installer to their Macs as part of the policy) The installer being cached plus space needed to do the upgrade are both taken into account and if there isn't enough space we let the user know they have to clear up some room. As you can imagine the Macs we often see needing to clear up space are older MacBook Airs with 128 GB SSDs. Those models seem to run out of room if you sneeze. We use a custom Extension Attribute to track free disk space on the boot volume since the % used value that Casper captures natively isn't very useful in this regard.

All in all, in place upgrades are and have been very doable for several years now, but you do need to do some legwork to make sure the experience is as smooth as possible.

JAMF also has some documents and perhaps some videos that explain how they do it. I'm pretty sure they use the same process they've outlined in their docs in house at JAMF when a new OS comes out.

bryce_carlson
New Contributor III

We have done in-place upgrades since 10.8.x. They have worked great for the most part. We encourage the users to back up their data beforehand.

To control the flow of converts to a new OS we have an app restriction policy that I make when an OS is announced (ex: Yosemite last year). This keeps them from running the install unless they have talked with me. The restriction policy gives a pop-up if they try to run the install and lets them know to give me a call. I talk with the user and make sure it will be a good fit, and then whitelist them to allow them to run the install. It has worked really well for us.

As for users that do not want to be on the cutting edge or do their own upgrades I use a smart group in JSS to get names. Then I e-mail them directly to find a time that they will be out of the office to do the upgrade for them. Again I use the same whitelist method from the restriction policy and run the updates as I have time, and when it works best for the user.

roethelbc
New Contributor III

How many of you guys are running an Active Directory environment for your Macs?

bryce_carlson
New Contributor III

@roethelbc We are full AD campus-wide. We use the built-in AD plug in. Part of the switch was to in-place upgrades also included the switch to the built-in AD plug-in from ADmitMac.

roethelbc
New Contributor III

@bryce.carlson thats perfect! AD issues and data loss our the two big fears that we have with making the switch. We are looking at CrashPlan as a failsafe for the upgrades.

alexjdale
Valued Contributor III

The native Active Directory plugin and FileVault work perfectly after an OS upgrade. That is a major reason we dropped third-party AD plugins, they never seemed to survive an OS upgrade.

bryce_carlson
New Contributor III

@roethelbc CrashPlan is a good move. We have laptop users that never use their network home share. I have trained them to use our OneDrive storage to sync their files with so they have some back up since they are off-net so often. CrashPlan would let you do the same if not even better.

As for our desktop users we tell them to use and save to their auto-mounted network shares from our SAN. It has been a good blend of security but letting them have the local disk as a big sandbox for content that will not stick around long.

What is your internet connection like? The other thing you might want to consider is caching the OS X Installer.app for users to upgrade with on their Macs.

roethelbc
New Contributor III

@bryce.carlson The more I look at CrashPlan the more I like it. I have often found trying to get your users to save anything in a network share is the equivalent to herding cats. So for us we rather make it as simple as possible to keep the data safe during any process.

Of internet speeds very from building to building. We are a university with our oldest buildings dating around 1960s. They tend to have slower speeds than our new ones. We were planning to cache the Installer.app because it seems like it makes more sense to deliver the upgrade right then an there.

Plus, if something does not happen fast enough our users get button happy.

mm2270
Legendary Contributor II

We're also all native Active Directory here, with cached mobile accounts. The only real 'caution' there may be around AD is that you should qualify any new OS from Apple against your Active Directory environment before ever opening an in place upgrade to your users. The concern isn't so much data loss as much as Apple has a bit of a sordid history of releasing x.x.0 OS X versions with broken Active Directory plug-ins. It hasn't happened with every version, but its happened enough times that we often have to put the brakes on a new version (like the upcoming 10.11) until we've verified if it works with AD or not. It sometimes takes a point release or 3 for them to shake out the bugs with that.
Test out everything 'AD related' thoroughly.

bryce_carlson
New Contributor III

@roethelbc Ha. Yeah. Herding cats is a good analogy paired with the button happy. I relate it to public policy. Protect the public from itself.

I am with @mm2270 the AD plug in has been bumpy on that past few OSes, but I always make users wait till 10.x.1 or higher always. Unless I have used it and it is rock solid.