OneDrive Known Folder Move Not Applying via Intune
A practical troubleshooting guide for when KFM works in GPO, but fails or “does nothing” in Intune.
The problem (what you see)
You deploy OneDrive Known Folder Move (KFM) with Intune expecting Desktop, Documents, and Pictures to silently redirect into OneDrive. Intune reports the policy as applied, OneDrive launches, but:
- Folders do not move
- Users still save locally
- You may see it work only after a second sign-in, a reboot, or after OneDrive is restarted
- In hybrid or Autopilot scenarios, behavior feels inconsistent compared to GPO
This is one of the most common “looks compliant but doesn’t execute” issues with OneDrive policy delivery via MDM.
Why this happens (the core cause)
In many environments, OneDrive starts before the Intune policy is fully applied to the user session.
With Group Policy, settings often land earlier in the logon sequence. With Intune (MDM), settings can arrive after the user session is already active and after OneDrive has already initialized. If OneDrive reads its configuration before the KFM values exist, it will not trigger the folder move until it re-evaluates settings (often next sign-in or restart).
What “good” looks like (expected sequence)
KFM is most reliable when this order happens:
- User signs in
- OneDrive silently signs in (or is already authenticated)
- KFM policy is present before OneDrive evaluates it
- OneDrive performs the move and sets state flags
- Folder paths redirect and remain consistent
If step 3 happens after step 2, KFM often fails silently.
The top reasons KFM doesn’t apply via Intune
1) Policy timing: OneDrive starts too early
This is the most frequent issue. You’ll notice:
- Works after reboot or second login
- Works for some users and not others
- Works on freshly built devices but not existing user profiles
2) Silent sign-in is not effective
KFM depends heavily on OneDrive being signed in without prompts. If the user must interact with sign-in dialogs, KFM may never trigger silently.
3) Conflicting policies block the move
Certain OneDrive restrictions can unintentionally prevent the folder move from executing. This can happen when multiple profiles or legacy settings overlap.
4) Wrong targeting (device vs user)
KFM is fundamentally a user experience and user profile change. If you apply it in a way that doesn’t reliably land in the user session early enough, KFM becomes inconsistent.
5) Existing state on the device
If the device already has OneDrive configured, or prior redirection attempts occurred, OneDrive may treat the folders as already processed, blocked, or in a different “known folder state” than expected.
Step-by-step: How to troubleshoot and fix it
Step 1: Confirm OneDrive is actually signing in silently
Check these realities:
- Does OneDrive sign in without user interaction?
- Does it complete first-run without user prompts?
- Are there any conditional access prompts, MFA prompts, or device compliance prompts at first login?
If silent sign-in is not clean, fix that first. KFM is downstream from successful sign-in.
Step 2: Make sure you’re deploying the right KFM settings in Intune
In Intune, your KFM policy should typically include:
- Silently sign in users to OneDrive sync app
- Silently move Windows known folders to OneDrive
- Prevent users from redirecting known folders back to their PC (use carefully, see below)
If you set “prevent redirecting back to PC,” ensure it isn’t colliding with other folder redirection behavior or legacy configuration.
Step 3: Remove conflicts and duplicates
Common ways admins accidentally break KFM:
- Multiple OneDrive configuration profiles targeting the same users
- A mix of Settings Catalog + Administrative Templates for the same setting
- Legacy GPO remnants still stamping values in the background
- Conflicting restrictions that prevent changes to folder location
Best practice: consolidate OneDrive settings into a single, well-governed Intune policy set (or as few as practical).
Step 4: Fix the “policy arrives late” problem
This is the “real-world” solution path.
Option A: Force OneDrive to re-check policies after they arrive
If OneDrive starts too early, you can trigger re-evaluation by restarting OneDrive after the device has checked in.
Practical approaches:
- Deploy a remediation script that:
- Checks if KFM has not completed
- Restarts OneDrive
- Optionally triggers a sync refresh
Option B: Delay OneDrive startup on first login
In some environments, delaying OneDrive’s startup slightly gives Intune time to deliver user policy before OneDrive initializes.
Option C: Use a Win32 app wrapper to control order
If you need deterministic behavior:
- Package a small Win32 “OneDrive configuration helper”
- Run it after enrollment and user context is established
- Ensure it runs once per user profile
Step 5: Verify KFM actually executed
Don’t stop at “policy applied.” Confirm the outcome:
- Desktop/Documents/Pictures are now pointing to OneDrive locations
- Files appear in OneDrive portal (and sync status is healthy)
- Known folder paths are consistent across reboots
- OneDrive shows normal sync status (no stuck “processing changes” or auth loops)
If possible, validate on:
- A new user profile on a known-good device
- A device that previously worked under GPO
- A hybrid-joined device versus an Entra-joined device
This helps isolate “timing” vs “conflict” vs “authentication.”
Hybrid and Autopilot considerations
If you’re in hybrid Autopilot (or hybrid join scenarios), expect more race conditions:
- Domain join and user profile creation timing varies
- Policy delivery can be less predictable at first login
- OneDrive may initialize before user policy settings are complete
In those cases, it’s common to:
- Keep KFM on GPO temporarily (if stable there)
- Or use the restart/delay method to make Intune behavior reliable
A clean, reliable rollout strategy
If you want KFM to stick at scale, roll it out like a migration project:
- Pilot with a small user group
- Ensure silent sign-in is flawless
- Deploy KFM to users (not devices)
- Eliminate conflicting OneDrive policies
- Add a “OneDrive restart after policy” safety net if needed
- Monitor outcomes, not just compliance
Quick checklist (use this when it “applies” but doesn’t move)
- OneDrive signs in silently with no prompts
- KFM policy is targeted to the user and delivered consistently
- No duplicate/conflicting OneDrive profiles in Intune
- No leftover GPO or legacy redirection settings interfering
- OneDrive restarts or re-evaluates after policy arrives
- Folder paths confirm actual redirection, not just policy state
Conclusion
When Known Folder Move works in GPO but not in Intune, the culprit is usually not the setting itself. It is the timing and session order of when OneDrive reads configuration versus when Intune delivers it. The most reliable fix is to ensure silent sign-in is solid, remove policy conflicts, and give OneDrive a trigger to re-evaluate settings after Intune policy lands.
