A user had been running Windows Server Essentials with folder redirection via Group Policy. Desktop, Documents, and Pictures were all redirected to a server share. They migrated away from WSE, stood up a new server, but their old laptop still had all the GPO registry state sitting there. When they tried to enable OneDrive Known Folder Move, it wouldn't budge. The error: Capabilities: 0x101. The Location tab for Documents, Desktop, and Pictures was greyed out entirely.
This turned into a several-hour archaeology dig. Here's what we found, layer by layer.
Layer 1: Standard registry cleanup wasn't enough
The obvious first step: go to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders and fix all the entries still pointing to the old server share. Updated the standard Known Folder GUIDs to local paths. Still broken.
The reason: Windows Server Essentials writes its own non-standard GUID variants into that key alongside the standard ones. Generic cleanup scripts target the well-known GUIDs and leave the WSE variants untouched. For example:
Standard SavedGames GUID: {4C5C32FF-BB9D-4518-B176-DEC04FF96F7E}
WSE variant: {4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4}
Standard Links GUID: {BFB9D5E0-C6A9-4D9F-9667-1F64AD761B0C}
WSE variant: {BFB9D5E0-C6A9-404C-B2B2-AE6DB6AF4968}
Notice how the GUIDs share the first two segments but diverge after that. Any script built from the standard KF GUID list will miss these entirely.
Layer 2: There are two registry keys, and only one got fixed
There's an important distinction between:
User Shell Folders -- the policy template; where Windows looks to know what the path should beShell Folders -- the resolved runtime cache; what the shell is actually using right now
The fix scripts updated User Shell Folders. Shell Folders still had all the old server paths. Why? Because the user had not logged off since the scripts ran. Windows only rebuilds the cache from the template at logon. The shell was still running against the old state.
Both keys need to be clean. Updating the template while the cache is stale does not help until the next login -- and if the user does not log off, the stale cache stays indefinitely.
Layer 3: The silent API bug
Even after fixing both keys, the Location tab was still greyed. This is where it got subtle.
The script was calling SHSetKnownFolderPath -- the Windows shell API that lets you programmatically update known folder paths -- with flags=0x4000 (the KF_FLAG_DONT_VERIFY flag). Seemed reasonable. It did not throw an exception. It returned a result code. The script moved on.
Problem: according to MSDN, the flags parameter on SHSetKnownFolderPath is reserved and must be 0. KF_FLAG_DONT_VERIFY is only valid on the GET call (SHGetKnownFolderPath). The SET call was returning 0x80070057 (E_INVALIDARG) on every invocation -- silently, because the script was not treating non-zero return codes as hard failures.
What this means in practice: the registry was clean, but the shell maintains its own internal known folder state that is not just a mirror of the registry. That internal state was never updated. OneDrive reads that internal state when it checks KFM eligibility. So from OneDrive's perspective, the folders were still policy-managed, regardless of what the registry said.
The fix that actually worked
After correcting the API flags to 0 and running the script again -- it still did not clear. At that point, the shell state was too corrupted for incremental repair to be reliable.
Two-step nuclear option:
- Wipe the user profile entirely via WMI (
Win32_UserProfile deletion -- removes the profile folder, the ProfileList registry entry, and all associated state)
- Install OneDrive in per-machine mode:
OneDriveSetup.exe /allusers /silent (puts it in C:\Program Files\Microsoft OneDrive instead of the user's AppData, so it survives a profile wipe and is available on fresh login)
User logged in, OneDrive KFM enabled on first attempt.
What to remember if you hit this
- WSE folder redirection leaves non-standard GUID variants that standard KFM repair scripts will not touch
User Shell Folders and Shell Folders are two separate keys -- the runtime cache does not update until logoffSHSetKnownFolderPath with flags=0x4000 fails silently; the flags parameter must be exactly 0- Registry edits bypass the shell's internal known folder state -- they're necessary but not sufficient; the API is the only thing that updates the shell layer
- If you've been at it for a few hours: profile wipe +
OneDriveSetup.exe /allusers /silent is 10 minutes and a clean slate
This came out of a real migration where a GPO outlived the server that set it. Folder redirection and OneDrive Known Folder Move interact badly enough that we check for it by default in our Microsoft 365 work — there's a full migration write-up if you want to see how we approach one. If you're mid-migration and stuck here, we can take it from you.
