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 Dutch folder names. I couldn’t, for the life of me, see the logic in it.
At first Oktay and 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.
|I’ve grown up a little…
Since embarking on my first adventures in blogging, with the gracious help of Oktay, I’ve created my own blog: threeisacloud.tech. This post was re-published there (albeit in slightly redacted form). The version here will stay, forever reminding me of my roots.
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 by 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 Known Folders in OneDrive using Known Folder Move (KFM), it evaluates a couple of things to determine which language to use:
- 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
PreferredLanguagein (Azure) AD or the portal, OneDrive will follow that instead of the display language.
SOFTWARE\Policies\Microsoft\OneDrive\KfmForceWindowsDisplayLanguageis set to 1 (in
HKCU), the default behavior (display language) is enforced. Even when the user has set a different
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.
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 simply synchronized to your client(s) without any issue. Sure, you’ll still see the same
LocalizedResourceName, but the folder name on 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:
Note: a big thank you goes out to Patrick Lamber for pointing me in this direction.
Please visit his blog, the only place on the entire internet (according to Google) where these properties are mentioned.
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 foldernames in all endpoints from then on.
That said, SPMT is a wonderful tool. Just keep in mind that it simply lifts and shifts your data and then moves on.
Part 2 is now available. I’ll get up close and personal with this metadata and explain how to make it fall in line.