In this article

Planning for an Azure File Sync deployment

In this article

Use Azure File Sync to centralize your organization's file shares in Azure Files, while keeping the flexibility, performance, and compatibility of an on-premises file server. Azure File Sync transforms Windows Server into a quick cache of your Azure file share. You can use any protocol that's available on Windows Server to access your data locally, including SMB, NFS, and FTPS. You can have as many caches as you need across the world.

Azure File Sync terminology

Before getting into the details of planning for an Azure File Sync deployment, it's important to understand the terminology.

Storage Sync Service

The Storage Sync Service is the top-level Azure resource for Azure File Sync. The Storage Sync Service resource is a peer of the storage account resource, and can similarly be deployed to Azure resource groups. A distinct top-level resource from the storage account resource is required because the Storage Sync Service can create sync relationships with multiple storage accounts via multiple sync groups. A subscription can have multiple Storage Sync Service resources deployed.

Sync group

A sync group defines the sync topology for a set of files. Endpoints within a sync group are kept in sync with each other. If, for example, you have two distinct sets of files that you want to manage with Azure File Sync, you would create two sync groups and add different endpoints to each sync group. A Storage Sync Service can host as many sync groups as you need.

Registered server

The registered server object represents a trust relationship between your server (or cluster) and the Storage Sync Service. You can register as many servers to a Storage Sync Service instance as you want. However, a server (or cluster) can be registered with only one Storage Sync Service at a time.

Azure File Sync agent

The Azure File Sync agent is a downloadable package that enables Windows Server to be synced with an Azure file share. The Azure File Sync agent has three main components:

FileSyncSvc.exe: The background Windows service that is responsible for monitoring changes on server endpoints, and for initiating sync sessions to Azure.

StorageSync.sys: The Azure File Sync file system filter, which is responsible for tiering files to Azure Files (when cloud tiering is enabled).

PowerShell management cmdlets: PowerShell cmdlets that you use to interact with the Microsoft.StorageSync Azure resource provider. You can find these at the following (default) locations:

Server endpoint

A server endpoint represents a specific location on a registered server, such as a folder on a server volume. Multiple server endpoints can exist on the same volume if their namespaces do not overlap (for example, F:\sync1 and F:\sync2). You can configure cloud tiering policies individually for each server endpoint.

You can create a server endpoint via a mountpoint. Note, mountpoints within the server endpoint are skipped.

You can create a server endpoint on the system volume but, there are two limitations if you do so:

Cloud tiering cannot be enabled.

Rapid namespace restore (where the system quickly brings down the entire namespace and then starts to recall content) is not performed.

Note

Only non-removable volumes are supported. Drives mapped from a remote share are not supported for a server endpoint path. In addition, a server endpoint may be located on the Windows system volume though cloud tiering is not supported on the system volume.

If you add a server location that has an existing set of files as a server endpoint to a sync group, those files are merged with any other files that are already on other endpoints in the sync group.

Cloud endpoint

A cloud endpoint is an Azure file share that is part of a sync group. The entire Azure file share syncs, and an Azure file share can be a member of only one cloud endpoint. Therefore, an Azure file share can be a member of only one sync group. If you add an Azure file share that has an existing set of files as a cloud endpoint to a sync group, the existing files are merged with any other files that are already on other endpoints in the sync group.

Important

Azure File Sync supports making changes to the Azure file share directly. However, any changes made on the Azure file share first need to be discovered by an Azure File Sync change detection job. A change detection job is initiated for a cloud endpoint only once every 24 hours. In addition, changes made to an Azure file share over the REST protocol will not update the SMB last modified time and will not be seen as a change by sync. For more information, see Azure Files frequently asked questions.

Cloud tiering

Cloud tiering is an optional feature of Azure File Sync in which frequently accessed files are cached locally on the server while all other files are tiered to Azure Files based on policy settings. For more information, see Understanding Cloud Tiering.

Azure File Sync system requirements and interoperability

This section covers Azure File Sync agent system requirements and interoperability with Windows Server features and roles and third-party solutions.

Evaluation Tool

Before deploying Azure File Sync, you should evaluate whether it is compatible with your system using the Azure File Sync evaluation tool. This tool is an AzureRM PowerShell cmdlet that checks for potential issues with your file system and dataset, such as unsupported characters or an unsupported OS version. Note that its checks cover most but not all of the features mentioned below; we recommend you read through the rest of this section carefully to ensure your deployment goes smoothly.

Download Instructions

Make sure that you have the latest version of PackageManagement and PowerShellGet installed (this allows you to install preview modules)

