Move Users Folder Location in Windows 11

Kari · Jul 29, 2021

johnlgalt said:
@Kari - any other ideas? This is your bread and butter tutorial, but I don't see anything wrong in the file itself.

I have absolutely no idea. I have no explanations, for me the method works perfectly both on Hyper-V virtual machines, and on physical machines.

One thing worth mentioning: the most common fault in relocating the Users folder with sysprep is that when Windows gets to OOBE, setup cannot find the drive. For instance, if answer file tells sysprep to move Users folder to drive D:, and somehow drive letters are changed and suddenly the DVD drive is D: and what user thought to be drive D: becomes drive E:, the procedure of course fails.

Kari

Kari · Jul 29, 2021

Note: I just reinstalled W11 on my laptop. Users folder was relocated as it should, without any issues.

poles · Jul 29, 2021

johnlgalt said:
I checked both visually as well as with WinMerge and the files are indeed identical. Additionally, I double checked to make sure that the items were all in place as they should be.

Just to recap - Windows 10 and Windows 11, both in VMWare Player, and both instances did, indeed, have 2 virt HDs set up for use?

Which version of VMWare player are you using?

@Kari - any other ideas? This is your bread and butter tutorial, but I don't see anything wrong in the file itself.

Recap of pole's posts so it's all in one place:

Thanks again John,

I have checked all this with VMWare Player versions V15.5 and the latest one 16.1.2.
Win10 installation works without any issues. Just changing the ISO to Win11 with same setup on VM and sysprep fails. To me it is all pointing to something to do with Win11, maybe Kari can throw some light.
I am yet to test the Win11 on a physical machine although I have installed Win10 a few times already on physical machines with the same answer key.

poles · Jul 29, 2021

Kari said:
I have absolutely no idea. I have no explanations, for me the method works perfectly both on Hyper-V virtual machines, and on physical machines.

One thing worth mentioning: the most common fault in relocating the Users folder with sysprep is that when Windows gets to OOBE, setup cannot find the drive. For instance, if answer file tells sysprep to move Users folder to drive D:, and somehow drive letters are changed and suddenly the DVD drive is D: and what user thought to be drive D: becomes drive E:, the procedure of course fails.

Kari

Thanks Kari. I will try Method 2 and remove the DVD drive in the configuration to ensure that there will only be 2 possible drives.
By the way, for Method 1 do you recommend creating the second drive when beginning the install of Windows or from within the administrator account?

johnlgalt · Jul 29, 2021

As soon as you go into OOBE, use Disk MGMT to verify which drives have been assigned what letters, before you run the sysprep command. Kari's tutorial is quite specific about doing this, and it works well.

The big red warning in the middle of step 2 of Method One - Move Users Folder Location in Windows 10

Although, technically, since that is at a point where the OS is already installed, just removing the virtual ROM drive should suffice, as long as you do it before you enter OOBE - otherwise, if the ROM drive captured drive letter D and you remove it, the second virtual drive may still be at another letter and you'd need to still reassign D to that drive.

poles · Jul 29, 2021

johnlgalt said:
As soon as you go into OOBE, use Disk MGMT to verify which drives have been assigned what letters, before you run the sysprep command. Kari's tutorial is quite specific about doing this, and it works well.

The big red warning in the middle of step 2 of Method One - Move Users Folder Location in Windows 10

Although, technically, since that is at a point where the OS is already installed, just removing the virtual ROM drive should suffice, as long as you do it before you enter OOBE - otherwise, if the ROM drive captured drive letter D and you remove it, the second virtual drive may still be at another letter and you'd need to still reassign D to that drive.

Well, noting all the prerequisites and precautions, still unable to figure why the entire process is successful installing W10 and exactly the same steps fail with Win11. I had already tried manually reassigning drive letters without success.
Last option: I will move away from VM and try the install on a physical machine; I am quite sure that I am not doing anything different to install W11 other than changing the ISO file

johnlgalt · Jul 29, 2021

Question: You made the .ISO from UUPDUMP, I assume?

poles · Jul 30, 2021

johnlgalt said:
Question: You made the .ISO from UUPDUMP, I assume?

Yes John. The ISO is from UUPDUMP and Win11 installation completes as a normal install. Its only the sysprep and OOBE failure for moving the user folder.

johnlgalt · Jul 30, 2021

