Azure File Sync: Setup, Use Cases and Cloud Tiering Explained

Most organisations with on-premise file servers are not ready to move entirely to the cloud. Users expect local file access to be fast. Legacy applications write to UNC paths. IT teams have invested years in permissions structures tied to on-premise Active Directory. Azure File Sync addresses this without requiring a full cutover: it keeps a Windows file server in place as a local cache, synchronises the content to Azure Files in the cloud, and lets you move to a cloud-first storage model at a pace that suits the business.

The result is a hybrid storage architecture where the most recently accessed files are available locally at full disk speed, less-used files are transparently tiered to Azure (appearing as stubs that download on access), and the authoritative copy of everything lives in Azure Files where it can be backed up, accessed from anywhere, and protected independently of the on-premise server.

How Azure File Sync works

Azure File Sync has four components:

Azure File Share. A fully managed SMB file share in Azure Files, inside a Storage account. This is the authoritative storage location. All servers syncing to the same share see the same data.

Storage Sync Service. A management resource in Azure that coordinates synchronisation. You register file servers with it and define sync groups.

Sync Group. Defines what syncs to what: one Azure file share plus one or more server endpoints. Changes on any endpoint (including direct uploads to the Azure file share) propagate to all other endpoints.

Azure File Sync Agent. A software agent installed on each Windows Server participating in sync. It monitors the registered server endpoints and handles upload, download, and cloud tiering.

Synchronisation is bi-directional. A file created on the file server in your Cardiff office syncs to Azure Files, then propagates to any other server endpoints registered to the same sync group. This is how multi-office scenarios work without setting up DFS-R.

Prerequisites

Azure File Share: Premium (SSD-backed) file shares are recommended for sync scenarios with many files or high IOPS requirements. Standard file shares work for typical office file serving. The storage account hosting the file share should be in the same Azure region as the Storage Sync Service.

Windows Server: Windows Server 2012 R2 through 2022. The server does not need to be domain-joined to sync, but NTFS permissions and Active Directory integration work best when it is.

Network: The agent communicates with Azure over HTTPS (port 443). No inbound firewall rules are required. Outbound connectivity to *.afs.azure.net and *.azure.com domains is needed; specific endpoint URLs are documented by Microsoft and should be allowlisted if you run an outbound proxy.

Storage account firewall: If your storage account has network restrictions enabled, you need to allow the server's public IP or use a service endpoint/private endpoint from the server's VNet. Azure File Sync does not support storage accounts with both Secure Transfer Required and SAS token authentication disabled simultaneously; ensure Secure Transfer Required is enabled.

Step-by-step setup

Step 1: Create the Storage Sync Service

In the Azure Portal, search for Azure File Sync and create a Storage Sync Service resource. Choose the same region as your storage account. This becomes the registration hub for your servers.

Step 2: Create a sync group

Inside the Storage Sync Service, create a sync group. Attach it to the Azure file share you want to sync to. The cloud endpoint is the Azure file share; it represents the authoritative cloud copy.

Step 3: Install the agent on Windows Server

Download the Azure File Sync agent from the Microsoft Download Centre (or via the portal). Install it on the Windows Server that will act as a sync endpoint. During installation, register the server with your Storage Sync Service by signing in with an Azure account that has Owner or Contributor rights on the Storage Sync Service resource.

Registration requires outbound access to Azure. If the server is behind a proxy, configure the proxy address in the agent settings before registration.

Step 4: Add a server endpoint

In the sync group, add a server endpoint. Select the registered server and the local path to sync (e.g., D:\FileServer\SharedDocs). This does not have to be the root of a volume; you can sync specific folders.

If cloud tiering is being enabled (recommended for anything but small shares), configure the tiering policy here. The two tiering triggers are: - Volume free space policy: Keep a specified percentage of the volume free by tiering the least recently accessed files to the cloud. A 20% free space policy is a sensible default for volumes that are not near capacity. - Date policy: Tier files that have not been accessed for a specified number of days. A 30-day policy tiers anything not touched in a month, regardless of volume space.

Both policies can be active simultaneously and Azure File Sync uses whichever trigger is more aggressive.

