Data Transfer

Transferring they're data over seems to take a chunk out of my time. This is time I could be using doing/learning other things.

Yep. If possible at your org I would work with your manager/dept to discourage the expectation that you perform these transfers. Ideally, users own/control their own data, and so it's their responsibility to save documents as needed, or to re-install non-standard apps. As you said, this would give you more time to build up some skills/work on better projects.

The biggest issue you'll have with Migration Assistant and any MDM service is your management system might get confused with 2 devices with the same name/profiles enrolled at the same time. Best practice would be to unenroll the device and remove any configuration profiles before running Migration Assistant, then re-enroll once everything is transferred over. This post explains some of the issues you'll encounter if you rely on Time Machine/Migration Assistant.

@sshort I don't have the luxury of making users back up their own data. I definitely understand what you are trying to say. Is there a way to transfer data quicker and more efficient?. I usually unenroll one device before I do these transfers. I also automated all of the policies that push out during recurring checkin. They currently execute in order during enrollment. The problem is that our users will come into some issues when doing the data transfers themselves. Especially, if they are remote workers. They end up having to enroll their new computers themselves. Even with Apple DEP its tough to get remote workers to understand our enrollment process. They're also unable to have our admin account passwords. That ends up causing a lot of trouble when trying to install MDM.

We are using AD/mobile accounts in our environment. When doing a replacement request I first validate if user needs/wants data transferred

I then run the below script to leverage rsync to copy their user profile folder data over to Users/Shared. Prompts for systems IP or computer name want to copy from and to enter the users AD ID. Connects with our local support account

Once copied will then have the user login remotely via VNC to their new replacement device so it creates their profile on the system

I will then quick drag and drop data into users profile folder created above. This processed has worked well for me as I can start the copy and let it run and will do it all on its own and show you copy process/status/time/etc.

#!/bin/bash

echo -e "x1b[31mEnter users current computer name or IP:x1b[0m"
read computer
#computer

echo -e "x1b[31mEnter users login ID:x1b[0m"
read user
#$user


sudo rsync -vau --progress localadminaccounthere@$computer:/Users/$user/ /Users/Shared/ProfileBackup/

sleep 5

echo -e "



x1b[31mProfile copy completex1b[0m



"
open /Users/Shared/ProfileBackup

If you will have access to both laptops you can increase your speed by booting the old Mac to Target Disk Mode. Then boot the new Mac to Recovery and use Disk Utility to "restore" an exact copy of the old drive onto the new Mac with a Thunderbolt cable. This does assume that the old Mac is running a version/build of macOS compatible with the new Mac, and both machines have the same disk format (either HFS+ or APFS).

As far as better informing users... I'm working on that one myself. Currently investigating DEPNotify and the IBM Enrollment app.

@sshort I use DEP Notify to automate the setup of all our laptops here. @sbirdsley we aren't using active directory here. There has to be a way to transfer data more quickly and efficiently.

We also rsync user data to their home folder and then they can move it to whether they please.

I've been advising users that get a new Mac to set it up as a new one and download all needed apps again and transfer needed files via target disk mode or airdrop. With the reasoning along the lines to avoid transferring unnecessary bloat and act as a clean up of rarely used apps, etc. However I want to have a plan in place for those that insist on using migration assistant during the setup assistant of the new Mac.

From what I understand is I should make sure the MDM profile is removed before hand on the "old" Mac. In my testing I noticed that removing the MDM profile does not remove the hidden jamfadmin account, is this something that needs to be done as well for migration assistant to work properly between a Mac that is getting replaced (user-enrolled non-DEP) and a new DEP enrolled Mac?

Otherwise I will test some other options such as @sshort 's suggestion. I'm new to rsync but will test it as well. Someone on the MacAdmins Slack channel mentioned that tar would be a better option as well? Most of the responses advised to use target disk mode + rsync using a "transfer user" can someone expand on this?

I do agree though with placing the burden on the end users regarding backups but still want to hear some more details of what you all are doing.

@kadams I'm curious what route you ended up taking.

Admittedly I have been out of the data transfer world for over 2 years since I do not directly touch endpoints or deal with end users. However, when I was deploying machines I would actually perform an rsync across the network before having the user bring their machine in. When the user did bring it in, I would log them out, do another sync over the network (or via TDM) and then swap them out.

The steps were:

1. SSH into their old machine.
2. Use the following rsync command:

rsync -avr --exclude 'Caches' --exclude '.Trash' /Users/<user> adminuser>@<newmachienIP:/Users/Shared

1. Once done logout of SSH.

When the user was ready to migrate, like I said I would log them out or reboot into Target Disk Mode and connect via Thunderbolt cable. If just logging them out, I would do the same as above, except I would add --delete to the command, right after the -avr so that any files or folders that the user had deleted on the old machine since the original sync would be removed.

After getting the data onto the new machine, I would login to the new machine as the user, and then log right back out. I would then login as the admin user, open Terminal, sudo up the admin account, and then:

1. Delete the home folder of the user account that was just created when they logged into the new machine: rm -rf /Users/<user>
2. Move the synced home folder from /Users/Shared to /Users.
3. Change the ownership on the home folder I moved so that they match the user: chown -R <username>:staff /Users/user
4. Close Terminal and logout.
5. Login as the user.

This would bring everything over and the user would have a machine that looked just like their old one.

Now, all of this was done pre-10.14 and I haven't done it since, so I'm not certain how that plays into it now. I know that 10.15 will probably introduce some issues to this with the protection of more user folders.

Just for good measure you could also reset the user's permissions on their home folder once you logged in, just to be safe.

Resolve Permissions Issues

Thanks @stevewood your insight is much appreciated.

For us, we do this in two ways. (The easy way and the hard way). At our help desk, we keep around external USB-C SSDs from OWC for high-speed transfers. Doesn't matter if it's a repair loaner or a swap. Usually, we grab the whole user folder as the logged-in user and transfer anything from the entire user directory, or file copy, depending on what the situation calls for. For our users that cannot be at the help desk, or need to grab and go, they can load any backups from our Code42 environment.