This message was deleted.

Known folders simply redirects these folders to the users local ondrive folder. You could set GPO to just redirect there instead of a share.

There are sometimes two entries for Desktop under HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserShellFolders, check there

sorry i probably wasn't clear in my description.....we are working on a project where we're migrating that content ahead of time w/ the sharepoint migration manager (that part is working fine) and then at the same time, revert the current on-prem folder redirection to local and have the new onedrive policies kick in to now look to onedrive for those folders. it works fine as long as those folders revert back to local and for some reason its doing it correctly for all except desktop

Check the UserShellFolders and ShellFolders keys. 👆

hmm i did look in that location and thought there was just the 1 for desktop but i'll double check. and it still holds onto that on-prem share for some reason. i thought i could just change that key value but that wont be too seamless if say one night we are doing a batch of users the plan was to reboot their desktop, migrate content and move them from an OU w/ the current redirection policy to another that instead has the onedrive known folder policies

Well known folders is going to modify the Desktop value in ShellFolders anyway.

Check for any values pointing to a [GUID] that also have references to Desktop in their data

true......except it seems like the known folder move is failing since its still seeing folder redirection in place it seems

Might be worth checking this out, as well: https://github.com/JamesKindon/Citrix/blob/master/SetShellFolderDefaults.ps1

that looks interesting.....i wonder if that can be run when no user is logged in (to say reset those folders for all local accounts). if so i can maybe work w/ that since i could reboot everyone first and run a gpupdate and run that script on the desktops as a next step to clean stuff up

Probably not, as it hits HKCU.

damn ya i just saw that. i had initially thought i could use WEM to run something like this on first logon but i'd need that first logon to run something like this to clean things out and THEN process the OneDrive Known Folder policies to look to Onedrive for the newly moved content. so gonna be a weird timing issue i'm afraid

I forgot you use WEM...

the hope was i could rely on that group policy redirect back to local to work properly (which it ALMOST does)....and then use PDQ to throw in a gpupdate /force and a couple of reboots for good measure and then when they log in next from the Onedrive OU those known folder policies would just work. and i'm so friggin close.....if i manually fix that desktop key first it all works great

I don't have KFM enabled in my environment, instead use WEM to handle the redirection,

you use WEM to redirect to Onedrive?

Yep

so in a case like this where network folder redirection is in place i wonder if the WEM way would override things better. at the very least maybe something i can look at. i know our company wants to stick w/ GP known folder move as most as possible

Using any profile management that might be roaming the registry settings back in?

no pretty vanilla outside of the folder redirection. we use fslogix but only for hiding rules (i tried removing that but same issue)

No, that's a set process. This photo is old, but should still be relevant:

alright so the Desktop specific issue turns out i'm an idiot.....to try and simulate a real user w/ my test account i copied some folders w/ files to that test accounts share folder for the Desktop and forgot doing that copy as me does not give permissions to the user and that appears to be what was stopping it. my issue now is why is it copying all the data local when it reverts when we have that setting disabled (i think thats why it was failing since there was an access denied on that one folder when it tried to move it local)

So it's Moving even though the 'Move Contents...' setting is disabled?

so i found out that the issue was we had that setting in place and then would log into a desktop in an OU w/ onedrive settings to do the known folder move . anyways i learned that even w/ the redirect back to local setting , it was still holding onto the network path for those folders (not sure if thats by design or not). so i'm running a WEM run once task for a powershell script that resets those HKCU keys to local and re-runs the onedrive client to process those onedrive policies. so what was happening is , since it still was looking to those network locations, onedrive thought it still had to move the files. so far thats the theory 🙂