The policy is configured, it shows as applied, and nothing has moved. No error in the sync client, nothing useful in the event log, and the user's Desktop is exactly where it was. Before working through the usual policy troubleshooting, there is one condition worth eliminating, because while it holds nothing else you do will have any effect.
The blocker that makes every other check pointless
The OneDrive Known Folder Move policies do not work if Windows Folder Redirection was previously used to point Documents, Pictures or Desktop somewhere other than OneDrive. This is documented behaviour rather than a bug, and it is silent. The OneDrive policy is present, valid and ignored.
In an estate of any age this is the common case rather than the exotic one. Folder Redirection to a file server was standard practice for years, and the policy object outlives the file server, the migration project and usually the person who created it. So the first question is not whether the OneDrive policy is right. It is whether an old redirection policy is still in scope for that user.
Migrating off Folder Redirection, by where the folders point now
Three starting points, three different sequences. Establish which one applies before changing anything.
Already redirected to OneDrive
The simplest case. Disable the Folder Redirection policy, leaving the folder and its contents in place on OneDrive, then enable the Known Folder Move policy. The folders stay where they are and control passes across without a data move.
Redirected to a location on the local machine
Disable the Folder Redirection policy and leave the contents at the redirected location, then enable Known Folder Move. The folders then move up to OneDrive, so this one does involve an upload and should be paced accordingly.
Redirected to a network file share
The one that needs real planning, because the data has to be moved deliberately rather than by the sync client. Copy the file share content into the user's OneDrive first, making sure it lands in the existing Documents, Pictures and Desktop folders. Then disable the Folder Redirection policy, leaving the share contents in place as a fallback, and enable Known Folder Move so the folders move and merge with what you copied up.
One trap in that sequence: if the migration tooling creates the Documents, Pictures or Desktop folders rather than merging into existing ones, do not carry the file share permissions across with them. Preserved share permissions on a user's own known folders cause problems that are much harder to unpick later than they are to avoid now.
A folder that has already moved ignores the policy afterwards
This one gets reported as the policy being unreliable, and it is deterministic once you know it. After a known folder has been moved, the policy will not act on that folder again, even if the selection for it changes. Adding Pictures to a policy that already moved Documents on a device does nothing to Pictures on that device.
The practical consequence is that partial rollouts are sticky. If the first wave of a project moved Desktop only, those machines are not going to pick up the rest by policy, and they need handling separately. Deciding the full set of folders before the first deployment is considerably cheaper than deciding it afterwards.
Rollout guidance that looks like a fault
Where a policy appears to be working for some users and not others, and the difference does not correlate with anything in the configuration, deployment pace is worth considering. Microsoft's guidance is explicit about scale, and the numbers are lower than most people assume.
- For the silent move policy on existing devices, no more than 1,000 devices a day and no more than 4,000 a week across Windows and macOS.
- For the prompting policy on existing devices, no more than 5,000 devices a day and no more than 20,000 a week.
- Where users hold a large volume of files, the upload rate limiting policy is the recommended way to keep the network usable during the initial move.
Deploying the silent policy alongside the prompt is also worth doing rather than choosing between them. Where the silent move cannot complete, the user is prompted to deal with the error instead of the move simply not happening, which converts a silent failure into a visible one.
What these policies do not cover
Two limits that account for a fair number of reported failures. The OneDrive policies do not act on Music and Videos, so those stay wherever they are and can be left with Windows Folder Redirection if they need redirecting. And Known Folder Move does not work at all for users syncing against SharePoint Server rather than the service.
There is also the cross-organisation case, which is rare and alarming when it happens. If a user's folders are currently redirected to OneDrive in a different tenant, redirecting to yours creates fresh empty folders and the user sees an empty Desktop. Their files are intact in the other tenant, and they have to move them across by hand. Disabling the other redirect first is the only way to avoid that.
Can I force it by editing the registry values the sync client uses?
Values that record whether a silent move has already run do circulate in community threads. They are undocumented, unsupported, and they treat a state marker as a switch. On a managed estate the sequencing above is the change that holds.
Does the user need to be a local administrator?
No. The policy acts through the sync client running in the user's own context, which is also why a device with the policy applied and the client signed out does nothing.
How do I confirm the policy actually reached the device?
Check it as you would any other policy, at the device rather than in the console. A policy that is linked correctly and filtered to a group the user is not in is the most ordinary explanation of all, and worth eliminating before the harder causes.