Since the beginning of the Azure Era, one of the basic components of the Microsoft Cloud were Azure Storage accounts.

An Azure storage account provides a unique namespace in the cloud to store and access your data objects in Azure Storage. A storage account contains any blobs, files, queues, tables, and disks that you create under that account.

One of the biggest limitation we found during our Customer’s Cloud Journeys in One Step Beyond was that Azure Storage is not able to preserve and integrate Windows ACLs and for this reason cannot be used as a sort of File Share replacement as security cannot be preserved.

Finally, in September 2017, Microsoft released the first preview version of what we consider a game-changer on this point: Azure File Sync.


Azure File Sync (in preview but just updated to v2 in May 2018) centralizes your organization’s file shares in Azure Files, while keeping the flexibility, performance, and compatibility of an on-premises file server.

In other words, Azure File Sync transforms Windows Server into a quick cache of your Azure file share: this enables you to keep only the newest and most recently accessed files locally without sacrificing the ability to see and access the entire namespace through seamless cloud recall.

The great benefits you can have using this hybrid technology are:

  • Reduce required storage on-prem
  • Keep cold data in a secure way without using expensive storage on-prem
  • Accessing for different locations
  • Automatic Backup and Disaster recovery in case of file server failure.

How it works

Azure File Sync is a multi-master sync solution that makes easier to solve global file shares access problems introduced by having a single point of access on-premises (or in Azure) by replicating data between Azure File shares and servers anywhere in the world. it introduced the concept of the Sync Group, to manage the locations that should be kept in sync with each other.

Every Sync Group has one Cloud Endpoint, which represents an Azure File share, and one or more Server Endpoints (where a Azure File Sync Agent is installed), which represents a path on a Windows Server on-prem or in Azure IaaS that are called Registered Server. File Shares on Registered servers could be tiered using the Cloud tiering optional feature in which infrequently used or accessed files greater than 64 KiB in size can be tiered to Azure Files. When a file is tiered, the Azure File Sync file system filter replaces the file locally with a pointer, or reparse point. The reparse point represents a URL to the file in Azure Files. A tiered file has the “offline” attribute set in NTFS so third-party applications can identify tiered files.


Azure File Sync can be useful in different scenarios. Some examples are the following:

Simple Sync

this is the simplest scenario where all the data in the file server will be copied to the Azure Storage and remove infrequently accessed data from the local server. this permits to reduce the storage occupation on-prem. This also helps in case of a local server failure: in this case a new server can be implemented and connected to the same Sync Group so that all the name space will be downloaded. Over the time the most frequently accessed files will be synced back to the new Registered Server.

Multi-Master Sync

Azure Sync can synchronize files from multiple file servers in different locations. This will let you to use file servers in different geographical locations while Azure Files acts as the central location. When a user trying to access a file that is already opened in another location, user will be notified and can select an option to work later or parallel.


In case you have to move a huge amount of data you should consider also Azure Data Box service. This could be used to move hundreds of terabytes of data into Azure with high speed, by using secure transfer appliances. Microsoft accelerate the movement of your data by shipping you a proprietary, secure, and tamper-resistant transfer appliance, and by handling the end-to-end logistics.


Azure File Sync Agent can only be installed on Windows Server 2012 R2 or Windows Server 2016 (next version of Windows Server will be supported as well) and also:

  • Windows Management Framework 5.1  – this is included by default on Windows Server 2016 but needs to be installed on Windows Server 2012 R2. Link here.
  • Azure Powershell –
  • Registered Servers should be able to connect with the Cloud Endpoint over HTTPS (port 443) – Data are always encrypted in transit and at rest in Azure.


There are also some limitations to keep in consideration:

  • Max size of the share is currently 5TB, Max file size is 1 TB and Max IOPS per share is 1000. (Microsoft is planning to increase the limit of the share to 100TB in the GA version)
  • Only non-removable volumes are supported. Drives mapped from a remote share are not supported for a server endpoint path.
  • Only NTFS volumes are supported. ReFS, FAT and FAT32 are not supported.
  • Cloud tiering is not supported for server endpoints on the Windows system volumes.
  • Support for encryption solutions depends on how they are implemented. Azure File Sync is known to work with BitLocker or Azure Information Protection and work with NTFS EFS.
  • Antivirus and Backup Solutions that are not considering “offline” attribute for files are not supported with Cloud tiering functionality enabled.
  • Even if the Azure File Share will be accessible from the Azure Portal directly and from Azure Services like WebApp and Azure Functions, Windows ACLs are not preserved. it means that your application will not be able to apply security trimmed access to the files.


Now that we have all the information, let’s implementing it in the Part 2.

Comments are closed.