OneDrive and its (Un)known Folder Move (KFM) – Part 1

Sometimes I stumble upon app behavior that intrigues me. In this case, there appeared to be a disconnect between the naming of Known Folders in OneDrive across users. Somehow, some users had English folder names, while others showed folder names in another language (in this case, Dutch). I couldn’t, for the life of me, see the logic in it.

Previously known as…
This was originally published on December 9th, 2022 as a guest post for allthingscloud.blog. It’s been (slightly) redacted and placed here as its permanent home. You can still read the original here.

Imagine that

At first I figured it had to be related to the Windows image or, to be specific: its language. We installed the exact same image (and language) on all devices and lo and behold…

It didn’t make any difference whatsoever. The folder names seemed to be unaffected by the image language.

RTFM

Time to hit the docs (because who reads the manual first)! First, just to be sure, I refreshed my memory about how Known Folders are created in Windows:

• Folders are always created using English names (such as “Desktop” and “Documents”). Unless you’re still using XP. Please don’t do that.
• A (hidden, system) desktop.ini-file is placed to configure display name (LocalizedResourceName), icon (IconResource) and other ‘special’ configuration.
• The folders (and it’s Quick Access counterpart) are configured in registry (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders).

However, OneDrive’s Known Folder Move (KFM) fancies itself a bit of a multi-national and likes to create folders in different languages. While provisioning these folders in OneDrive using KFM, it evaluates a couple of things to determine which language to use for their names:

• By default, the Windows display language is used. When you use an English ISO, you get English folders (“Desktop”, “Documents”) and when you use a Dutch ISO, you get (duh) Dutch folders (“Bureaublad”, “Documenten”).
• If the user has set a PreferredLanguage in (Azure) AD or the portal, OneDrive will follow that instead of the display language.
• If SOFTWARE\Policies\Microsoft\OneDrive\KfmForceWindowsDisplayLanguage is set to 1 (in HKLM or HKCU), the default behavior (display language) is enforced. Even when the user has set a different PreferredLanguage.

After the client has determined the folder names, they are created in OneDrive. KFM then ‘redirects’ the local folders to the OneDrive folders.

Our users didn’t set a PreferredLanguage, and the display language was the same now, so why were there still differences between users? My dear reader, you may have already noticed the mother of all [censored] we made… We assumed existing data in OneDrive was irrelevant.

It. is. not. Not even remotely.

Magic mechanic

Turns out, there’s a mechanic at work which allows KFM to determine if there are already Known Folders present in its cloud-data. If so, any connecting client will follow the naming of these cloud folders.

You can (kind of) see this tight coupling in action: just rename your “Documents”-folder via the OneDrive-portal. That change is then synchronized to your client(s) without a hitch. Sure, you’ll still see the same LocalizedResourceName, but the folder name in your filesystem will have changed.

So, can we simply create folders with the same name? Nope, this mechanic is smarter than that. The “Documents” list (not to be confused with your “Documents” folder which is actually a folder inside this list… you know, just to keep you on your toes) contains some metadata telling a connecting OneDrive-client which folders in its dataset are Known.

The following properties will point to a folder-object. Their names will be used (or created) during KFM:

• vti_DesktopFolderGuid
• vti_DocumentsFolderGuid
• vti_PhotosFolderGuid
• vti_CameraRollFolderGuid
• vti_ScreenShotsFolderGuid

A big, BIG thank you goes out to Patrick Lamber. Please visit his blog: the only place on the entire internet (according to Google) where these properties are mentioned. Well… were mentioned, as this post now joins that small club.

And it all comes together

This journey started in a tenant where user-data was moved from home folders to OneDrive using SharePoint Migration Tool (SPMT). The home folders contained Known Folders using the (filesystem) English naming convention.

Then, new clients where deployed on endpoints. The Dutch language endpoints simply created a new (localized) folders, like “Bureaublad” and “Documenten” and corresponding metadata (ignoring the folders created by SPMT) during KFM. The English language endpoints (almost accidentally) used the already provisioned folders and then created corresponding metadata, as their naming collided.

Once the metadata was in place, the folder names became ‘solidified’ (via the metadata in the Documents-list) and followed the user across endpoints in all languages.

My advice is to use KFM as soon as possible. That way, Known Folders will be provisioned correctly at an early stage, and you will have consistent folder names in all endpoints from then on. But, SPMT is a wonderful tool. Just keep in mind that it simply lifts and shifts your data and then moves on.

Now what?

Continue with OneDrive and its (Un)known Folder Move (KFM) – Part 2, of course! I’ll get up close and personal with this metadata and explain how to make it fall in line using my favorite method: PowerShell.