CrashPlan PROe Deployment Issue

Kevin
Contributor II

I am trying to deploy CrashPlan PROe using the JSS, following the procedure in the "Administering CrashPlan PROe with the Casper Suite" document. I have run into an issue and need guidance. After I build and deploy the CrashPlanCustomInstallation.dmg, the device pops up in the CrashPlan Dashboard, owned by me, not the logged in user of the device that has been enrolled in CrashPlan.

I believe I am missing something in these steps in the white paper (written by JAMF, 8/12):

Mount the CrashPlanPROe_Mac.dmg file in the CrashPlanPROe_Custom directory by double-clicking it.
Copy the hidden .Custom directory to /Library/Application Support/CrashPlan/ by executing the following command: sudo cp -r /Volumes/CrashPlanPROe/.Custom /Library/Application Support/CrashPlan
Open Composer and authenticate locally.
Locate the CrashPlan directory in /Library/Application Support/ and drag it to the sidebar in Composer.

The directory will appear under the Sources heading.

Rename the “CrashPlan” package source to “CrashPlanCustomInstallation”.
Select the “CrashPlanCustomInstallation” package source in the sidebar and click Build as DMG.
Choose a location to save the package and click Save.

I believe the issue is that there are some configuration files in that directory that cause CrashPlan to identify me as the owner of the device (My identity is all over the my.service.xml file). I see nothing in the directions that tell me to use a system that does not have CrashPlan configured to build this installer, nor do I find anything telling me to delete or edit this file.

So, I try this as a next step…

I installed CrashPlan PROe on a new system, but did not configure it. I did this to simply build a blank CrashPlan directory in /Library/Application Support. I put the custom files in the /Library/Application Support/CrashPlan directory and regenerated the files using Composer. I installed on a target system. It recognized the organization in the "existing user" pane of the main login window after the install, but it would not accept my user's credentials. So essentially, I am still unable to mass-deploy without resorting to sending an email to each user.

CrashPlan support told me this was not supported. JAMF support said they did not have a license for CrashPlan to test…
Anyone have experience distributing CrashPlan PROe in this manner?

1 ACCEPTED SOLUTION

Kevin
Contributor II

Resolved!

Our CrashPlan Account Manager and senior engineer came onsite today for a visit and I got some good time with them. The engineer was initially stumped as to why this wasn't working, because all of the settings I had in my custom files were correct. He then had an AH-HA! moment.

The instructions:
Mount the CrashPlanPROe_Mac.dmg file in the CrashPlanPROe_Custom directory by double-clicking it.
Copy the hidden .Custom directory to /Library/Application Support/CrashPlan/ by executing the following command: sudo cp -r /Volumes/CrashPlanPROe/.Custom /Library/Application Support/CrashPlan

are correct, but there is a step left out…
It seems the ".Custom" directory has to be RENAMED "Custom" before this will work. The "." has to be removed or CrashPlan ignores the settings files inside. I renamed the directory on one of the systems that was not working. It immediately stared working.

View solution in original post

27 REPLIES 27

Chris
Valued Contributor

It's been a while since I did this, but i believe this is what i did:

- Download the custom installer ressources from
http://YourServerAddress:4280/download/CrashPlanPROe_Custom.zip

- run the "custom.sh" script from the downloaded ZIP file and enter the details as needed

- this will spit out a DMG containing the installer and a "custom.properties" file

- modify the "userInfo.sh" script as needed

- copy "custom.properties" and "userInfo.sh" to "/Library/Application Support/CrashPlan/.Custom" and create a DMG of the ".Custom" folder with Composer (it should only contain these two files) -> upload to Casper Admin

- mount the "CrashPlanPROe_Mac.dmg" from earlier and upload the contained "Install CrashPlanPROe.pkg" to Casper Admin

So basically you use the same "Install CrashPlanPROe.pkg" on all clients.
The configuration is done by the package containing the ".Custom" folder, you'll need one package per Organization, as the "custom.properties" file contains the organization registration key.

