Deployment of Azure File Sync

Return to AZ-104 Tutorial

Here, we are going to discuss the deployment of Azure file Sync. This page offers in-depth knowledge and understanding regarding the same. So, let’s begin.

To begin with, you need to understand the use of Azure File Sync to centralize your company’s file shares in Azure Files. Also, while maintaining the flexibility, performance, and compatibility of an on-premises file server. Not to mention, Azure File Sync modifies Windows Server into a smart cache of your Azure file share. With this, you’ll able to use any protocol that’s accessible on Windows Server. Lastly, you can own as many caches as you need across the globe.

Prerequisites

First and foremost, an azure file share in the same domain that you require to deploy Azure File Sync.
Secondly, at least one sustained instance of Windows Server or Windows Server cluster to sync with Azure File Sync.

Preparing Windows Server to use with Azure File Sync

For each server, this requires to use with Azure File Sync. Further, including each server node in a Failover Cluster, disable Internet Explorer Enhanced Security Configuration. However, this is only required for initial server registration. Also, you can re-enable it after the server has been listed.

Deploying the Storage Sync Service

The deployment of Azure File Sync commences with placing a Storage Sync Service resource into a resource group of selected subscription. We suggest provisioning as few of these as needed. Also, keep in mind that servers from various storage sync services cannot sync with each other.

Installing the Azure File Sync agent

The Azure File Sync agent is a downloadable pack that allows Windows Server to be synced with an Azure file share.

Registering Windows Server with Storage Sync Service

Next, registering your Windows Server with a Storage Sync Service builds a trust relationship between your server and the Storage Sync Service. Also, remember that a server can only be registered to one Storage Sync Service.

Furthermore, the head or the administrator registering the server must be a member of the management roles Owner or Contributor for the given Storage Sync Service.

Creating a sync group and a cloud endpoint

A sync group describes the sync topology for a set of files. So, endpoints within a sync group are held in sync with each other.

To begin with, a sync group must contain one cloud endpoint, which outlines a file share and one or more server endpoints.
Secondly, a server endpoint denotes a path on a registered server. A server can have server endpoints in many sync groups.
Subsequently, you can create as many sync groups as you want to appropriately define your desired sync topology.

Creating a server endpoint

A server endpoint outlines a specific location on a registered server, such as a folder on a server volume. Also, remember that server endpoint should be a path on a registered server.

Configure firewall and virtual network settings

In case you wish to configure the Azure File sync to work with firewall and virtual network settings, do the following:

First of all, from the Azure portal, operate to the storage account you want to secure.
Secondly, select the Firewalls and virtual networks button on the left menu.
Subsequently, select Selected networks under Allow access from.
Next, make sure the servers IP or virtual network is registered under the appropriate section.
Moving on, make sure Allow trusted Microsoft services to access this storage account is checked.
Lastly, select Save to save your settings.

Onboarding with Azure File Sync

Following are the recommended steps to onboard on Azure File Sync for the first with zero downtime. Additionally, preserving full file fidelity and access control list (ACL) are as follows:

Begin by deploying a Storage Sync Service.
Then, create a sync group.
Next, install Azure File Sync agent on the server with the full data set.
Now, register that server and create a server endpoint on the share.
Now, let sync do the full upload to the Azure file share (cloud endpoint).
After the completion of initial upload, install File Sync agent on each of the remaining servers.
Now, create new file shares on each of the remaining servers.
Also, create server endpoints on new file shares with cloud tiering policy, if desired. (This step requires additional storage to be available for the initial setup.)
For now, let Azure File Sync agent do a rapid restore of the full namespace without the actual data transfer. After the full namespace sync, sync engine will fill the local disk space based on the cloud tiering policy for the server endpoint.
Further, ensure sync completes and test your topology as desired.
Next, redirect users and applications to this new share.
Moreover, you can optionally delete any duplicate shares on the servers.

Self-service restore through Previous Versions and VSS

Earlier Versions is a Windows feature that allows utilizing server-side VSS snapshots of a volume to confer restorable versions of a file to an SMB client. Further, this enables a powerful scenario, usually attributed to as self-service restore, directly for information workers instead of depending on the restore from an IT admin.

VSS snapshots and Previous Versions work freely of Azure File Sync.

Not to mention, VSS snapshots are taken of an entire volume. By default, up to 64 snapshots can endure for a given volume. The above PowerShell cmdlet does two things:

Firstly, it configures Azure File Syncs cloud tiering on the specified volume to be agreeable with prior versions and guarantees that a file can be restored from a previous version, even if it was tiered to the cloud on the server.
Secondly, it permits the default VSS schedule. You can then select to modify it later.

Proactively recalling new and changed files from an Azure file share

With the help of agent version 11, a distinct mode becomes available on a server endpoint. Further, this mode provides globally distributed companies to have the server cache in a remote region pre-populated even before local users are accessing any files.

Migrating a DFS Replication (DFS-R) deployment to Azure File Sync

In order to migrate a DFS-R deployment to Azure File Sync:

Begin with, creating a sync group to represent the DFS-R topology you are replacing.
Then, start on the server that has the full set of data in your DFS-R topology to migrate. Install Azure File Sync on that server.
Next, register that server and create a server endpoint for the first server to be migrated. Do not enable cloud tiering.
Also, let all of the data syncs to your Azure file share (cloud endpoint).
Further, install and register the File Sync agent on each of the remaining DFS-R servers.
Now, disable DFS-R.
Moving on, create a server endpoint on each of the DFS-R servers. Do not enable cloud tiering.
Subsequently, ensure sync completes and test your topology as desired.
Now, retire DFS-R.
Lastly, cloud tiering may now be permitted on any server endpoint as aspired.