Future versions of Windows Server will be added as they are released. Earlier versions of Windows might be added based on user feedback.

Important

We recommend keeping all servers that you use with Azure File Sync up to date with the latest updates from Windows Update.

A server with a minimum of 2 GiB of memory.

Important

If the server is running in a virtual machine with dynamic memory enabled, the VM should be configured with a minimum 2048 MiB of memory.

A locally attached volume formatted with the NTFS file system.

File system features

Feature

Support status

Notes

Access control lists (ACLs)

Fully supported

Windows ACLs are preserved by Azure File Sync, and are enforced by Windows Server on server endpoints. Windows ACLs are not (yet) supported by Azure Files if files are accessed directly in the cloud.

Hard links

Skipped

Symbolic links

Skipped

Mount points

Partially supported

Mount points might be the root of a server endpoint, but they are skipped if they are contained in a server endpoint's namespace.

Junctions

Skipped

For example, Distributed File System DfrsrPrivate and DFSRoots folders.

Reparse points

Skipped

NTFS compression

Fully supported

Sparse files

Fully supported

Sparse files sync (are not blocked), but they sync to the cloud as a full file. If the file contents change in the cloud (or on another server), the file is no longer sparse when the change is downloaded.

Alternate Data Streams (ADS)

Preserved, but not synced

For example, classification tags created by the File Classification Infrastructure are not synced. Existing classification tags on files on each of the server endpoints are left untouched.

Note

Only NTFS volumes are supported. ReFS, FAT, FAT32, and other file systems are not supported.

Files skipped

File/folder

Note

Desktop.ini

File specific to system

ethumbs.db$

Temporary file for thumbnails

~$*.*

Office temporary file

*.tmp

Temporary file

*.laccdb

Access DB locking file

635D02A9D91C401B97884B82B3BCDAEA.*

Internal Sync file

\System Volume Information

Folder specific to volume

$RECYCLE.BIN

Folder

\SyncShareState

Folder for Sync

Failover Clustering

Windows Server Failover Clustering is supported by Azure File Sync for the "File Server for general use" deployment option. Failover Clustering is not supported on "Scale-Out File Server for application data" (SOFS) or on Clustered Shared Volumes (CSVs).

Note

The Azure File Sync agent must be installed on every node in a Failover Cluster for sync to work correctly.

Data Deduplication

For volumes that don't have cloud tiering enabled, Azure File Sync supports Windows Server Data Deduplication being enabled on the volume. Currently, we do not support interoperability between Azure File Sync with cloud tiering enabled and Data Deduplication.

Distributed File System (DFS)

DFS Namespaces (DFS-N): Azure File Sync is fully supported on DFS-N servers. You can install the Azure File Sync agent on one or more DFS-N members to sync data between the server endpoints and the cloud endpoint. For more information, see DFS Namespaces overview.

DFS Replication (DFS-R): Since DFS-R and Azure File Sync are both replication solutions, in most cases, we recommend replacing DFS-R with Azure File Sync. There are however several scenarios where you would want to use DFS-R and Azure File Sync together:

Sysprep

Using sysprep on a server which has the Azure File Sync agent installed is not supported and can lead to unexpected results. Agent installation and server registration should occur after deploying the server image and completing sysprep mini-setup.

Windows Search

If cloud tiering is enabled on a server endpoint, files that are tiered are skipped and not indexed by Windows Search. Non-tiered files are indexed properly.

Antivirus solutions

Because antivirus works by scanning files for known malicious code, an antivirus product might cause the recall of tiered files. In versions 4.0 and above of the Azure File Sync agent, tiered files have the secure Windows attribute FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS set. We recommend consulting with your software vendor to learn how to configure their solution to skip reading files with this attribute set (many do it automatically).

Microsoft's in-house antivirus solutions, Windows Defender and System Center Endpoint Protection (SCEP), both automatically skip reading files that have this attribute set. We have tested them and identified one minor issue: when you add a server to an existing sync group, files smaller than 800 bytes are recalled (downloaded) on the new server. These files will remain on the new server and will not be tiered since they do not meet the tiering size requirement (>64kb).

Backup solutions

Like antivirus solutions, backup solutions might cause the recall of tiered files. We recommend using a cloud backup solution to back up the Azure file share instead of an on-premises backup product.

If you are using an on-premises backup solution, backups should be performed on a server in the sync group which has cloud tiering disabled. When restoring files within the server endpoint location, use the file level restore option. Files restored will be synced to all endpoints in the sync group and existing files will be replaced with the version restored from backup.

Note

