Posted on 03-11-2013 05:31 AM
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?
Solved! Go to Solution.
Posted on 03-12-2013 11:24 AM
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.
Posted on 03-11-2013 06:50 AM
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 ;)
Posted on 03-11-2013 07:59 AM
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.
Posted on 03-11-2013 12:42 PM
Chris, it make perfect sense, it just doesn't connect and authorize the user as it is supposed to.
Posted on 03-11-2013 02:04 PM
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.
Posted on 03-12-2013 12:45 AM
Any hints in the CrashPlan Logs at /Library/Logs/CrashPlan?
Posted on 03-12-2013 05:43 AM
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.
Posted on 03-12-2013 06:23 AM
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.
Posted on 03-12-2013 07:01 AM
@ 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
Posted on 03-12-2013 07:21 AM
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.
Posted on 03-12-2013 11:24 AM
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.
Posted on 03-12-2013 12:32 PM
Strange.
Works fine for us with the dot.
Posted on 10-11-2013 04:18 PM
Do I really need to make a separate package for each of my Crashplan organizations?
Posted on 04-03-2014 10:36 AM
@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`
Posted on 04-03-2014 11:34 AM
@Chris @clifhirtle I'm using that too--thanks!
Posted on 02-04-2016 11:11 AM
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.
Posted on 02-07-2016 12:53 PM
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
Posted on 02-08-2016 09:17 AM
@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.
Posted on 02-08-2016 09:23 AM
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.
Posted on 02-10-2016 07:23 AM
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
Posted on 02-12-2016 10:13 AM
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)
Posted on 08-25-2016 06:56 AM
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.
Posted on 11-28-2016 02:54 AM
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
Posted on 11-28-2016 08:44 AM
@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.
Posted on 11-30-2016 08:47 AM
@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
Posted on 11-30-2016 09:00 AM
@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.
Posted on 11-30-2016 09:55 AM
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.
Posted on 12-15-2016 03:26 AM
@stevewood that is what i am doing now.. i had a quick response but with wrong information. I am still working with them.