Offline Files lets Windows keep cached copies of network files for use while disconnected. When synchronisation fails, the workstation and file server may each contain unique valid work. Resetting the cache before reconciling both sides can destroy the only current copy.

Freeze avoidable changes

Ask the user to stop editing affected files. Record the exact UNC/DFS path, Sync Center status, conflicts, last successful sync, current network and recent server/namespace/permission/Folder Redirection changes.

Identify whether the user is reading the server copy or cached copy. Network access to some shares does not prove this path is online; Windows can serve cached content when UNC prefix resolution or permissions fail.

If storage is failing or malware is suspected, preserve evidence and recover the disk before synchronisation attempts.

Protect both data sets

Inventory important files visible offline and on the server separately, including size, modified time and selected hashes. Export/copy unique cached user data through an authorised context to a protected recovery location before disabling Offline Files or clearing anything.

Do not copy only what appears in the user’s normal folder view. Confirm which items are available offline, pending, conflicted or excluded. Preserve EFS/information-protection recovery where relevant; ACL changes do not decrypt protected data.

Treat Offline Files as a working cache, not a durable backup. Establish a real backup of recovered data.

Diagnose why Windows is offline

Check the path layer by layer:

  • client IP, DNS and time;
  • VPN/network connection where required;
  • server and SMB reachability;
  • every UNC or DFS namespace prefix;
  • share and NTFS permissions;
  • name/namespace referral changes;
  • effective Offline Files and Folder Redirection policy; and
  • Sync Center events/status.

Microsoft documents cases where a user can reach parts of the network but lacks permission at an intermediate share/namespace level. Prefix resolution fails and Client-Side Caching continues presenting offline content. Fix the precise path/permission rather than assuming the cache is corrupt.

Check whether slow-link or offline policy deliberately placed the path offline. A manual Work Online attempt that immediately reverses is evidence of an unresolved path or policy condition.

Reconcile conflicts explicitly

Classify each divergent item:

  • identical content with different metadata;
  • local-only change;
  • server-only change;
  • both changed; or
  • deleted on one side.

The latest timestamp is not always authoritative, especially after clock or restore changes. For both-changed files, preserve both versions with clear neutral names and let the data owner decide or merge them in the application.

Record decisions and verify the resulting server version. Do not bulk choose “keep server” or “keep local” until the conflict set and owner are known.

Restore normal synchronisation

After correcting connectivity, namespace, permission or policy, bring the path online and run a controlled sync. Start with a small representative folder. Watch Sync Center and relevant events; compare server and client results after the sync.

Test:

  • server-to-client update;
  • client offline edit followed by reconnection;
  • a deliberate conflict and chosen resolution;
  • access after restart and network transition; and
  • Folder Redirection through the same path if used.

If normal sync returns, keep the recovery copy until the observation period passes.

Reset the cache only after recovery

Consider cache reset only when the local CSC database is proven unusable and all valuable local content has been recovered and reconciled. Historical registry techniques that request cache formatting are destructive on restart. They should never be the opening troubleshooting step or a casual response to a red Sync Center icon.

Capture policy and cache state, obtain data-owner acceptance and ensure the server holds the approved copies. Apply the current Microsoft-supported recovery for the exact Windows release, then re-enable/pin content only if the architecture still requires Offline Files.

If retiring Offline Files, decide how mobile/offline work will be supported—such as a current sync platform, VPN plus online-only share, or managed local workflow—before removing it.

Verify recovery and ownership

Completion requires:

  • all unique local and server files accounted for;
  • every conflict resolved by the appropriate owner;
  • intended UNC/DFS path available with correct permissions;
  • online/offline transitions and sync tested;
  • redirected folders point to the intended authority;
  • recovered data included in verified backup; and
  • no hidden dependence on the old cache remains.

The goal is not to make Sync Center show green. It is to preserve the user’s work and restore one explainable authoritative copy with a safe offline workflow.