OS X new domain migration – retaining user profile with terminal commands

If you’ve been tasked with the domain migration of a number of OS X El Capitan and Mavericks iMacs or MacBook Pro or Mac Air workstations, you may need to retain the user profiles. Normally, when unbinding, and then binding to a new domain, your user’s settings will be lost. You may be tempted to use Migration Assistant, but this usually requires copying the entire profile somewhere else which can take a long time and use a lot of disk space.

With this list of steps, you can use commands, scripting, and setting permissions and ownership of the user directories to perform the domain migration in-place.

Below is the sequence of commands and workflow step by step to migrate an OS X mac to a different domain. The key is to delete the sqlindex files, and prepare the user account for it’s new permissions. Please note the guide may not make sense at first while reading, but it will allow you to migrate your macs so that the users keep their same profile. Let me know if this guide helps you in your domain migration and if you find any better solutions.

Tasks Commands
1 Login as admin user and list users  Terminal -> ls -alh /Users/
2 move domain User folders to .old sudo mv /Users/johndoe /Users/johndoe.old
3 Unbind Machine  Preferences->Accounts->Login Options->Network account server -> Directory utility ->Active directory->Unbind
4 Delete sqlindex files found in ls /var/db/dslocal/nodes/Default/ sudo rm -f /var/db/dslocal/nodes/Default/sqlindex
sudo rm -f /var/db/dslocal/nodes/Default/sqlindex-shm
sudo rm -f /var/db/dslocal/nodes/Default/sqlindex-wal
5 reboot sudo reboot
6 Bind to new domain Preferences->Accounts->Login Options->Network account server -> Directory utility ->Active directory->Unbind
7 reboot
8 login as user
9 Logout and login as admin
10 move User folder .new After you have logged in as the user under the new domain you need to move the newly created User home folder to johndoe.new and move the .old User folder to /Users/johndoe with the command:
sudo mv /Users/johndoe /Users/johndoe.new
11 move .old to new username sudo mv /Users/johndoe.old /Users/johndoe
12 Change ownership of user home folder sudo chown -R johndoe:”Domain\Domain Users” /Users/johndoe
13 logout as admin
14 Reboot
15 login as that user (johndoe)
16 Click on “Create a new keychain” much easier in El Capitan and Yosemite If “Create new Keychain” fails then goto Keychain Access –> Preferences –> Reset Default Keychain

20 thoughts on “OS X new domain migration – retaining user profile with terminal commands”

    1. Glad the info helped out! Has anything changed / are there any missing steps or did it work as outlined?

    1. That’s a good question – we did not have filevault enabled on our systems so we never tested that scenario. If you do please report back your results?

  3. Does it matter whether the migrated user has local admin rights on that machine before the process is started?

    1. No it should not matter. However the unbinding of the machines and changing file/directory permissions and renaming user directories is of course necessary to have admin/root permissions.

  4. Thanks!
    I’ve tested it on a non-admin profile and it works so I’ll go ahead with the others 🙂

  5. So at step 8 you are essentially logging in as the domain user into the new domain, correct? If you’re having difficulty at that step I recommend you check your new domain binding settings (I think you should always put a checkmark in the mobile user setup). Additionally I would double-check DNS (it’s always DNS). I have a feeling the login is not locating the new domain and timing out. Also try logging in as a domain admin to see if it’s a permissions issue.

    1. That is correct. I am logging in as the domain user into the new domain. I will take a closer look as to what is different. Thank you for the response!

  6. Update: I am able to successfully unbind and rebind with using the GUI. It appears as though either my bind or unbind commands might need more flags and which is affecting the first login as the user after bound to the new domain.

    Unbind:
    dsconfigad -remove -force -u none -p none

    Bind:
    dsconfigad -a $HOSTNAME -u $domain_admin_user -p $domain_admin_password -preferred $domain_controller -ou “CN=Computers,DC=newdomain,DC=corp” -domain $domain -mobile enable -mobileconfirm enable -localhome enable -useuncpath enable -groups “newdomain\Domain Admins,newdomain\Enterprise Admins”

    1. Sounds like you’ve narrowed down the issue which is always a good place to be! Let me know if you get the commands to complete successfully as well as you can with the GUI – I’m sure other admins would like to know!

  7. What if the new domain has a different account logon name than the old domain? EX: old is “johndoe”, new is “john.doe”. Since this results in a different home folder (“john.doe” vs “johndoe”), would renaming the old home folder from “johndoe.old” to “john.doe” in Step 11 cause issues? I imagine that users that have written code that may reference objects in a “johndoe” directory may have issues once it becomes “john.doe”. What can be done to minimize or prevent these conflicts?

    Thanks!

    1. I would imagine that these cases would need to be tested and the bugs ironed out in advance of a migration. This procedure is not a utility or tool that has been written for the expressed purpose of solving all situations one would encounter during a migration. In other words: THIS PROCEDURE IS PROVIDED “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
      HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS PROCEDURE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

  8. I’ve bumped into a similar problem to Brian’s.
    The profile name in users has a space in it but her login ID does not; eg: username = “john.doe” & profile name = “john.doe 1”
    I get a error at step 2 – presumably because there’s a space in the profile name.
    Any thoughts?

    1. If it can’t be scripted then perhaps add it to the one-off’s column and do a manual restore with an external drive?

  9. Hey,

    Thanks for Publishing this , it will be great help, as migrating almost 100 mac

  10. Step 6 seems like a copy & paste oversight. It should say: Preferences->Accounts->Login Options->Network account server -> Directory utility ->Active directory->Bind

  11. I have some questions:
    1- Why do I need to delete the sqlindex files? Seems to me that everything worked fine even without doing this.
    2- Why do I have to rename the profile folder to .old? I realize it is to grab the new ID from the domain on the account. In my case, this was not necessary. I simply changed the owner and it all worked fine.
    3- Why delete/create a new keychain? I was able to retain the old keychain after the migration to the new domain.

Comments are closed.