Azure File Sync Requirements
The Server Endpoint
A server endpoint is any file server with a registered Azure File Sync agent that is a part of a sync group, that is, the file server is synchronizing files/folders to an Azure storage account through a sync service. There are a few system requirements for the server endpoint.
The operating system must be either:
- Windows Server 2012 R2 Datacenter or Standard with a Full UI (not Core)
- Windows Server 2016 Datacenter or Standard with a Full UI (not Core)
Windows Server 2012 and older are not supported and will not work. Core installations are also not supported and will not work.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Before you can successfully install & register the sync agent, you must install the latest released version of the Azure Resource Manager (AzureRM) PowerShell modules, which you can download from GitHub. Note that this installation will require a reboot if the modules have never been installed on the file server before – you will not be prompted to do this reboot.
A server endpoint can be a highly available file server that is made from a traditional active/passive cluster. The sync agent must be installed on each node of the cluster. Note that Scale-Out File Servers (shared Storage Spaces or Storage Spaces Direct) are not supported.
Some of you might consider building file servers using Sysprep. Generalizing a file server that has the sync agent installed is not supported.
Files & Folders
The folders/files that you wish to synchronize to the cloud must be on non-removable drives. The content may not be stored on another server, accessed via a share. If you synchronize files from the system/OS volume, then you will lose the following two features:
- Cloud tiering (saving space)
- Rapid namespace restore (disaster recovery)
A number of file system features are not supported by Azure File Sync – these are the sorts of things that you normally won’t see on a general file server. One interesting thing is permissions; these are synchronized by Azure File Sync and can be replicated from one server endpoint to other server endpoints through Azure. However, Azure Files cannot use these permissions to restrict access to any shares that you decide to make available to end users – watch this space.
A number of files and file types are also skipped by Azure File Sync – this includes *.tmp and other kinds of temporary files.
- Note that files must be greater than 64KiB in size to be tiered by Azure Files.
- If you enable deduplication on the file server storage then you cannot enable cloud tiering.
- Any tiered files will not be indexed by Windows Search.
On the topic of encryption:
- BitLocker is OK, as are Azure Information Protection (AIP) and AD Rights Management Services (RMS).
- Azure File Sync does not work with EFS.
If you use an alternative to BitLocker that encrypts the disk then it should probably not cause issues. If the encryption happens at the file level, like AIP/RMS, then there should be no problem. But file system encryption like EFS will not be supported.
You need to be careful here. Microsoft cannot give you a full answer to questions on third party solutions so understand what Azure File Sync (particularly tiering) does so you can ask vendors about support and implications.
If you want to run anti-virus then you need to select a product that understands the “O” (offline) attribute. Any file that is tiered by Azure File Sync will have this attribute. You do not want these files to be scanned because they will be needlessly downloaded from Azure to the file server. Microsoft has tested some solutions and documents them here.
You have a similar situation with backup. If a backup solution understands the “O” attribute then it might not cause an issue. But Microsoft does say:
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.
Their advice for backing up tiered shares is that you should back them up in Azure using the features of Azure Files and Azure Backup – supplement this with a (no) Delete lock on the storage account.
The Storage Account
The solution uses the Azure Files feature of general purpose storage accounts (v1 and v2). Each sync group (a selection of synchronized folders) will synchronize to an Azure Files share, which is known as a cloud endpoint.
At this time, a single Azure Files share is limited to 5TiB of content. That does not prevent a file server from synchronizing 8 TiB of content. You can split this into 2+ sync groups, each of which synchronizes to a different share in the same storage account – the user will see no differences or changes on the file server.
Note that snapshots (backups) of the files in the share do not consume from the 5TiB limit but the increments of the changes captured by the snapshots do contribute to the storage costs.
If you wish to have a disaster recovery solution for the cloud endpoint, then you can enable GRS replication to the paired region, at roughly double the storage cost of LRS.