Azure File Sync: Architecture, Limits, and the Best Way to Use It

Date October 23, 2025
Blog Main Image

TL;DR

  • Azure File Sync is best used as a migration tool.

  • Azure File Sync (AFS) caches Azure file shares on Windows Server and syncs changes between endpoints.

  • Cloud-side changes are discovered by a scheduled change-detection job that runs every 24 hours, not in real time.

  • Concurrent edits create conflict copies; AFS keeps both versions and can create up to 100 conflict files per original.

  • Open file handles and record-locking across sites are not coordinated for live coauthoring; handling issues often requires closing or enumerating file locks.

  • Use AFS for migrations, branch caching, and DR. For user access, expose Azure Files natively via MyWorkDrive or VDI for fast, secure, VPN-free access.

What Azure File Sync Is

Azure File Sync diagram with Azure Files at center, on-prem Windows Server cache, users, and internet access with secure arrows.

Azure File Sync centralizes Windows file shares in Azure Files while letting you cache and serve data from Windows Server close to users. It supports SMB/NFS access on-prem and keeps a cloud copy in Azure for scale and protection.

Azure File Sync is best used as a migration tool (to move from on-prem to Azure File Shares) and as a one-way backup (for DR/recovery).

How Sync Actually Works

Timeline showing Azure File Sync near-real-time server-to-cloud and 24-hour cloud-to-server change detection.

  • Server → Cloud: AFS monitors the Windows Server USN journal and syncs promptly.

  • Cloud → Server: AFS detects Azure file share changes using a scheduled change-detection job that enumerates the share and triggers a sync. Runs every 24 hours by design. Admins can force detection with Invoke-AzStorageSyncChangeDetection when needed.

Implication: Cloud-side edits are not discovered in real time, and large namespaces can take longer than 24 hours to fully enumerate.

Collaboration Limits You Must Plan Around

Flow showing two users editing the same file leading to a conflict copy in Azure File Sync due to 24-hour cloud change detection.

1) Not real-time, multi-writer collaboration

AFS is bi-directional, but cloud changes are discovered on a schedule. Concurrent edits across sites lead to conflict copies rather than true global locking. See community discussion: r/AZURE: “Azure File Sync for realtime collaboration?” and r/sysadmin: Azure Files.

2) Conflict handling and version sprawl

AFS keeps both changes and renames the older file (e.g., Report-ServerName-1.docx). It supports up to 100 conflict files per original before sync fails until conflicts are reduced. Refer to Azure Files FAQ.

3) Open/active files and locks

Open handles can block or delay sync. Ops teams often need to list and close file handles (Get-AzStorageFileHandle) to resolve issues; see Microsoft troubleshooting linked above.

When Azure File Sync Shines

  • Migrations to Azure Files: Seed data, cut over, then retire legacy servers. See Plan for an Azure File Sync deployment.

  • Branch caching and consolidation: Keep hot data local, cold data tiered, with Azure as authoritative storage.

  • Disaster recovery: Maintain an Azure copy; promote or rehydrate on demand.

When It Struggles

  • Real-time coauthoring across multiple sites

  • Workloads that depend on strict, cross-site file locking

  • Rapid cloud-side edits that users expect to see instantly on-prem

In these cases, expect conflict copies and manual resolution.

SMB over QUIC: Helpful, but Mind the Constraints

SMB over QUIC can provide secure, TCP-445-free access over UDP 443 and modern TLS. It requires specific OS versions and configuration, and Azure Files doesn’t directly support SMB over QUIC without using a Windows Server cache (e.g., AFS) to front the share. Evaluate prerequisites, client support, and latency.

A Practical Architecture That Works

Reference architecture showing MyWorkDrive handling user HTTPS access to Azure Files while Azure File Sync handles server–cloud synchronization for migration and DR.

Use Azure Files as the durable store. Give users native, HTTPS access without VPN or sync using MyWorkDrive:

  • Direct access to Azure Files and Azure Blob via REST with Entra ID in MyWorkDrive Server 7+.

  • Mapped drive, web, and mobile clients over port 443 with DLP, device approvals, and detailed logging.

  • Keep NTFS/ACLs and data sovereignty while avoiding sync conflicts for day-to-day access.
    Start here:

  • Azure File Shares & MyWorkDrive Remote Access

  • Azure Storage with Entra ID in MyWorkDrive (KB)

  • Compliance overview and Data sovereignty

Best-Practice Checklist

  1. Pick the right access pattern: Use AFS for caching/migration/DR. Use MyWorkDrive or VDI for daily user access to avoid conflict storms.

  2. Minimize cross-site concurrent editing: Structure shares and workflows to reduce multi-writer hotspots.

  3. Force detection when needed: Use Invoke-AzStorageSyncChangeDetection after large cloud-side changes.

  4. Monitor conflicts: Review and resolve conflict copies before hitting the 100-file limit. See Azure Files FAQ.

  5. Watch open handles: Enumerate and close stale locks on Azure file shares during incidents with Get-AzStorageFileHandle.

  6. Plan for namespace scale: Large trees extend change detection times; keep shares sensibly scoped.

Common Questions

How MyWorkDrive Complements Azure File Sync

MyWorkDrive provides secure HTTPS access to Azure Files and on-prem shares without VPN or sync, keeps NTFS ACLs, and adds DLP, auditing, and device approvals. It lets you place AFS where it fits best—migration and DR—while giving users fast, direct access that avoids conflict copies. Explore MyWorkDrive for Azure and Azure File Shares & Remote Access.

Table of Contents