Moving user profiles, why do it?

Ok, this is a bit niche, but one of the things that I’ve commonly done over the years is move user profiles from the boot drive and get them placed into either a second drive or partition. There are reasons for this, and most of them run around the use of the products that my work produces. Granted there are some other reasons for this – having a very small boot drive being the biggest one that I can think of off hand.

Granted, not as huge a concern these days since you can get huge drives now. However given the price of those huge drives this may become more relevant in the next couple of years.

In either case what I generally find is that creating a fresh user profile in a new location is generally simpler than trying to move an existing profile over. On the Windows side things have been getting progressively worse with the Windows Metro apps and things that Microsoft has been adding to Windows over the course of Windows 10 and Windows 11. Even Outlook stops working if you move the user data to a new location. For whatever reason Outlook, at least the last version I used, used a absolute path to reference the way to access it’s data files as opposed to having it use a relative path based on the location of the users profile.

This winds up breaking a pile of things when you shift stuff around, and I can’t frankly be bothered trying to fix all the broken links as I stumble across them.

macOS has some similar things that happen, however those are really as bad as what you see on Windows. In most cases it’s just a couple of broken shortcuts on the dock, or worst case some permissions that don’t get carried over that you need to correct. Again, I’m a very lazy person and I’m generally just going to pull my data out of the profile, tear it out, and start over rather than waiting to stumble over all the potential landmines that are sitting around.

So, on the Windows side it’s just a single registry edit and I can tell Windows where to put new profiles down;

HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Profile List
Key: ProfileDriectory
Default: %SystemDrive%\Users

Once you change that specific registry key to point to a folder on your other volume any new profiles are created in the new location the first time that specific user logs into the computer.

Now macOS is a slightly different beast. I spent some time looking for the prefs file that would have the equivalent setting to change the default home folder location for new users and I didn’t really have a hell of a lot of luck in tracking it down. There’s a lot of conflicting information so in the end I moved to just using a command line option to create new users as shown below;

SUDO sysadminctl -addUser "username" -fullName "Users Full Name" -password "SomethingSecure" -home"/Volumes/Some/New/Place"

The important thing for me at least is that last piece, that argument lets me tell the OS where to put that new profile, and in some ways it’s a bit simpler than the Windows side since I can still put the profiles on the boot disk if I want.

The other nice thing about the macOS side is that I can also incorporate that into a script that lets me do all of this, including creating the volume for the data to be saved into, without having to do a lot of actual touching the device. Add in some scripting of the homebrew project on macOS and you have a script that can go from a fresh install of macOS to something working properly without having to get into the weeds of installing apps from the ground up.

And yes, this is all possible on macOS as long as you have a MDM solution in place, but that’s not something currently at my disposal other play with so, script it is.

On the Windows side though, I still have to play around with the scripting on that side to see if it’s something that can be used to automate resizing the partitions around. The macOS side is simple, just run a command to create a second volume and you are good. The new volume just pulls from the same pool of space that the existing volume lives on. On Windows you have to actually cut things into specifically sized chunks, something that’s kind of hard to do if you don’t know the size of the disk or are having to deal with different sized disks.

I’m sure that it’s able to be done, I just haven’t had enough time, hassle, or need to actually step through and dig into automating this out.