Step 5: Wait for initial upload

The first sync uploads all content from the server endpoint to the Azure file share. For large shares (hundreds of GB to TB), this takes hours to days. Do not cut off the server from the network during this window. Monitor progress in the portal under the server endpoint status.

For very large initial datasets, an offline data transfer using Azure Data Box (physical appliance) or Azure Import/Export Service is more practical than uploading over a business internet connection. Seed the Azure file share with the data using the offline path, then connect the agent and let it reconcile the differences.

Cloud tiering and what users experience

With cloud tiering enabled, files that have not been accessed within the tiering policy window are replaced with sparse stubs on the local server. The stub looks like a normal file: it has the correct name, size, and metadata, and it appears in File Explorer. When a user opens it, the agent downloads it transparently from Azure Files. The experience is typically a short delay on first access for a tiered file; subsequent access within the cache window is local-speed.

Files actively being worked on are not tiered. The access tracking window (configurable, 30 days is default) ensures that files in active use stay local.

Tiered files have a special Windows attribute set. You can identify them with Get-Item -Path "C:\filepath\file.txt" | Select-Object -ExpandProperty Attributes and looking for ReparsePoint in the output. The command attrib +p filepath recalls a single tiered file to local disk without opening it, which is useful before a maintenance window or when preparing a server for decommission.

Before decommissioning a server endpoint, use the Invoke-StorageSyncFileRecall cmdlet to recall all tiered files to local disk:

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -SyncGroupName "MyGroup" -ServerEndpointPath "D:\Share"

Do this before removing the server from the sync group. Removing the server endpoint first and then trying to recall files is the wrong order and leaves tiered stubs without the agent to recall them.

Use cases

Branch office consolidation. Multiple office locations each with a local Windows file server, all syncing to the same Azure file share. Users in each office get local file access speed. IT manages one authoritative copy in Azure instead of managing replication between offices. New offices join the sync group by installing the agent on a local Windows Server.

Disaster recovery for file services. The file server on-premise is the primary. The Azure file share is the durable backup and secondary access point. If the on-premise server fails, users can access files directly from the Azure file share via SMB (with the right network connectivity) or via the Azure Portal. Recovery involves provisioning a new Windows Server, installing the agent, and registering it to the existing sync group.

Cloud-first migration. Migrate the file server to Azure Files gradually. Start sync, let the cloud share become the authoritative copy, then shift access to the cloud share as users and applications are ready. The on-premise server stays as a cache during the transition and is decommissioned when no longer needed.

Capacity management for large shares. A 20 TB file server where 15 TB has not been accessed in 90 days. Cloud tiering moves the 15 TB to Azure Files at storage account pricing, freeing expensive local disk for frequently accessed data. The full 20 TB remains accessible to users without any change to how they access files.

Monitoring and maintenance

Monitor sync health through the Azure Portal under Storage Sync Service > Registered servers. Each server shows sync status, last sync time, and any errors. Common error codes: - 0x80c80002 (ECS_E_ITEM_ALREADY_EXISTS): A file conflict exists because the same file was modified in multiple locations simultaneously. Azure File Sync does not merge conflicting changes; it keeps both, with one renamed with a conflict suffix. - 0x80c86010 (ECS_E_SYNC_METADATA_KNOWLEDGE_SOFT_LIMIT_REACHED): The sync metadata cache is approaching its limit. This usually indicates a very large number of files; consider splitting the share.

Set up Azure Monitor alerts on the sync health metrics exposed by the Storage Sync Service. Alert on items not syncing for more than 24 hours, as this typically indicates a connectivity or agent issue that will grow into a larger problem if left unattended.

Where Critical Cloud comes in

Azure File Sync is infrastructure that runs quietly when it is right and causes significant user impact when it is wrong. We manage hybrid storage architectures for businesses migrating away from on-premise file servers, with monitoring that catches sync failures before they affect users. As the world's first Powered by Datadog accredited partner, we monitor File Sync agent health, sync lag, and cloud tiering recall performance as live signals alongside the rest of the Azure estate. See how Critical Support works.