At this point I’m sure you’re heard about Azure File Sync. If you have not, Azure File Sync (AFS) is a service that centralizes your file shares in Azure Files, while keeping the flexibility, performance, and compatibility of an on-premises file server. In essence, it transforms your File Server into a quick cache of your Azure file share.
It’s a great way to deal with shrinking storage space in your environment by using AFS to tier your files to the cloud and ensure you never run out of space locally.
In order for you to be able to set this up in your environment you have to meet the following prerequisites:
- Windows Server 2019 (Datacenter and Standard), Full and Core
- Windows Server 2016 (Datacenter and Standard), Full and Core
- Windows Server 2012 R2 (Datacenter and Standard), Full and Core
- A minimum of 2 GiB of memory.
- A locally attached volume formatted with the NTFS file system (Only NTFS volumes are supported. ReFS, FAT, FAT32, and other file systems are not supported.)
- Az and StorageSync PowerShell modules installed (requires .NET 4.7.2)
Create an Azure storage account, file share and Azure File Sync Service
in my case I used Azure-CLI in an azure shell to create the storage account that will host our File Share.
az storage account create --location <location> --name <account_name> --resource-group <resource_group> --sku <account_sku>
Now that the Storage account is created, to create the File Share in that storage account we need to create a connection string to the storage account where you want to create the share. To achieve that we used the following command:
conn_string=$(az storage account show-connection-string -n <account_name> -g <resource_group> --query 'connectionString' -o tsv)
Then we used that environment variable to create the share.
az storage share create --name itopsfiles --quota 2048 --connection-string $conn_string
Now that the Storage Account and the file share have been created we are ready to enabled the File Sync Service in the portal (this can also be done in Powershell).
In the Azure Portal, search for “Azure File Sync”, select it from the results and
In the “Deploy Azure File Sync” screen pick a Subscription where you want it deployed, a resource group to store it in, and the name you want to give to your AFS service.
Then click Review & Create. > Create.
Once the Azure File Sync Service has been deployed, we need to install the agents and register our Windows Server with the Storage Sync Service. Registering your Windows Server with the Storage Sync Service will setup a trust relationship between your server (or cluster) and the Storage Sync Service.
The Server registration process uses your Azure credentials to create a trust relationship between the Storage Sync Service and your Windows Server, however subsequently the server creates and uses its own identity that is valid as long as the server stays registered and the current Shared Access Signature token (Storage SAS) is valid.
The Azure credentials you use MUST have the capabilities to grant access to the registered server. If you do not have enough rights in your Azure Active Directory, you will get a notification when you try to perform the registration in the form of the following authentication prompt:
For this article I’m using a subscription where I have “global administrator” role.
In my case I used the Windows Admin Center console to register both my servers. I will walk you throught setup up TWT-FS01 my on-prem File Server. TWT-FS02 is setup the exact same way and it sits in a remote branch office.
To start, in my Windows Admin center (WAC) console, I select the server I want to manage.
The next step is to navigate to the Azure File Sync menu option. And click Setup.
the process will take you through the 3 steps:
- Deploy the Agent
- Connect to the Storage Sync Service
- Register the server
click Next to Deploy the Agent
you need to decide if you want to use Windows Update to keep the agent up to date. I recommend you do, and deploy the agent. whe it’s done downloading and installing, click next to continue.
the next section is where you need to authenticate to Azure in order to connect to the Storage Sync Service. Remember, if it says “Need Admin Approval” your Azure Account does not have the proper permissions. if you have the proper permission a dialogue box will prompt you to grant access.
Now that we are authenticated and can read the subscription info, the next step will have you pick the subscription, the resource group and the Storage Sync Service we created earlier. then click Next.
and on the last step just click register server. it will take a few minutes to complete.
Following the server registration we will create a sync group to defines the sync topology for a set of files. Endpoints (cloud or server) within a sync group are kept in sync with each other. So after we setup TWT-FS01 and TWT-FS02 has endpoints, the will be kept in sync with each other.
A server endpoint represents the path on a registered server we want synchronized. A server can have server endpoints in multiple sync groups. You can create as many sync groups as you need to appropriately describe your desired sync topology.
Note: in your Azure File Share, a special folder, comparable to the hidden “System Volume Information” folder on an NTFS volume, will be provisioned. This directory is called “.SystemShareInformation”. It holds important sync metadata that will not sync to other endpoints. Do not use or delete it!
Next we need to create a sync group, in the Azure portal, go to your Storage Sync Service, and then select + Sync group:
the Sync Group creation only required a Name, a subscription, the name of the storage account and File Share we created earlier
and once the sync group creation is complete, we are now at the point to add the server endpoints. by selecting “Add server endpoint” in the portal. this is where the tiering magic happens. while adding the server endpoint we can setup how we want the service to treat the local volumes. so for TWT-FS01 (in the registered server field) we setup the path where the local share is, and setup cloud tiering to ensure that our local drive ALWAYS has 50% free space and that it only cached the files used in the last 30 days.
At this point I can also add TWT-FS02 and use server specific tiering settings to deal with servers that may not have the same size volumes locally.
You can always go back to the Storage Sync Service and drill into your sync groups and validate the health of your sync topology.
That’s it! we now have a fuly managed topology that will ensure our local servers never run out of space and (at least on the drive being synced) and the Azure File Share is now our offsite backup. 2 birds… one stone.
Let me know if there are other scenarios you’d like us to cover.