Hello, I was wondering what other Casper Admins were using to migrate user data/Apps between Macs or for re-images?
I'm particular interested in hearing how folks are dealing with user data in a AD bound environment.
we put data on a separate partition so re-images are not an issue, use fstab plenty of discussions here about that.
between machines I make the users login to the new machine, and then rsync their data from the old machine.
Yes, the second partition for data trick. I was doing that as a standard practice, mainly as a video / Final Cut Pro engineer. Having the data / media on a separate partition makes re-imaging a lot easier, especially if the users have 100's of GB of data and you have to copy two ways, can take a lot of time, where the actual Casper Imaging takes only 5-7 minutes.
One thing I could never quite get down was the user home folder. As we know OS X wants to put everything here, and there still seems no solid / obvious way to locate this /Users folder to another volume than the actual boot volume.
I am all ears.
We have handled this mainly in two ways:
1) Use of a Data partition. It is not too late to do this depending on your current OS version. You can do nondestructive partitioning these days in Disk Utility, move your Users folder, then create a symlink. Depending on how you do this, you could create problems, but if you were to make the changes while you have it in target disk mode or in single user mode, this can be done quite easily.
2) In one reimaging project, we copied the user folder to a folder named "current" on an external drive using the ditto command. For this example, the drive is named JAMF2013. Then during imaging on the boot volume, after our AD binding script runs, a package is installed that runs a script that dittos the data back from /Volumes/JAMF2013/current/ into the User folder, it then performs a CHOWN and CHMOD of the folder, which is easy in our instance since the basename of the user folder can be referenced because it is their AD username as well. The script then uses the mv command to move the user folder on the JAMF2013 drive out of "current" and into a "completed" folder, which preps the drive again for use.
The main benefit of the second method is that you completely wipe the machine and any changes you made to local user accounts in your base image are now in your newly imaged machine. In addition, once you copy the data to the drive, you image the computer and all of the data is restored to the machine programmatically using the package deployed by casper imaging. It may sound more convoluted than it actually is and I can provide my scripts if that interests you or anyone else.
We have also used alternate locations for our local administrative users so that we can blow away the Users folder or preserve it on the Data partition in other deployment methods as well.
Some people have a local CrashPLan device and just restore from backup, I have never been in love with this method, but if it works for them, more power to 'em!
Many ways to accomplish this, the choice is yours for what you think is best for your environment!
We simply move the Users folder to our Data partition and use a symbolic link. Works like a charm. Obviously, you do not want to be logged in as one of the users when you do this.
It would look something like this...
ditto /Users /Volumes/Data/Users
ln -s /Volumes/Data/Users /Users
Any particular problems that you are aware of or can foresee? I ask because we have been doing this on our Desktop machines for at least the 4 years I have been here and have not ran into any problems yet.
We've started using FSTAB to put our user data onto a separate partition & blogged how: http://macmule.com/2012/07/31/how-to-use-fstab-within-a-casper-imaging-workflow/
I've also got a script I'm yet to blog that will query AD for a user & apply the right permissions using their UniqueID & that of the domain users group.
We've so far migrated about 30 of the 150 macs we're migrating from 10.6 with success using the script. I just need to make a little tweak & I'll post a link to it here.
With our 10.6 clients we managed a separate partition for the Users folder with Mobile accounts and MCX prefs. The MCX prefs push the cached AD account to the Storage partition. The idea being that you can wipe and restore the startup partition without touching the user's home folder.
However, we're actually moving away from a separate Users partition with our 10.8 build. On rare occasions, the Users partition would fail to mount and it would create a new mobile home folder on the startup partition (shutting down or rebooting the Mac however, would almost always remount the Users partition). Information about mobile accounts would disappear when not on the startup partition (i.e. we had retail accounts set to auto login that would fail quite a bit when the cached AD account was on a separate partition) FileVault 2 was also less than enthused about the protected User's folder not living on the startup drive.
Not sure how simlinks or using fstab would address those issues. I had also read that simlinks could cause some odd behavior on the Mac, but that was several years ago in the 10.5 days.
We've been using symlinks since (at least) 10.5 to redirect the users folder to another partition. We do have the odd occasion of dealing with a Data partition that does not mount fast enough. However at that point the OS will alert the user that it can't find the homefolder. A restart resolves this issue (or mounting the partition and then logging out). For this reason I created an admin that lives in the /var/ folder since using root is not allowed in my organization. Helps with remote sites that only know "the computer doesn't work." At least this way I can log in as a non-root admin user and troubleshoot the situation.
We have not had ANY issues whatsoever other than what I just described and some oddness with FEU. To that end, I created a script that I usually run as a post-flight if I need to populate existing users profiles with plists or other such things.
OTOH, I remember reading that if an OS update touched fstab, permissions or otherwise, or changed the way the OS works with fstab, it could mess with how Users gets mounted. I didn't feel like playing with that too much, so went the symlink route. However I might be reopening the testing with fstab if it's determined that FV2 should be a requirement on our laptops since i've also read that it does not play well with symlinks.
We use a second partition to store user data on our student macbooks (using fstab) on our student macbooks. Our teacher macbooks have smaller hard drives and wasn't an option. For those, we use Carbon Copy Cloner to migrate data. It works great. I never have to deal with user permissions. It's well worth the money.
We run the old way. Since our population is transient (students) and they own their machines, we tend to always have our end game in mind. By that I mean, that when a student graduates or otherwise leaves our academy we need to be able to strip all the software that the school owns, remove the JAMF Binary, remove our accounts/restrictions and elevate the students users to the admin group. For this we keep everything on a single partition. In this manner students are able to simply leave at the end of the year, having a perfectly functional computer ready for college while our software and settings simply melt away.
When it comes to transferring files we simply copy their user directory to a local NAS or HDD while we do whatever it is we need to do. Most issues here are physical rather than software related. Once we've finished we copy the files into a new user account on the machine (bound) to avoid any permissions issues. We're also very pick about which user/LIbrary files get transferred. We'll grab bookmarks and relevant settings and let the rest replace themselves. It may sound complicated but one you're comfortable with most of the files there it's simple. This also helps eliminate any user created software issues.
Most people wouldn't notice than any changes other than the fact that their dock and backgrounds have been reset. With that said once could move those preferences, but we like our students having to learn about the computers in some way.