Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've just tried to move my users folder to another drive on 64-Bit Windows 7 Ultimate. However, I can no longer log in as I get the error message: "The User Profile Service failed the logon. User profile cannot be loaded".

In windows, my drives are mapped as:
C:\ -> windows system drive SSD
d:\ -> programs
e:\ -> users

Using the recovery command prompt my drives were mapped as:
X:\ -> recovery media
e:\ -> windows system drive SSD
f:\ -> users

I tried to create a hardlink from c:\users to e:\users in the recovery command prompt as follows:

robocopy /copyall /mir /xj e:\users f:\users
rmdir /S /Q e:\users
mklink /J e:\users f:\users

this seemed to work in the command prompt as doing a 'dir' showed the junction point as expected. However I was unable to log in after rebooting.

As I was slightly confused about which drive letters to use (the recovery ones or the original windows ones), I tried this again using the "\?\Volume{GUID}\" notation instead but this still has the same problem.

Anyone know what I did wrong or how to both this?

PS the original instructions I used were: PPS this is a clean install of windows, so I am not worried about losing data, etc.

share|improve this question
sounds like the profile path is still set to c: I think this can be changed in managment console, not sure how to do it on commandline, probably via some regedit? – stijn Oct 16 '10 at 13:46
@stijn - the profile path is still set to c, but this is correct isn't it? I thought that was the point of the junction point? – Simon Oct 17 '10 at 10:02
oops didn't see you created the juntcion; in that case, yes, it sounds allright.. either something went wrong with the copy (you could check that by moving everything from e: to c: again, if you still get the error, something's currupt), or windows has problem seeing everytiing through the junction (which I doubt, I've been using junctions for a long time and never had problems) – stijn Oct 17 '10 at 10:23
@stijn thanks, that's a good suggestion. I've done that and you are right, it still can't logon. Any idea's on what I could have missed on my robocopy arguments? It didn't report any failures when I did the copy? – Simon Oct 17 '10 at 10:31
as harrymc points out, robocopy might not copy files that are in use; did you copy after booting to recovery console? if not, that might be the problem; if so, I don't know, afaik when booting via cd no files are in use so it should be fine. – stijn Oct 18 '10 at 18:05

The problem seems to be with the different drive letter mappings in repair mode compared normal mode. What I did and worked for me is to run DISKPART (good reference here: remap the partition/devices and then make the junction with the drive letters which windows will normally use.

share|improve this answer

See in this thread the comment made by ohdannyboy on December 4th, 2009 2:33 pm, and the following comment by imadman.

They detail how to relocate the Users folder in a way that supposedly works.

From wikipedia Robocopy :

The Windows Volume Shadow Copy service is the only Windows subsystem that can copy open files, which it does by snapshotting them for point-in-time consistency. Robocopy does not implement accessing the Volume Shadow Copy service in any way, inhibiting its usefulness as a backup utility for volumes that may be in use. However, one can use separate utilities such as VSHADOW or DISKSHADOW (included with Windows Server 2008) to create a shadow copy of a given volume with which to back up using Robocopy.

If uncopied in-use files are the cause of the problem, it is still unclear how you could have deleted e:\users, but many miracles are possible in Windows.

However, the article Backup/Copy Files that are "In Use" or "Locked" in Windows advocates using HoboCopy instead of robocopy.

As another remark, I cannot understand how you claim to have mapped the system drive to another letter than C:. As far as I know, this is absolutely impossible.

share|improve this answer
thanks harrymc, the instructions I used were actually "ohdannyboy"'s anyway. Still cannot get it to work though. – Simon Oct 17 '10 at 10:17
I have added some more thoughts about the subject. – harrymc Oct 17 '10 at 18:24
Thanks for the update harrymc. The problem wasn't files not copying because they were in use. I've now fixed the problem and will add an answer here to provide my solution, but briefly the problem was that robocopy doesn't copy junction points. As to how the system drive wasn't c:, that can happen when you boot from a win7 dvd and select command prompt from the repair menu. – Simon Oct 18 '10 at 10:32
According to your description, the junction was created AFTER the copy. – harrymc Oct 18 '10 at 12:54
Yeah, sorry, the junctions i'm talking about there are the one's that windows creates INSIDE the c:\users folder - for example, it creates a junction called "My Documents" that just points to "Documents". These are for legacy compatibility but in my experience it appears that they are required for the user account to work correctly. – Simon Oct 18 '10 at 13:24

The problem is that the \xj option on the robocopy EXCLUDES JUNCTION POINTS, creating the issue (missing junction points) later clarified by Simon. Unfortunately, if you leave this option out, the process chokes on the junction points. This is a serious catch 22 with the proposed approach.

If you didn't create a recovery point and are desperate, I reinstalled and identified the following juctions that need recreated (replacing ? with your profile). I did not actually restore a system this way so I cannot guarantee that this is exhaustive, but I believe it to be so.

As you can verify for yourself, the junctions continue to point at "C:" even after the drive letter has changed (during Windows Repair Command Prompt). I believe, therefore, that the new junctions should be pointed at their "usual" locations (standard drive letters) despite the fact that the instructions above show different drive letters (on the Repair Command Prompt).

  • Users\Default User <==> Users\Default
  • Users\?\My Documents <==> Users\?\Documents
  • Users\?\Local Settings <==> Users\?\AppData\Local
  • Users\?\Application Data <==> Users\?\AppData\Roaming
  • Users\?\Cookies <==> Users\?\AppData\Roaming\Microsoft\Windows\Cookies
  • Users\?\NetHood <==> Users\?\AppData\Roaming\Microsoft\Windows\Network Shortcuts
  • Users\?\PrintHood <==> Users\?\AppData\Roaming\Microsoft\Windows\Printer Shortcuts
  • Users\?\Recent <==> Users\?\AppData\Roaming\Microsoft\Windows\Recent
  • Users\?\SendTo <==> Users\?\AppData\Roaming\Microsoft\Windows\SendTo
  • Users\?\Start Menu <==> Users\?\AppData\Roaming\Microsoft\Windows\Start Menu
  • Users\?\Templates <==> Users\?\AppData\Roaming\Microsoft\Windows\Templates
  • Users\?\Documents\My Music <==> Users\?\Music
  • Users\?\Documents\My Pictures <==> Users\?\Pictures
  • Users\?\Documents\My Videos <==> Users\?\Videos
  • Users\?\AppData\Local\Application Data <==> Users\?\AppData\Local
  • Users\?\AppData\Local\History <==> Users\?\AppData\Local\Microsoft\Windows\History
  • Users\?\AppData\Local\Temporary Internet Files <==> Users\?\AppData\Local\Microsoft\Windows\Temporary Internet Files

You may also need to add a SYMLINKD using "mklink /d ". Note the substitution of the /D option for the /J option:

  • Users\Application Data\ <==> C:\ProgramData (unless you have also moved this directory)

Naturally, additional links may have been created by other programs, but this should fix the major items broken by the inadequate instructions.

share|improve this answer

I ran into this previously. You have to make sure you use the remapped volume letter for the SOURCE parameter on the mklink command and your actual Windows-recognized volume letter for the DESTINATION parameter. Windows does NOT remap symlinks when you change the volume letters of what they point to. They're dumb like that.

E.G. According to your configuration, the following command should suffice:

mklink /J E:\Users E:\Users

Also, NOTE: if you remap your users directory elsewhere as a subdirectory (E.G. E:\Storage\Users as I once did) be careful that robocopy does not skip over any files, ASIDE from any failing. My experience with this tells me that Windows will not copy critical Users files that only work with the default directory scheme (E.G. [DRIVE]:\Users). I found out that putting the Users directory into a subdirectory would cause critical files to pass their filename length quota, and it would thus skip over them.

share|improve this answer
You really should provide more information. If you can't provide more information then its not really a full detailed answer like the other answers currently. – Ramhound Feb 6 '13 at 16:28
@DukeWellington you know, I think that was the problem - always meant to come back to this question, but did so many things I couldn't remember what the solution was! I think your answer has useful info. – Simon Feb 7 '13 at 17:34
mklink /J E:\Users E:\Users is the key – Matt Oct 18 '13 at 17:54

Using sysprep is the easiest way to create user profiles in a different location. All the other, unofficial ways, such as messing around with junctions and copying or moving files around, gave me "The User Profile Service failed the logon. User profile cannot be loaded." profile error.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .