Tag: code42

Considerations when upgrading CrashPlan with Munki

I had a great workflow for installing CrashPlan with Munki for older versions of CrashPlan (we were on versions 3 and 4 before).

We recently made the jump to CrashPlan 6.5, though, and that workflow no longer applies. Now you have to use a deploy.properties file instead of custom.properties and userInfo.sh files.

We had some added complications to our "upgrade" process, because our new CrashPlan server is a completely different server, and we weren't migrating everyone at once, so we couldn't just change the DNS to point to the new server. I'm not sure a jump from 4 to 6.5 would have been possible as just an installation upgrade anyhow.

So what were those complications?

  • We couldn't use an installs array any more to tell Munki whether CrashPlan was installed or not. Keeping the installs array would (without managed_updates) prompt users to upgrade to CrashPlan 6.5 or, worse, just upgrade them automatically (with managed_updates). So I changed CrashPlan 4 and 6.5 to use an installcheck_script instead.
  • Since CrashPlan 6.5 isn't just an update but an actual upgrade for us (think Microsoft Office 2016 vs. Microsoft Office 2011), it's a separate item in Munki altogether, which means we also had to remove the old version from the client's SelfServeManifest before installing the new version (otherwise, the old version would just reinstall).
  • Likewise, as part of the preinstall_script for 6.5, we had to invoke the /Library/Application Support/CrashPlan/Uninstall.app/Contents/Resources/uninstall.sh script to remove 4 first.
  • Lastly, we had to have a temporary place to hold the deploy.properties file before copying it to /Library/Application Support/CrashPlan—otherwise, the old installation of CrashPlan would somehow make it disappear or be unusable by the new installer. Not sure exactly what was happening, but it wasn't being recognized when just being delivered there directly as a payload. We also tried including the deploy.properties file in the .dmg itself, but that didn't work either (prompted for server and registration key).
  • Annoyingly, if you choose not to use SSO, you can't fully automate user account creation or sign-in, so some user interaction for the upgrade is required.

Ours may be a very niche scenario (upgrading from CrashPlan 4 to CrashPlan 6.5 and not using single sign-on), but in case anyone else is in that same situation and using Munki, maybe this blog entry can save you some time in planning your rollout.

Freeing up licenses from deactivated users in CrashPlan

If you have CrashPlan PROe licensed for a certain number of users at your organization, but then you run out of licenses, you may think you can just deactivate users, and that's all good, but in Deactivating & Reactivating Users & Devices, Code42 is a little vague on how long it will take for the licenses to free up:

Deactivation stops backup and causes associated archives to be placed into cold storage and eventually deleted. Licenses are not immediately freed by deactivation.
Apparently (thanks, Sean, from the Mac Admins Slack), you have to purge the cold storage (CrashPlan's version of the Trash can or Recycle Bin) in order for the licenses of the deactivated accounts to be freed up. More details at Purging Cold Storage.