Migration Assistant Tool and Migrating AD Accounts to New Machines

Does it make a difference that we are going from an AD account to an AD account?

We're not using local accounts, so it's hard for me to see the total relevance of the article you just posted.

@bsanto the steps that I use to migrate our AD users from one machine to another are as follows:

1. Use rsync to sync the data from one machine to another: rsync -av --exclude 'Caches' --exclude '.Trash' /Users/<userfolder> <adminuser>@ipaddress:/Users/Shared

2. On the new machine after making sure it is bound, move the user folder from /Users/Shared to /Users.

3. Change ownership on the folder: chown -R <user>:"domain users" /Users/<userfolder>

The user can then log in with their AD credentials and everything will be there. There's no need to create the user ahead of time or to use Migration Assistant.

I've been using this method for years.

Doesn't make a difference, if you are just moving a folder back over. Steve's above method is basically the same just with a rsync script instead of dragging a folder over. Either way works.

So in our case we hook the two machines together (either target mode or ethernet cable) then log into the admin on the new machine(making sure its bound) and copy the user folder over to the Users folder. Then just apply the permissions to the user folder with the chown command from the article or in Steve's step 3. Then have the user log in to test.

Gabe Shackney
Princeton Public Schools

Thank you!

@stevewood wow, can't believe Apple's article doesn't mention using Domain instead of staff. I submitted a bug report to get that changed...

I used to sniff at the Migration Assistant too, but over the last year I have been using it to move folks from one Air to a newer model, newer OS, and the ONLY thing I've found that breaks it the AD bind.
If BOTH devices are bound and I migrate users, the target bind is funky so I just unbind/rebind.

Other than that it has been awesome, user profile, printers, added apps all go across and work, and since I never have to log into that user I avoid all the keychain bulls**!
My biggest challenge is to get both devices to recognize the thunderbolt bridge, which is the fastest way to transfer files.

I do this.

A bit OTT, but hey.. works for me :) We run it post imaging, post migration & people can run it via self service.

Would like to revisit this as the Apple article no longer exists.

A couple things that I have found important:

1) Having a AD bind in DEP is not the way to go if you are migrating from one devise to another (new) as it creates a container by the current name of the device (iMac, MacBook) and not the container for your new user. A lanualy bind to the existing container is the way to go.

2) Run into "macOS needs to repair your library to run....." issue on the migrated user. Pain in the A** to fix and a crap-shoot

3) Even though there is a Admin account already on the device from the DEP enrollment, migration tool does not recognize it or ignores and wants you to create or promote a user to admin. Plus, it states a new password created for the migrated user. Be sure to write this one down because it is another pain point.

@stevewood Is your solution still valid? Lets say if I have the new machine thats bound, FV2 and I have the users time machine backup, would this work?

@Kristopher If you have a Time Machine backup, why wouldn't you just be restoring the backup? What I posted above is for moving a user's data from one computer to another without a backup. And yes, as far as I am aware, the method I posted above is still valid for moving a user's data.

sorry to dig this old one up. looking for some help with the chown syntax. So i copied the user folder and moved it to users. Then i bound the machine to AD. When I try to change ownership, i get variations of illegal user name or group name depending on which way i do it.

I'm still logged into the mac as the local admin user and trying a variation of this:

sudo chown -R <user>:"domain users" /Users/<userfolder>

Is the <user> the name of the AD account that hasn't logged into the machine yet? Do I need to log in with that domain account before I change the ownership?

@stevewood @dswitmer I am in a similar spot. Steve, if you can give us any advice I would really appreciate it.

FileVault is enabled on our machines and they are all joined to the domain when they are provisioned, so I am using your rsync ideal to transfer data from one machine to a new machine and running in to the same issue as dswitmer. I can set permissions successfully. My issue comes in when trying to provision the transferred user with a secureToken.

sysadminctl -adminUser <localAdminAccount> -adminPassword - -secureTokenOn <user> -password -

That gets me an unknown user error.

This is my last little gremlin before I turn field services loose to remediate several hundred machines that may or may not be at risk for battery fire.

thoughts?

@Andrew.Rogers @dswitmer

The AD account needs to be present on the machine before you can set permissions. You can do this by either logging in with the user's account information and then logging back out, or you can try the createmobileaccount utility:

/System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount

Once you've done that you should be able to set the permissions on the folder.

As far as SecureToken, if the user is not on the machine already, then you won't be able to create a token.

@stevewood Ahhhhh, thanks much. That does clarify things. I will play with that utility and see where I get. Mostly just a long exercise to see if we can get by without using migration assistant.

Has anyone built a user rsync migration into Self Service? I'm working on this, but not sure how to pass credentials into the rsync command.