CrashPlan Pro admins, sound off

[JPDyson]

I'm looking for feedback (positive or negative) regarding your experiences deploying and administering CrashPlan Pro with Casper. All helpful comments are welcome, but I'm really hoping to hear from folks who support a medium or larger enterprise, and if you use the CPP appliance, that would be super.

[stevewood]

While I'm not a medium or large enterprise, I do have 80 licenses deployed of CPP, and I am running the CPP appliance under VMWare 5. I don't follow the JAMF way of deploying CPP, but I do deploy the PKG file using Casper. I just make a headless connection to the client via ssh and the CPP application on my machine. That's one of the things I love about CPP. This article on their site explains how to do it:

http://support.crashplanpro.com/doku.php/recipe/configure_a_headless_client

The only "difficult" part of this has been managing storage. And that's only difficult because I'm not a Linux guru, but I've been able to stumble through and make it work.

[jhbush]

We just installed CrashPlanPROe with four appliances around the world with 8000 clients worldwide. The new version is great, but it has many bugs that they are working on. I would wait until they get some of those worked out. Deploying it with the JSS can be done a number of ways:launch agent, at login, or via Self Service. We chose the Self Service method as we would like end users to take a more active role in supporting themselves. It has worked well so far as we also added a script to remove Mozy Enterprise. We looked at a number of other options and settled on CPP as it seems to integrate well into AD, supports both Mac & PC, and is easy for end users to understand.

[Dtwerdohlib]

It's been pretty good for us. We deployed to around 120 staff laptops. We followed this article http://jamfsoftware.com/libraries/pdf/white_papers/CrashPlanPRO_and_CasperSuite.pdf.

The one strange thing that we discovered during deployment was that it seems the scripts in the CrashPlan mpkg work based off of the last user logged in using the 'last -1' command. So if you setup a login policy and the user happens to restart their Mac, then login, the last known user is listed as 'reboot'. So the install fails. We had a workflow where we made sure the user was logged in, then we used ARD to send the unix command 'last -1' to make sure that is correct, then we added the user to the CrashPlan policy we have setup, log out, log back in, open CrashPlan app and login as the user.

We also found a couple times that if the Mac does a check into the jamf using some sort of trigger, then the last known user would be the name of our hidden account.

So when the install failed we had to use the CrashPlan uninstall located at /Library/Application Support/Uninstall CrashPlan. On top of that, we had to delete a pref from the user that you are setting up in ~/Library/Preferences/com.backup42.desktop.plist...there is also a folder in the ~/Library/Caches/ folder...I think its called CrashPlan or com.backup42....something along those lines

Hope this helps!