I'm assuming that you are performing a 64bit install in VMPLayer, not ARM64.

Out of curiosity - which entry did you select when making the .ISO from the following screenshot?

I'm particularly curious if you used #1 instead of #2, and if you did, if you wouldn't try building the .ISO from #2 instead (or, if you prefer, I built a complete All In One that includes all editions, and had updates slipstreamed in, and uses install.ESD so it can be put on a FAT32 formatted USB drive, already made, and I can upload it to OneDrive for you, if it would take too long to build for you). But before that, let's ask Kari.

@Kari - to your recollection, should an .ISO built from either #1 or #2 behave the exact same regardless when cleanly installing in a VM or on live hardware?

poles · Jul 30, 2021

johnlgalt said:
I'm assuming that you are performing a 64bit install in VMPLayer, not ARM64.

Out of curiosity - which entry did you select when making the .ISO from the following screenshot?

View attachment 4414

I'm particularly curious if you used #1 instead of #2, and if you did, if you wouldn't try building the .ISO from #2 instead (or, if you prefer, I built a complete All In One that includes all editions, and had updates slipstreamed in, and uses install.ESD so it can be put on a FAT32 formatted USB drive, already made, and I can upload it to OneDrive for you, if it would take too long to build for you). But before that, let's ask Kari.

@Kari - to your recollection, should an .ISO built from either #1 or #2 behave the exact same regardless when cleanly installing in a VM or on live hardware?

Some updates John and Kari,
the observations are interesting:
I tried the procedure with VirtualBox instead and guess what it is SUCCESSFUL !
So we have success with installing on a physical machine, Hyper-V (tested by Kari) and VirtualBox - tested by myself,
and clearly it is failing with VMWare... its not an issue with the Win11 ISO : works well only without the sysprep intervention on VMWare

Kari · Jul 30, 2021

johnlgalt said:
@Kari - to your recollection, should an .ISO built from either #1 or #2 behave the exact same regardless when cleanly installing in a VM or on live hardware?

Yes, they behave exactly the same way. Only difference is (should be), that #1 in your screenshot starts from 22000.1, then adds cumulative and other updates bringing it to 22000.100, whereas #2 has updates already integrated, meaning a bit faster process to create the ISO.

Kari

johnlgalt · Jul 30, 2021

Cool, thanks for the heads up Poles, and the explanation, Kari.

poles · Jul 31, 2021

Some more updates

I managed to succeed with the procedure to move the users folder to another drive within VMWare Player after changing the HDD type to SATA from NVMe.

It is indeed surprising that the same partitioning that works for W10 using NVMe does not work with Windows 11. Perhaps this will be resolved in the final release of Windows 11 and/or an update to VMWare; it is not a critical requirement but just an observation in the difference in performance.....

johnlgalt · Jul 31, 2021

Interesting.

I suggest (in case you haven't already done so) making a Feedback report of this, as it is definitely a bug of some sort, perhaps in the emulation of the NVMe drives itself, or something related to it somewhere. And if you have, link us to it so we can up-vote it.

poles · Aug 1, 2021

johnlgalt said:
Interesting.

I suggest (in case you haven't already done so) making a Feedback report of this, as it is definitely a bug of some sort, perhaps in the emulation of the NVMe drives itself, or something related to it somewhere. And if you have, link us to it so we can up-vote it.

Thanks John, I haven't yet made any feedback. I am wondering if I should feedback to VMWare or Microsoft or both. Will post when I do. I was busy this weekend and will try to do so sometime this week.

johnlgalt · Aug 3, 2021

Maybe check VMWare forums, it might be a known issue. And if not reported, report it there. I don't think it's a Microsoft per se because it works fine on everything but the NVMe drive, right? So, sounds like an emulation issue there.

johnlgalt · Aug 14, 2021

Kari said:
I use that method to relocate the Users folder and all user profiles to drive E:, as I have always done since early Vista days. Works like a charm in W11, absolutely no issues.

View attachment 1629

Kari

I just clean installed Win11 and it gave me the same error that Poles above ran into, as reported above in his screenshot, when using the file exactly as written in 10F. I'm trying it again to see if I may have an answer as to why it may have happened, but it failed to do it this first time around.

I have a suspicion that saving the file to the USB install drive is the issue.

Testing now.

johnlgalt · Aug 14, 2021

Having the file on C (or else not enabling Secure Boot while setting up the OOBE) allowed it to work. I suspect it was the file on the USB, but who knows, may have been the stupid SB......

Kari · Aug 15, 2021

First, a reminder:

Kari said:
One thing worth mentioning: the most common fault in relocating the Users folder with sysprep is that when Windows gets to OOBE, setup cannot find the drive. For instance, if answer file tells sysprep to move Users folder to drive D:, and somehow drive letters are changed and suddenly the DVD drive is D: and what user thought to be drive D: becomes drive E:, the procedure of course fails.

OK, I did three test installs today, using three different USB flash drives. All tests where done step by step exactly as told in tutorial, even using the relocate.xml answer file directly copied from it (only changing Users folder location to E: instead of D: as shown in tutorial).

Move Users Folder Location in Windows 10

How to Move Users Folder to another Location in Windows 10

www.tenforums.com

All three USB flash drivers had exactly the same content, Windows 11 PRO build 22000.132 install files, the answer file relocate.xml (yellow highlight in screenshot), and a Diskpart script (blue highlight) to partition two disks before running Windows Setup, just to be sure that drive letters would be correctly assigned:

Booting from USB, after running the Diskpart script in Command Prompt to partition disks, I run Windows Setup normally, installing to partition 3 on disk 1 ( my laptop has a bigger HDD as disk 0, smaller SSD as disk 1).

Answer file used:

XML:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FolderLocations>
<ProfilesDirectory>E:\Users</ProfilesDirectory>
</FolderLocations>
</component>
</settings>
</unattend>

I partitioned both disks with this Diskpart script:

Code:

rem ---------------------------------------------------
rem
rem Select Disk 1, wipe it empty, convert to GPT
rem
rem ---------------------------------------------------
select disk 1
clean
convert gpt
rem ---------------------------------------------------
rem
rem Create & format 100 MB EFI System partition
rem
rem ---------------------------------------------------
create partition efi size=100
format quick fs=fat32 label="System"
rem ---------------------------------------------------
rem
rem Create 128 MB MSR partition (will not be formatted)
rem
rem ---------------------------------------------------
create partition msr size=128
rem ---------------------------------------------------
rem
rem Create & format Windows partition using all free
rem space, then shrink it by 600 MB to make space for
rem recovery partition at end of disk. Assign drive ID
rem letter W to this partition
rem
rem ---------------------------------------------------
create partition primary
shrink minimum=600
format quick fs=ntfs label="Windows"
assign letter="W"
rem ---------------------------------------------------
rem
rem Create & format 600 MB recovery partition
rem
rem ---------------------------------------------------
create partition primary
format quick fs=ntfs label="WinRE"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
rem ---------------------------------------------------
rem
rem Crete Software, Users and Hyper-V partitions on Disk 0
rem
rem ---------------------------------------------------
select disk 0
clean
convert gpt
rem ---------------------------------------------------
create partition primary size=102400
format quick fs=ntfs label="Software"
assign letter="D"
rem ---------------------------------------------------
create partition primary size=204800
format quick fs=ntfs label="User Profiles"
assign letter="E"
rem ---------------------------------------------------
create partition primary size=512000
format quick fs=ntfs label="Hyper-V"
assign letter="F"
rem ---------------------------------------------------
create partition primary
format quick fs=ntfs label="MDT"
assign letter="G"
rem ---------------------------------------------------
rem
rem Exit Diskpart
rem
rem ---------------------------------------------------
exit

All three test installs worked perfectly, Users folder was relocated to drive E.

I cannot explain why it fails for you geeks.

Kari

johnlgalt · Aug 15, 2021

Maybe I have too many drives and after moving things around the flash drive gets moved to a different letter.

After all I have 3 NVMe drives, and SSD, and a pair of Mechanical HDDs in RAID 1 - and the BluRay burner.

Windows 10 love putting my drives in pretty much the correct order, but Windows 11 puts the SSD before the NVMe drives, so I had to do a lot of drive letter changes to get them back in the right order.

And, it only happened once, and that with the file on the USB drive. Second time I made sure to copy it to the C: drive I wold eventually be booting off of, because I knew that one drive would not change letters lol.

So it failed once and succeeded once - no real way to ascertain that it was simply the location of the file.

If I feel funky I can try several more times - once I've got my system fully set back up and backed up, that is, So, maybe this weekend?