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

Text Description automatically generated with medium confidence

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.

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 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 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.

Logo, company name Description automatically generatedMagic 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 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:

  • vti_DesktopFolderGuid
  • vti_DocumentsFolderGuid
  • vti_PhotosFolderGuid
  • vti_CameraRollFolderGuid
  • vti_ScreenShotsFolderGuid

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.

Now what?

Part 2 is now available. I’ll get up close and personal with this metadata and explain how to make it fall in line.

0 0 votes
Article Rating

Niels Scheffers

I'm what you'd call a geek. I love technology (in any shape or form), collectibles, Back to the Future and so many other things. Most of all though, I love my wife, dog and two cats. Whenever I'm not working I spend as much quality time with them as possible. After working for a cloud service provider for more than 20 years, I recently switched jobs. I started working for a small but great company (Etesian IT Consulting, https://etesian.nl/) with huge ambitions (and they've been living up to it).

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments