Rolling back to a snapshot

[jbarnes]

We're currently planning to upgrade our JSS from 9.65 to the 9.81. Has anyone ever had a failed upgrade, or had things go awry with this sort of upgrade and done a snapshot recovery (we run our JSS in VMware vSphere) -- and has that worked well for you? Any gotchas?

One thing I know is that the JSS upgrades jamf clients to the latest version -- but if the latest version exists in some half-broken state, you'd end up rolling back the JSS with clients and possible self service running a newer version. Has anyone run into issues with that?

I am a bit apprehensive since this is the first time I'll be upgrading my JSS.

[jhalvorson]

Don't rollback the JSS, even JAMF's documents says to not rollback. Work with JAMF support prior to the upgrade if you are concerned. They might survey your environment prior to your upgrade.

[scottb]

@jbarnes - is your JSS on Windows? Linux? Mac? There are docs on things you can do (in addition to what @jhalvorson noted) to prep your server before you upgrade.
We have Windows servers and we're basically locked out of all but the most basic access, so I understand your apprehension for a production environment.

We have had one or two go wrong, and once we needed the TAM once to get us back up. There's no guarantees, but there are steps you can take to mitigate lots of things that do go wrong.

Here is one such document (click)

I'd recommend a couple that bit us in prior upgrades (in addition to JAMF's docs).
1. Might want to use IP addresses for your DP's if applicable.
2. Remove any complex characters from your CasperAdmin and CasperInstall JSS account passwords.
3. Check all the requirements on the release notes first. Making sure that your MySQL and Java are up to date, etc.

Good luck.

EDIT: Apologies - didn't read closely enough that you are using Sphere. Sorry about that...

[Aaron]

I did the same thing last night - took a snapshot in vSpehre. Didn't end up needing it. Depending on the size of your fleet, you could pick a time (evening) where there'll only be 1 or 2 clients connected, so if something does go wonky, it's not a big deal to re-enrol them.

At first I tried downloading the VMDK and spinning up a local VM through VMware Player, and hooking up a test Mac via a private network. The upgrade itself went fine, but I couldn't get the client to communicate properly with the server (probably because DNS was broken, and I was trying to manually force hostnames in /etc/hosts). It was a good test though to see if there would be any issues with the upgrade, and it also pointed out which scripts/policies were using an invalid path to the jamf binary.

Ideally, you want a live test environment. Do you have the ability/permission to clone your VM in vSphere? Give it a different name/IP, and enrol your test Mac to it. That'll let you know how Self Service/policies go after the upgrade without impacting the rest of the fleet.

[Chris_Hafner]

The only thing I'll add is that it is possible. It's a god awful idea but we've had to do it once, a long time ago for an issue we didn't catch in testing. I could have reinstalled the older version of the JSS from scratch and a backup. It would probably have been a better idea but our TAM and some other fine folks from JAMF got us through. Again, it's an awful idea and thankfully a moot point in this thread.

[jared_f]

Last time I spoke with Jamf support, they said as long as tomcat is stopped during the snapshot that is ok.

It would probably be better to fully power off the VMs, take the snapshots and take them offline during the upgrades.

Not sure if anybody has done with w/ version 10.