Hope this makes sense ;)

JPDyson
Valued Contributor

I'm running off of memory here, but what Chris said rings true. We were just building CPPe at my last gig before I left, and this was a problem I had with the very first client I built (but that was probably 6 months ago). I *believe* the problem was actually in that userInfo.sh step.

Kevin
Contributor II

Chris, it make perfect sense, it just doesn't connect and authorize the user as it is supposed to.

gregp
Contributor

Which version are you using? I tried it about a year ago with 2010.03.08 (or something like that) and didn't get it going.

Currently on 3.4.1, but haven't tried it again.

Chris
Valued Contributor

Any hints in the CrashPlan Logs at /Library/Logs/CrashPlan?

jhalvorson
Valued Contributor

Two weeks ago, I followed the directions created by JAMF and discovered that CrashPlanCustomInstallation works when a user installs it via Self Service. The users's name (aka user account) is populated in the CrashPlan PROe UI correctly.

If I deploy the same package via Casper Remote, then the user name is populated with our JAMF management account and hence, does not work as expected.

It's my understanding the logic of determining the CrashPlan user account is set within the userInfo.sh file and how it determines the current user. It would appear that deploying via Casper Remote, the current user is our JAMF management account.

I haven't tried making any adjustments so that the user info is blank and would allow for deployment via both Casper Remote and Self Service.

Kevin
Contributor II

We have a visit by our CrashPlan rep today. He is bringing his engineer with him. I am going to get to the bottom of this issue this morning. I will post our solution.

carlo_anselmi
Contributor III

@ jhalvorson
I noticed the same behavior but for 10.6 clients only.
WIth them, I can only use SelfService while a login policy/Casper Remote would use the JAMF management account.
In 10.8 installing CP at login works as expected.
Cheers

Chris
Valued Contributor
a login policy/Casper Remote would use the JAMF management account

It totally depends on how the variables are set in the userInfo.sh script.
The defaults are

CP_USER_HOME="$HOME"
user=basename $CP_USER_HOME
userGroup=id -gn "$user"
CP_USER_NAME="$user"

They need to be changed when using Casper Remote or a policy.
What works best depends on your environment, for example I'm using

user=/usr/bin/defaults read /Library/Preferences/com.apple.loginwindow lastUserName
CP_USER_NAME="$user@mycompany.com"
CP_USER_HOME="/Users/$user"
userGroup=id -gn "$user"

but that won't necessarily work in all environments.

Kevin
Contributor II

Resolved!

Our CrashPlan Account Manager and senior engineer came onsite today for a visit and I got some good time with them. The engineer was initially stumped as to why this wasn't working, because all of the settings I had in my custom files were correct. He then had an AH-HA! moment.

The instructions:
Mount the CrashPlanPROe_Mac.dmg file in the CrashPlanPROe_Custom directory by double-clicking it.
Copy the hidden .Custom directory to /Library/Application Support/CrashPlan/ by executing the following command: sudo cp -r /Volumes/CrashPlanPROe/.Custom /Library/Application Support/CrashPlan

are correct, but there is a step left out…
It seems the ".Custom" directory has to be RENAMED "Custom" before this will work. The "." has to be removed or CrashPlan ignores the settings files inside. I renamed the directory on one of the systems that was not working. It immediately stared working.

Chris
Valued Contributor

Strange.
Works fine for us with the dot.

stevehahn
Contributor

Do I really need to make a separate package for each of my Crashplan organizations?

clifhirtle
Contributor II

@Chris your workaround for getting the primary user via the com.apple.loginwindow file versus the last | awk workflow worked great. Thanks for posting!

user=`/usr/bin/defaults read /Library/Preferences/com.apple.loginwindow lastUserName`

stevehahn
Contributor

@Chris @clifhirtle I'm using that too--thanks!

bbot
Contributor

Bringing an old post back, but I've tried using the loginwindow lastusername to pull the user and it's worked great on a majority of machines. However, I have found a couple machines that are pulling _mbsetupuser when it generates the user. Has anyone experienced this?

