Move Users Folder Location in Windows 10  

OldGrantonian said:

I have a brand-new Dell Vostro, with Win 10 Pro.
.
Is there a similar tutorial for the situation where Windows is already installed?

I would like to move my "Users" folder to E.

If that's not possible (or too risky for a non-techie), the next choice would be to move my Downloads folder to E, to free up space on C.

I've already moved "Documents" to E, using: Right-click on Documents > Properties > Location tab

If there's a better method, I can move Documents back to C, and start again

Thanks.
.

To move the \Users tree on an existing installation, use method 2: Users Folder - Move Location in Windows 10 - Windows 10 Forums

If you just want to move special folders, you can do that easily enough - I do it all the time for Documents, Downloads, Music, Pictures, and Videos. I use the method outlined in the tutorial from the sevenforums sister site: User Folders - Change Default Location - Windows 7 Help Forums (and we do have the reversal in case something messes up right here - Users Personal Folders - Restore Default Location in Windows 10 - Windows 10 Forums ).

However, a more convenient way to do this might instead be one of these methods:

1. Library Save Location - Set in Windows 10 - Windows 10 Forums
2. Storage Save Locations - Change in Windows 10 - Windows 10 Forums

HTH

pietro said:

definitive workaround to resolve the bug.

i lost tons of hours trying from an AU iso, but... damn, was so obvious

- install november update
- relocate (during installation or after as you prefer)
- install anniversary update
- done

at the moment, i don't see any difference compared to a clean install using an AU iso. i'll use it for a while and, finally, migrate all pcs...

Perhaps you were correct in terms of other folders being affected. I am having a lot of idiosyncrasies that I have never experienced with WinX when clean installing AU with the \Users folder move that I never have before. I am not talking about the known issues with IP build 14965 / 14971, either, where settings / Store automatically run, but a lot of other stuff. I wonder if starting with the IP 14971 .ISO directly would make a difference....

I am going to take a shot at starting all over again and seeing if I can get these issues resolved or not. Hopefully I can. I will start with the 14971 .ISO first, and see if it exhibits the behavior. if so, I'll go back and start with November Update.

<off to DL November update>

pietro said:

definitive workaround to resolve the bug.

i lost tons of hours trying from an AU iso, but... damn, was so obvious

- install november update
- relocate (during installation or after as you prefer)
- install anniversary update
- done

at the moment, i don't see any difference compared to a clean install using an AU iso. i'll use it for a while and, finally, migrate all pcs...

I installed the April build (1511_2) using the tutorial to move my drives and the word Public sorted in all public folders.

@Kari - this tutorial works without a hitch, even when using Easy2Boot to boot the .ISO from media. The only thing different is that you have to mount the .ISO prior to running Sysprep (and, obviously, point the relocate..XML file to the source folder on the mounted .ISO).

Also, WinX setup works perfectly well with Micro$oft's two-step verification when logging in to your outlook / Hotmail account during initial setup. Just make sure you have your device handy. I use Android, and have the Micro$oft App installed, and it just pops up a notification allowing me to accept / reject (allow / deny) the attempted log on.

OldGrantonian said:

.


Thanks for all these different methods

I intend to try them all while I still have a clean laptop. If I screw things up, I can quickly restore my Macrium image, roll back to my current setup, and then try a different method.
.

Best way to test [emoji2]

@Kari - I attempted to be cute and see if I could speed the process along with the clean install --> update process, starting with the April TH2 .ISO, then manually updating to AU, then again manually updating to 14971. By manually, I mean by mounting the relevant .ISO in my system and running setup.exe from inside Windows and letting it take care of the update process.

I learned (the hard way) that this is not the same as letting the updates apply from WU. It recreated the /Users tree in the default location on the system drive, unbeknownst to me, and when I finally figured it out, I realized that I could not do it this way without using the tutorial again at every upgrade attempt. That sucks.

What's worse, though, is that I did not test (but will do so soon in a Hyper-V VM when I get this instance running correctly again) if running the tutorial actually works fine or if it creates its own problems - namely creating multiple local user profiles for my main user because it does not recognize that I ma upgrading, and thus does not rename the old profile (or /Users tree, whichever way the WU update does it) to Windows.old.

Silly me to think that an in-place upgrade would act the same way as an upgrade triggered by WU....

yuvala said:

Hi Kari,
I am a new member with basic English.
I used your toutorial to Relocating Users folder on an existing Windows installation.
Failed to execute command: "sysprep /oobe/ unattend:\relocate.xml".
I got error message that Windows can't execute the command, missing [mode:??]
I found at Microsoft guide to execute Audit command with reboot, so I add REBOOT to your example, an its work.
I change to: "sysprep.exe /oobe /reboot /unattend:d:\relocate.xml"

The tutorial already includes the /reboot flag in the command line:

Now the Sysprep command itself. Type the following:

%windir%\system32\sysprep\sysprep.exe /oobe /reboot /unattend:d:\relocate.xml

Perhaps you just left it out?

johngalt said:

@Kari - I attempted to be cute and see if I could speed the process along with the clean install --> update process, starting with the April TH2 .ISO, then manually updating to AU, then again manually updating to 14971. By manually, I mean by mounting the relevant .ISO in my system and running setup.exe from inside Windows and letting it take care of the update process.

I learned (the hard way) that this is not the same as letting the updates apply from WU. It recreated the /Users tree in the default location on the system drive, unbeknownst to me, and when I finally figured it out, I realized that I could not do it this way without using the tutorial again at every upgrade attempt. That sucks.

What's worse, though, is that I did not test (but will do so soon in a Hyper-V VM when I get this instance running correctly again) if running the tutorial actually works fine or if it creates its own problems - namely creating multiple local user profiles for my main user because it does not recognize that I ma upgrading, and thus does not rename the old profile (or /Users tree, whichever way the WU update does it) to Windows.old.

Silly me to think that an in-place upgrade would act the same way as an upgrade triggered by WU....

I've never had that kind of issue. Upgrading through WU or using an ISO, if Users folder is relocated before the upgrade it will be relocated also after the upgrade. No new Users folder will be created, not on C: drive or anywhere else.

Since November 2015 update (version 1511) it is possible to upgrade any version and edition of Windows 7, 8, 8.1 and 10 when Users is relocated without any whatsoever issues.