Application-aware, volume-level and bare-metal (BMR) restore options can cause unexpected results and are not currently supported. These restore options will be supported in a future release.

Encryption solutions

Support for encryption solutions depends on how they are implemented. Azure File Sync is known to work with:

In general, Azure File Sync should support interoperability with encryption solutions that sit below the file system, such as BitLocker, and with solutions that are implemented in the file format, such as Azure Information Protection. No special interoperability has been made for solutions that sit above the file system (like NTFS EFS).

Other Hierarchical Storage Management (HSM) solutions

No other HSM solutions should be used with Azure File Sync.

Region availability

Azure File Sync is available only in the following regions:

Region

Datacenter location

Australia East

New South Wales

Australia Southeast

Victoria

Canada Central

Toronto

Canada East

Quebec City

Central India

Pune

Central US

Iowa

East Asia

Hong Kong

East US

Virginia

East US2

Virginia

North Central US

Illinois

North Europe

Ireland

South Central US

Texas

South India

Chennai

Southeast Asia

Singapore

UK South

London

UK West

Cardiff

West Europe

Netherlands

West US

California

Azure File Sync supports syncing only with an Azure file share that's in the same region as the Storage Sync Service.

Azure disaster recovery

To protect against the loss of an Azure region, Azure File Sync integrates with the geo-redundant storage redundancy (GRS) option. GRS storage works by using asynchronous block replication between storage in the primary region, with which you normally interact, and storage in the paired secondary region. In the event of a disaster which causes an Azure region to go temporarily or permanently offline, Microsoft will fail over storage to the paired region.

To support the failover integration between geo-redundant storage and Azure File Sync, all Azure File Sync regions are paired with a secondary region that matches the secondary region used by storage. These pairs are as follows:

Primary region

Paired region

Australia East

Australia Southeast

Australia Southeast

Australia East

Canada Central

Canada East

Canada East

Canada Central

Central India

South India

Central US

East US 2

East Asia

Southeast Asia

East US

West US

East US 2

Central US

North Europe

West Europe

North Central US

South Central US

South India

Central India

Southeast Asia

East Asia

UK South

UK West

UK West

UK South

West Europe

North Europe

West US

East US

Azure File Sync agent update policy

The Azure File Sync agent is updated on a regular basis to add new functionality and to address issues. We recommend you configure Microsoft Update to get updates for the Azure File Sync agent as they're available.

Major vs. minor agent versions

Major agent versions often contain new features and have an increasing number as the first part of the version number. For example: *2.*.**

Minor agent versions are also called "patches" and are released more frequently than major versions. They often contain bug fixes and smaller improvements but no new features. For example: **.3.**

Upgrade paths

There are three approved and tested ways to install the Azure File Sync agent updates. These update paths work for both major and minor versions.

(Preferred) Configure Microsoft Update to automatically download and install agent updates. We always recommend taking every Azure File Sync update to ensure you have access to the latest fixes for the server agent. Microsoft Update makes this process seamless, by automatically downloading and installing updates for you.

Patch an existing Azure File Sync agent by using a Microsoft Update patch file, or a .msp executable. The latest Azure File Sync update package can be downloaded from the Microsoft Update Catalog. Running a .msp executable will upgrade your Azure File Sync installation with the same method used automatically by Microsoft Update in the previous upgrade path. Applying a Microsoft Update patch will perform an in-place upgrade of an Azure File Sync installation.

Download the newest Azure File Sync agent installer from the Microsoft Download Center. The installer download is a Microsoft Installer package, or a .msi executable. To upgrade an existing Azure File Sync agent installation, uninstalled the older version and then install the latest version from the downloaded installer. The server registration, sync groups, and any other settings are maintained by the Azure File Sync installer.

Agent lifecycle and change management guarantees

Azure File Sync is a cloud service, which enables continuously introduction of new features and functionality. This means that a specific Azure File Sync agent version can only be supported for a limited time. To facilitate your deployment, the following rules to guarantee you have enough time and notification to accommodate agent updates/upgrades in your change management process:

Major agent versions are supported for at least six months from the date of initial release.

We guarantee there is an overlap of at least three months between the support of major agent versions.

Warnings are issued for registered servers using a soon-to-be expired agent at least three months prior to expiration. You can check if a registered server is using an older version of the agent under the registered servers section of a Storage Sync Service.

The lifetime of a minor agent version is bound to the associated major version. For example, when agent version 3.0 is released, agent versions 2.* will all be set to expire together.

Note

Installing an agent version with an expiration warning will display a warning but succeed. Attempting to install or connect with an expired agent version is not supported and will be blocked.