PC Folder Backup (which was previously known as Known Folder Redirect) is a rather useful feature that’s been added into OneDrive. It allows the redirection of users Desktop, Documents and Pictures folder for a user to live in a folder in OneDrive under the user’s profile (e.g. C:\Users\bgates\OneDrive – Contoso\Desktop ). This in turn causes OneDrive to automatically sync the data to the user’s OneDrive cloud based storage, and works a bit like having a roaming profile, without the many issues that plague actual roaming profiles.
Stephen Rose wrote a great post on how it all works with screenshots, check that out if you’re still looking at testing this solution.
An issue that I’ve come across while rolling out, was the duplication of desktop shortcuts. The problem is that OneDrive won’t match files that are ‘identical’ unless they’re Office documents; a local file called test.lnk on your desktop, and another file in OneDrive in the Desktop folder called test.lnk from a previous sync on a different computer will result in the new one being called test – Copy.lnk, and the older one synced back – you now have a test.lnk and test – Copy.lnk file on your desktop.
This wouldn’t normally happen when you log onto a computer for the first time, but many companies deploy shortcuts (usually through Group Policy). What happens is, you log onto a PC for the first time, Group Policy deploys the shortcuts to the desktop you need, then OneDrive kicks in and starts its PC Folder Backup process. I had 4 copies of each shortcut we were deploying before I noticed the mess that my desktop had become!
I asked around and was determined to work out a reasonable solution:
You can’t just block .lnk files from OneDrive without causing end user errors for everyone trying to automatically sync those.
You can run a script at startup to delete any “* – Copy*.lnk” file on the user’s desktop after logon, but that’s really a hack solution and an absolute last resort.
You can use Group Policy Preferences to delete any “* – Copy*.lnk” from the user’s desktop which is slightly better than a script, but it won’t run at the right time – the user will see duplicates for ~90 minutes after logging in before they get cleaned up, each time they log onto a new PC (which shouldn’t happen THAT often).
You can’t deploy shortcuts once through Group Policy, because the setting to ‘Run once and don’t reapply’ is a per user/per PC setting (unless you have roaming profiles, but you can’t do roaming profiles and PC Folder Backup at the same time unless the folders are excluded from one or the other) – so each time a user logs onto a PC for the first time, it’ll still trigger the shortcut deploys.
The best solution I came up with (and by that, I mean I asked in the Windows Admins Discord and someone said ‘just do it this way’), was to use the Public desktop rather than the user’s desktop.
The Public desktop (located by default in C:\Users\Public\Desktop) are files that everyone who logs onto a PC gets, and because they’re not part of the actual user’s desktop, they’re untouched by PC Folder Backup.
Because I had live shortcuts to clean up too, I first created and tested deleting copies as mentioned above through Group Policy Preferences. I then:
- Replaced any global shortcut a user needed to %CommonDesktopDir%\file.lnk – not in logged-on user’s context
- Deleted any existing shortcut deployed from %DesktopDir%\file.lnk in the logged-on user’s context
- Replaced any shortcut a specific user group needed to %CommonDesktopDir%\file.lnk – not in logged-on user’s context, with item level targeting
- Deleted any shortcut that was only being deployed to a specific user group, but out of the scope of the above item level targeting from %CommonDesktopDir%\file.lnk
This slightly messy but workable method means the shortcuts will get juggled around if only certain users should see them, and they’ll all live in the Public folder.
I’ll update this if things change with PC Folder Backup, but for the time being this lets the project continue, and users won’t be impacted with shortcut duplicates.