Change Storage Save Locations in Windows 10  

Hello synchrophasor, and welcome to Ten Forums. :)

When you upgraded to Windows 10 after moving your default user folders locations, it went back to the default C location and broke the link to the moved location. They are considered separate folders now, with C as your default.

Storage save locations will not use the old ones on D as you have already found out.

Moving your user folders like in OPTION TWO below to these exact same folders on D as before should do as workaround though.

User Folders - Change Default Location - Windows 7 Help Forums

Dreiba said:

I've tried applying this setting to my machine, to deploy the windows image later on other PC's. When sysprepping this image in audit mode and re-deploying it on the same machine with a actual user, the only option that was copied was the "new apps" option.

How does this come? Can't i change the default documents folder to another drive?

Hi Dreiba, welcome to Ten Forums.

Unfortunately that's how it works due the mechanism behind the Storage Locations. Location to store new apps is the only one which does not need to know user name or profile name as it is common to all users. All other folders available for storage location change in Settings > Storage > Save locations (Documents, Music, Photos, New films and TV programmes) are user specific folders under environment variable %USERPROFILE%.

When you prepare a deployment image in Audit Mode, your theme and settings will be copied to default user profile if COPYPROFILE in answer file is set to be TRUE, and you use the /generalize switch with sysprep command. Changing the storage locations in Settings will also be carried over to default profile and from there to each new user profile you create. This far everything is OK.

I did a sysprep run just now to get these screenshots and first screenshot below shows the storage settings a minute after a new user has signed in first time after sysprep and OOBE boot:

Everything should be OK now, exactly as set in Audit Mode before sysprep. All user data should be stored on E: drive. However, when I open E: drive I can in addition to apps folder only see the built-in admin storage folders, not my new user's:

This is because changing storage locations in Settings only works for the user account you are currently signed in. Although the settings were saved and copied to my new user, they do not work. As I did this in Audit Mode signed in with built-in admin account, its user data will now be stored to E: drive but for any subsequent user profile, the user in question must exist and be signed in to change the locations.

Very short explanation: any changes in Settings app that are user profile specific do not "survive" sysprep. That's why you can change universal not user specific app storage location in Audit Mode before sysprep, but not storage location of user specific data folders.

However, moving the complete Users folder to another drive works well in Windows 10. To achieve what you want to, user data being stored on another drive and that setting saved on your deployment image, you have to use FolderLocations component in answer file as told in these tutorials:

• Users Folder - Move Location in Windows 10 - Windows 10 Forums
• Windows 10 Image - Customize in Audit Mode with Sysprep - Windows 10 Forums

Kari

Dreiba said:

But when I set a background for example, and set some desktop items, those settings get copied though. why is that??

Because those personalizations when copied to default user profile will not require a folder with a user's name to be created. You don't have to trust me, feel free to search other sources to confirm this: Storage location changes done in Settings do not work for end users even if they are done in Audit Mode before sysprepping, exception being the storage location for apps.

Dreiba said:

Also, when applying the FolderLocations option, Windows doesn't support windows store apps anymore right?

WRONG!

Windows works totally normally with relocated Users folder, can't imagine where you have heard such a bogus invalid information? Absolutely not true.

A bit messy screenshot:

1. Using PowerShell $env:USERPROFILE to display the location of my user profile. It's relocated on drive E: as you can see, with FolderLocations component in answer file when I created my deployment image
2. Drive C: has no Users folder
3. Just to show in #2 you can see full content of drive C:, I am showing both hidden items and system protected items
4. Installing new Windows Store app from Store, which BTW is in itself a Store (UWP) app!
5. Playing with 3D Builder, another Store (UWP) app

(Click to enlarge.)

Dreiba said:

Thanks for the quick reply Kari :) I was having some trouble setting the ProfilesDirectory option, and made a SuperUser post about it.

The user that answered told me it was basicly unsupported in Windows 10, as read in this article.

That article you were referred to was outdated already when it was written.

Since first beta versions of Windows Vista I have used sysprep to relocate my Users folder, never had any issues with it. Windows Update works perfectly, all apps as well. I have never since those days back in early 2006 and Vista Beta run a Windows machine with Users folder on C: drive, exception being test machines and installs I do to get screenshots for tutorials or make newbie videos and other reasons like that.

It is true that until Windows 10 version 1511 build 10586 upgrade was not possible with relocated Users folder. Before that build I always needed to sysprep Users back to C: drive, upgrade and again sysprep Users to another drive after the upgrade. A simple and easy task, no issues.

However, Windows evolves all the time. Since build 10586 it is no longer required to move Users back to C: in order to be able to upgrade. I am currently running Windows 10 version 1607 on 6 physical machines and about a dozen Hyper-V virtual machines, all having Users relocated to either E: or D: drives. I've not had a single issue. I update, upgrade, run Store apps, my Windows works perfectly.

Your issue as told in that SuperUser post of yours was, believe it or not, that Windows Setup in OOBE phase did not find the U: drive. The empty not very informative error messages are a clear indication of this.

When preparing Windows image you really need to manually set the drive letters; booting to Audit Mode and seeing your preferred target drive for Users folder has ID X: does not mean it will be X: when sysprep is run and OOBE starts. Therefore when relocating Users folder it is important to go to Disk Management in Audit Mode, change the target drive for Users folder to anything else than preferred, close Disk Management, reopen it and now set the drive ID letter to preferred one. This will make it "stick".

See video in this post: Windows 10 Image - Customize in Audit Mode with Sysprep - Page 48 - Windows 10 Forums

Kari

Dreiba said:

How about the ProgramData option then? Do you use it on any of your machines? On the documentation, it states again:

• The Windows® Store and Windows Store apps are not supported.
• If you change the default location of the program-data folders to a volume other than the system volume, you cannot service your image. Any updates, fixes, or service packs may not be applied to the installation.

Does this mean you cannot use Windows-update according to this documentation?

Relocating ProgramData folder is supported in Windows 7, not supported and should absolutely not be done in Windows 8 or later.

How many times and in how many different words you need me to say the same? Relocating Users folder has none whatsoever effect in functionality of Windows Update or upgrading Windows 10. They will work extremely well regardless if Users is relocated or not.

When done correctly the relocation of Users folder is 100% safe, only making Windows more secure (OS and user profiles on separate drives = added security).

Being very sincere, judging by your posts, I wholeheartedly recommend you just to install Windows 10 with defaults, not trying to customize the deployment image, not trying to move Users to another drive.

Kari