The last -1 way use to give me errors on 1 in 3 machines.

Is anyone using stat -f "%Su" /dev/console to pull the user variable instead? I'm thinking of switching.

tcandela
Valued Contributor II

to get the primary user, why can't you use the 'whoami' ?? i get the same result as the one below it

user='whoami'
echo $user

user=/usr/bin/defaults read /Library/Preferences/com.apple.loginwindow lastUserName
echo $user

bbot
Contributor

@tcandela CrashPlan recommended not doing "whoami" as it didn't always work when pushing from Casper. I think this is in their official documentation too. I never tested.

bpavlov
Honored Contributor

They don't recommend it because when something is pushed via Casper it's getting done as root which is not the username you want.

Kevin
Contributor II

Update regarding pulling users:
I worked with JAMF TAMs and Code42 engineers and we tried multiple ways to get the user to populate… All failed to work under certain conditions.

whoami always returned root…

We tried pre-run scripts.
Failed.

We tried:
user=last | grep console | grep still | awk '{print $1}' | head -1

This worked if we triggered the policy in Self Service, but failed to work if we ran the policy at login.

Here is what we landed on that works every time:

user=/usr/bin/defaults read /Library/Preferences/com.apple.loginwindow lastUserName
CP_USER_HOME="/Users/$user"
userGroup=id -gn "$user"
CP_USER_NAME=$user

ryan_s
New Contributor II

Thanks for this update @Kevin -- I'd also like to point out that I had to use your workaround for the .Custom folder as well (copying from the Volume to the Application Support directory). When I copied the folder using the how-to:
(http://resources.jamfsoftware.com/documents/technical-papers/Administering-CrashPlan-PROe-with-the-Casper-Suite-v9.0-or-Later.pdf) ...over to my system library, it would populate 2 files: userinfo and custom, but it would miss many of the other files in the Volume's .Custom directory. As a result, during installation CPPe didn't install our customized version, but rather just a vanilla version. Just FYI with other users on v5.x.x (we are on 5.0.2)

Are you guys also somehow able include CrashPlan when laying down your OS X image...is it possible to somehow install CrashPlan during imaging and then pull through the user's name upon their first login? Maybe I'll need to create a new post for this...

djdavetrouble
Contributor III

I am using this method with the 5.3 installer, My policy has two parts: the 5.3 installer and a dmg which copies the .Custom folder (which has the username script and custom.properties) to Application Support. I chose to use self service since our techs need to log in as user anyway as part of the setup process.

vinicio
New Contributor

Hi, I am getting this error every time i try to create the DMG with the custom.h script
Any suggestions?

Thanks

Change settings (yes, no, or revert) [no]? n
Enterprise server url [http://myservername:port]?

Determine client installers location

FAILED Server API returned null response for client download paths DONE after 0m 0s

stevewood
Honored Contributor II
Honored Contributor II

@vinicio If your CrashPlan version is 5.3 or higher, you need to download the installers from their web site and place in the same directory as the custom.sh script. The following article describes how to customize the installer:

Preparing The Code42 CrashPlan App For Deployment

And this is the article that contains the installers:

Code42 Platform Installers Version 5.x

The error you are receiving sounds like this is the problem.

vinicio
New Contributor

@stevewood Thank you for your help. Actually, this morning i've been using this exact documentation but still having the same problem.Any other suggestion?...

Thank you

stevewood
Honored Contributor II
Honored Contributor II

@vinicio sorry, if you're still having trouble you might try reaching out to support at Code42. They're pretty good about responding quickly and have helped me out with items like this in the past.

djdavetrouble
Contributor III

If you are running 5.3 or later you will need to download installers in the console. If you haven't added any clients under "App Downloads" (left side navigation in server console) I can see this failing.

vinicio
New Contributor

@stevewood that is what i am doing now.. i had a quick response but with wrong information. I am still working with them.