Nothing programmatic about this post, unfortunately. Instead, a bit of rambling about Windows. :-) One of the reasons I don’t use Linux on my desktop computer is that it requires too much constant tweaking, configuring and fixing to get things to work together properly. I tried it twice, and I had the same (bad) experience both times. I’m mostly happy about Windows 7 - it’s a much better OS than previous Windows versions. But the other day, when I took on the seemingly easy task of moving one of my user profiles to a different partition (from c:\Users\SomeUser to d:\SomeUser), I immediately ran into problems.
The first problem was that the Local Users and Groups snapin isn’t available in Windows 7 Home Premium. This annoys me immensely for three reasons. One, that the OS really shouldn’t be allowed to have “Premium” in its name when it’s so crippled. Two, that there doesn’t appear to be any adequately detailed feature chart that I could’ve consulted before purchasing the OS. Three, that an upgrade to Professional or Ultimate is ridiculously expensive.
But then I got the idea to try the “net” command, specifically “net user.” Based on the command help output, it sure looked promising:
/HOMEDIR:pathname Sets the path for the user's home directory. The path must exist. /PROFILEPATH[:path] Sets a path for the user's logon profile.
The second problem was however that neither of these had any effect on the user profile location. A bit of investigation revealed that:
net user SomeUser /profilepath:<path>sets a roaming profile for the user SomeUser. I only tested this with a UNC path pointing to my local computer:
\\%computername%\d$\SomeUser. Upon logging SomeUser on and off, a directory d:\SomeUser.V2 was created with a “roaming copy” of the user’s profile (Wikipedia explains the [V2 suffix]). The “roaming copy” was properly kept in sync for each logon and logoff, as expected.
net user SomeUser /homedir:<path>only seems to affect the HOMEDRIVE and HOMEPATH environment variables. I tested setting the path to
d:\SomeUserX, and the environment variables happily reflected this. It had no apparent effect though. From what I can find on the web, these variables are “good to use in scripts,” although USERPROFILE is preferred. By default, they point to USERPROFILE.
Now here’s some rambling: I usually find that Microsoft’s documentation is very poor. I’ve been working a lot with the .NET framework lately, and I’ve found time and time again that the documentation helps very little, if anything at all. The documentation for net user is no exception. Compared to the command help output, it adds “This path points to a registry profile” for the /PROFILEPATH switch. Huh? What does that even mean?
I finally got the solution by consulting Microsoft Answers (I’m the OP):
- Create a System Restore Point.
- Log on under an admin account.
- Move the folder c:\Users\SomeUser so that it becomes d:\SomeUser.
- Open the registry editor.
- Navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.
- Search for “ProfileImagePath” until you find the one that points at c:\Users\SomeUser.
- Modify it so that it points at d:\SomeUser.
- Use System Restore in case things go wrong.
It’s a bit hackish, but it works very well! So if you ever needs to move a user profile, that’s how to do it!