How do I change the directory Windows uses for user profiles? revisited
Some time ago, I noted that you can use the ProfilesÂDirectory setting in your unattend file to move the directory that Windows uses for user profiles.
The classic documentation has been updated to emphasize that the setting should be used only in a test environment, and setting it prevents the system from being serviced or upgraded.
A newer version of the documentation repeats the emphasis that the setting should be used only in a test environment, although it no longer blocks upgrades starting in Windows 10. However, moving the profiles directory does prevent Store apps from working. And since many parts of the system are provided in the form of Store apps, moving the profiles directory will make many parts of the system inoperable.
TL;DR: Don’t use it.
Light
Dark
10 comments
If it is going to break a lot of the core Windows apps (like Edge, Notepad, etc) then why bother supporting it anymore anyway? Shouldn’t this trigger a warning/error and then ignored so nobody uses it anymore? Even in a test environment what would be the use case for changing it since you couldn’t really verify the test system is working if the store apps don’t work anymore.
I wonder why they simply remove the feature and even the function call from Win32 in the next versions. If it does not work, I don’t even understand why someone will need to test this.
I don’t understand why this doesn’t work. It should work.
This was very popular when SSDs first came out because they were very small. The idea was that you put the OS and possibly swap on the SSD for responsiveness, and put everything else on a hard drive because the SSD didn’t have room for anything else.
It’s not as much of a problem (but it’s not zero) as SSDs have increased in size to the point where you don’t have to do this unless you have a pathologically large profile.
Another use case is “semi-public” computers. Where I work we have a number of construction workers. They have access to email etc. but supplying corporate phones is (or at least used to be) a bit of a pain. So we would have a computer in the lunch room for the workers to use. This results in a lot of profiles on the one computer.
So why go to the effort of half-supporting this? At first glance it looks like a solution to a number of problems, but then you look further and say “No, that causes more problems than it solves.”
I suppose now that it’s in, pulling out the supporting code would take a lot of work and likely breaks something else.
Definitely seems odd the Store wouldn’t support this. If anything I’d expect new tech to support it more so than older stuff.
It could be the Store wants the profile on the same physical drive as Windows. Some apps don’t work right if you put some of their files/folders on separate drives from other files/folders, since some of the file move APIs won’t move files across drives (only between folders on the same drive) so it breaks some apps. For example if %TEMP% was on a separate drive from Chrome’s user profile Chrome used to not run (they’ve since fixed this).
For Store apps it could just be more like “you’re in unsupported territory, so we won’t run”.
Old apps would definitely have a problem with this, as some will just hard code the path name. For example C:\Users. This is why to this day there is still a “Documents and Settings” symlink (or NTFS junction or whatever i tis) in the root and similar other ones scattered throughout. And you can’t browse them in File Explorer, I assume so NEW apps don’t get written to use them by accident.
One time I reinstalled Windows XP and for some reason Windows decided that the system drive should be mounted as E:. This caused a lot of problems with third party apps. Eventually in desperation (you can’t adjust the mount point of the system drive!) I hacked the registry mount points to move it to C, and the system became unbootable. Just as well, my next approach was going to be to reinstall anyway.
Store apps themselves can be on any drive. They do not need to be on the OS drive or even the drive with the user profile. I personally have mine on a separate drive. The only requirement is that it can be secured with NTFS.
Having said that I don’t believe the issue is with the runtime behavior of the store apps as you can change the directory of where user profiles are stored in Windows and store apps work. Based upon a brief scan of what is being discussed this is an installation level issue. The unattended setup file (for installing Windows) has a setting to allow you to start user profiles in a different directory. Most likely the issue is that during Windows install it doesn’t support changing the user profile directory perhaps because paths are hard coded and/or the APIs normally used to get this information aren’t available yet. But I’m just guessing here.
Nevertheless it seems like you can change the user profile directory post install (indeed many colleges do just that) and you can change the store location path as well.
> Definitely seems odd the Store wouldn’t support this
Probably some “modern” programmer coding the “modern” Store just hardcoded
and was done with it. And instead of allocating programmer to fix that, they allocated a documentation writer to document the current state, because of course that’d seem like the correct approach for contemporary Microsoft.
From what I understand of UWP Apps (Universal Windows Platform Apps, A.K.A Windows Store Apps or Modern Style Apps in Windows 8), they run under the Windows Runtime which provides restricted/virtualized access to the file system/registry.
So to a certain extent, I don’t think the UWP App even know where the App is installed to or where the App Data is, they just call a Windows Runtime API, it returns a path and the UWP App uses it.
I don’t think a UWP App could hard code an App Path if it wanted to, the UWP app paths are long and contain some kind of ID in the path so it wouldn’t be easy to guess the path and hard code it.
The problem is not UWP apps hard coding a path, the problem is that during the development of the Universal Windows Platform in Windows 8 (Then just referred as the Windows Runtime (Or just RT, why the Modern Apps only version of Windows 8 was called Windows RT) that ran Modern Apps, it was a very confusing name for something developers/users were already not that excited about using), Microsoft decided that all UWP apps will install to “C:\Program Files\WindowsApps” and “C:\Users\[Username]\AppData\Local\Packages”.
Microsoft did add a feature to move the app to another drive but it has very specific spots where the apps and their data put on the drive they are moved to also.
I noticed recently that one very popular Windows Store app, WSL Ubuntu, does not allow the installation to be moved to a different drive. As a workaround, I exported the original distribution, reinstalled WSL Ubuntu to my D: drive, and finally imported the backup I made earlier.
Installing to D: is possible, as Windows allows nowadays the user to modify the default installation location for apps.
Haven’t encountered any issue from this “forced move” of WSL Ubuntu to a different drive, so not sure exactly why the app’s author has decided to disable the option.
Would prefer a better solution for this instead of resorting to some trickery.
What people actually want to do is point their user profiles onto another drive while keeping the system created (and store created and service created) profiles on the system drive.
I find the account per service to be ugly but there’s no good way of getting out of it so it stays.
Right now the best solution seems to be make a junk user at install; repoint it to other drive, make your main user, repoint it back. Repeat the process every time you need to add another real user.
you can achieve it via junction points without breaking anything.