Apple update roll back

[TysonU]

Hello all, getting ready to roll out JSS to Mac users and trying to get all my ducks in a row for potential pushback. Some users at our location only install specific updates and avoid others. My question is whether or not there is an easy way to roll back an update installed other then time machine? Can it be done remotely? If this question has already been answered I apologize for reposting but I couldn't find any answers in the discussion board.

Thanks in advance.

[thoule]

If you mean updates provided by Apple, then no. It is very difficult if even possible to 'uninstall' an update. While it is extremely rare for an update to be a problem, just be sure to test extensively. I recommend (https://github.com/wdas/reposado) with Dev, Staging, and Production branches.

[mm2270]

Same response from me. In re: to Apple software updates, there's no (reliable and safe) mechanism to roll those back. Just be sure to test them thoroughly, and also look at forming a small test group - volunteers who would agree to installing updates once you've put them through the wringer - to get further feedback on how it works for them.

Lastly, I would evaluate each update individually. If the updates clients are not installing are not critical patches, or related to security, maybe just let it go. Who cares if they don't install those? If they are important or security related, you do need to work on getting them to install those, if you care about keeping your fleet secure. The key will be to make it easy and as reliable as you can, which is where the testing mentioned above will come in.

[TysonU]

Thank you. I was afraid that was going to be the answer.

[gabester]

Alternately, if your organization can dedicate the resources to the Macs/users in question, you could readily replicate non-hardware-specific system configuration in a virtual machine and snapshot before OS updates. That's also great for other kinds of testing.

Otherwise, I'll echo what others have already said here - leverage reposado's ability to distribute different branches. Don't put something into your Production branch until you've tested it. You can even split off certain categories of users into separate branches for additional discrete patching regimens; say the graphics art team wants to avoid system updates that may impact the drivers that run their Wacom tablets and the CAD designers don't want their video cards to get borked, so you could have ART and CAD branches and point machines to them.

Then the trick becomes deciding how you want to point your devices to software updates - if you keep it simple you can have policies set the URL for machines per category; if you have the resources to host multiple servers one per branch then you can cascade out the branches to each server and use network segments to map the clients to the servers.