Migration Assistant Tool and Migrating AD Accounts to New Machines

[bsanto]

We've run into this frequently enough that I feel like some good feedback might be nice. We don't put local user accounts on our Macs, everyone uses mobile AD accounts.

On occasion, we'll have a user complain that their machine is slow/not performing/etc, so we offer to put them into a fresh machine with new OS, typically an SSD, etc.

In the past, to migrate their user account, we've just copied files from their user home directory to a network share or to an external drive, then had them log in on the new machine to create their account there, and then bring the data down into the newly created network account on the new machine.

I've tried using Migration Assistant in the past, but I've noticed it struggles with the migration and changes the computer name to match the old machine, and sometimes it flat out doesn't work.

Does anyone have a good solution for migrating an AD network account from one Mac to a new one, while preserving the user data?

Thanks in advance!

[GabeShack · Accepted solution]

https://support.apple.com/en-us/HT202506

This article has all the ingredients to help you with this.

Gabe Shackney
Princeton Public Schools

[GabeShack · Accepted solution]

https://support.apple.com/en-us/HT202506

This article has all the ingredients to help you with this.

Gabe Shackney
Princeton Public Schools

[bsanto]

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.

[stevewood · Accepted solution]

@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.

[GabeShack]

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

[bsanto]

Thank you!

[donmontalvo]

@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...

[Sandy]

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.

[bentoms]

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.

[mhegge]

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.

[Kristopher]

@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?

[stevewood]

@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.

[dswitmer]

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?

[Andrew_Rogers]

@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?

[stevewood]

@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.

[Andrew_Rogers]

@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.

[mhinsz]

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.