QWT: redirect known folders instead of relocating user profile

[iamahuman]

The problem you're addressing (if any)

• To move towards removing "move user profile" which does not always work properly in Windows 10.
• To use a documented and supported way of relocating user data for moving user data to the private volume.

Describe the solution you'd like

• Remove the NT native application responsible for relocating the user profile.
• Use Win32 IKnownFolderManager::Redirect (COM) to migrate individual user directories instead.

Where is the value to a user, and who might that user be?
Properly working user profile migration, without risking Windows Update.

Describe alternatives you've considered
Not applicable.

Additional context
Moving the user profile to another volume is unsupported by Microsoft and known to break updates which involve filesystem transactions spanning both system files and user profiles. See the following docs from Microsoft for more information.

TODO: decide specifically which directories are suitable for migration. Specifically, redirecting AppData (Local, LocalRow, and Roaming) seems possible, but would it break if the destination is another volume?

Relevant documentation you've consulted

• Relocation of the Users directory and the ProgramData directory to a drive other than the drive that contains the Windows directory (Microsoft Support)
• ProfilesDirectory | Microsoft Docs (Windows 8.1 and earlier)
• ProfilesDirectory | Microsoft Docs (Windows 10)
• IKnownFolderManager::Redirect (shobjidl_core.h) - Win32 apps | Microsoft Docs

Related, non-duplicate issues
TBD

[marmarek]

Isn't that going to break user registry changes (HKEY_CURRENT_USER branch)? When only some folders will be moved to "private" volume (the only persistent in TemplateBasedVM), other parts of the user profile will be reset on VM restart.

[iamahuman]

@marmarek You mean Ntuser.dat?

Thinking about it, if an update makes changes to the user registry, it won't be applied to TemplateBasedVMs, but moving Ntuser.dat to foreign volume might break the update.

Perhaps do some weird tricks to HKU and HKCU, in the same manner as how Qubes Linux VMs bind mount /rw/home to /home?

[marmarek]

Thinking about it, if an update makes changes to the user registry, it won't be applied to TemplateBasedVMs, but moving Ntuser.dat to foreign volume might break the update.

How is that different from performing update on one user and then logging into another? That should work by design.

[iamahuman]

@marmarek If both users are local, then Windows Update will apply changes to both of them at the same time.

For Qubes however, the user profiles in the TemplateBasedVMs are not visible at the time the update is applied.

Since "roaming profiles" are a thing, perhaps we can do away with somehow tricking Windows into thinking a user profile migration has happened when starting a TemplateBasedVM after updating its TemplateVM. This might perhaps trigger the annoying "getting user profile ready" dialog, but I know nothing about this route yet.

The most ideal scenario is that Windows will automatically recognise outdated registry and perform changes accordingly.

Side note: in a Windows system with multiple local users, does it attempt to update the system and all the users atomically at once even if one or more of them are logged out at the moment and will not necessarily require completely synchronised update in the same transaction?

[bi0shacker001]

Out of curiosity... Windows allows folder mounts. Can't we just mount the private disk on C:/Users ?

[DemiMarie]

@bi0shacker001 To me, that seems like the best option by far. A user profile migration can be triggered to handle system updates. Windows used to not support updates in this case, but that has been fixed. I think.

[omeg]

The current profile mover creates a symlink instead of a mount point. I'll be testing various methods soon to see how they behave (might be tricky with needing a system update to properly test...).

From the docs the IKnownFolderManager::Redirect API only allows redirecting particular user's profile, not the whole Users directory -- this might be enough if the user won't create new accounts or there's a way to set a default location for new profiles.

Edit:
Apparently even the user's profile root can't be relocated (%USERPROFILE% (%SystemDrive%\Users\%USERNAME%))

Note The user profile root folder (FOLDERID_Profile) does not support redirection.

Only subfolders of the profile (like Downloads, Documents etc) can be relocated by this method. This is useless for our purposes then because user's registry data is kept in a file in the root of their profile.