Create Azure File Sync Service

The backbone of Azure File Sync is the Storage Sync Service. The storage sync service is the service that runs in Azure that manages Azure. You should deploy as few storage sync services as necessary since a Windows Server file server can only be registered with one sync service and file servers that are connected to different storage sync services are unable to synchronize with each other.

You should plan to deploy the storage sync service and the Azure File Share endpoints used by each sync group in the same Azure region and resource group. To deploy a storage sync service, perform the following steps:

1. In the Azure portal select Create a resource and then search for Azure File Sync. In the list of results select Azure File Sync and then select Create.

2. On the Deploy Storage Sync page, provide the following:

   • Name A name for the storage sync service. This name only needs to be unique on a per-region basis, but it’s a good idea to have it unique for your organization.

   • Subscription The name of the subscription that will host the storage sync service. This will be the subscription where costs accrue for the service.

   • Resource Group The resource group that will host the storage sync service. You should also plan to host the storage account used with the sync service in the same resource group.

   • Location The location where you will deploy Azure File Sync. This location should be geographically proximate to where your server endpoints are. Remember that clients will be accessing files through the file server endpoints close to them. Bandwidth and latency between the server endpoint and the file share is generally only an issue when there is a substantive delay between a file that is tiered being requested and it synchronizing back to the endpoint.

Create sync groups

A sync group allows you to replicate a specific folder and file structure across server and Azure File Share endpoints. Each sync group has a single Azure file share endpoint but can have multiple server endpoints. An Azure file storage sync service can host multiple sync groups, and a Windows Server endpoint can participate in multiple sync groups as long as those sync groups belong to the same storage sync service. To create a sync group, you need to specify a sync group name, which is separate from the sync service name; the name of the storage account that will be used; and the name of the Azure File Share that will be used. You should create the storage account and Azure File Share before creating the sync group.

Create cloud endpoints

The back end of Azure File Sync is an Azure File Share, also termed a cloud endpoint. This is a cloud file share that will store any file that is written to an Azure File Sync endpoint. The back-end Azure File Share stores the entire contents of what appears to be on the file share that is the front end for Azure File Sync. Creating a file share involves creating a storage account and then creating the file share within the storage account.

To create an Azure File Share, consider the following:

• Performance requirements In most cases, the only computers interacting with the file share in an Azure File Sync deployment are the server endpoints. This means that you are unlikely to require the higher I/O performance capabilities of a premium file share that is hosted on solid-state disk (SSD)-based hardware.

• Redundancy requirements Standard file shares can use locally redundant, zone-redundant, or geo-redundant storage. Large file shares of the type you are likely to use with Azure File Sync are only available with locally redundant and zone-redundant storage.

• File share size Local and zone redundant storage accounts allow for file shares that span up to 100 TiB. The file share size will need to be able to hold all the tiered data from your file share endpoints and should be substantially larger than the storage on any on-premises server. The amount of storage you allocate to a file share will depend on the amount of data you need to tier and how much storing that data costs. Storage and transfer costs are billed separately, and even if you create a file share that is larger than you need, your organization will only be billed by the storage capacity actually used.

You can configure Azure Backup to back up this file share endpoint. The advantage of this is that in the event of data corruption or deletion, you can just recover data to the Azure File Share in the cloud from the Azure console, and it will replicate down to all the Azure File Sync endpoints.

Register servers

The Azure File Sync agent allows you to register a server with a storage sync service. To register a server, download and install the Azure File Sync agent from the Microsoft Download Center. As part of the installation process, you can configure the agent to be automatically updated through Microsoft Update. When the installation completes, you perform registration with a storage sync service. To register a server, you need local Administrator privileges on the server you want to register and you need an Azure account that is a member of the Owner or Contributor management role for the storage sync service in Azure. You can delegate these roles to an Azure AD account under Access Control (IAM) on the Storage Sync Service properties page in the Azure console. During the registration process, you must specify the Azure subscription, resource group, and storage sync service that will be used with the server endpoint.

Registration will use Azure credentials to create a trust relationship between the storage sync service and the Windows Server computer. The Windows Server instance will then create an identity separate from the user account used to create the registration that will function as long as the server remains registered and the current share Access Signature token associated with the storage account remains valid.

Create server endpoints

An Azure File Sync endpoint consists of a server and a path that are enrolled in an Azure File Sync service. A Windows Server can host multiple endpoints, each of which has a different path, as long as those endpoints are in different sync groups associated with the same sync service. An Azure File Sync endpoint functions as the folder structure that underlies a normal file share. Administrators create a traditional shared folder and point it at the path that the Azure File Sync endpoint replicates to. You can also point a Distributed File System (DFS) namespace at this path, replacing Distributed File System Replication (DFSR) with Azure File Sync replication while still keeping the navigational advantages of the DFS way of identifying shared folders.

Create a server endpoint by adding the server that you registered with the storage sync service and specifying the local path to the files that you want to replicate using Azure File Sync. When creating the server endpoint, you also specify the cloud tiering settings in terms of how much free space should always be available on the local volume that hosts the files and how many days after a file was last accessed should pass before the file is tiered. After the endpoint is created, any files in the path specified will be replicated up to the Azure File Share that functions as the cloud endpoint. If you create an endpoint that points to the system volume of the registered server, you cannot enable cloud tiering on that endpoint.

File shares that serve as front ends for Azure File Sync endpoints should have the same share permissions. If you are using Azure File Sync with a failover cluster, ensure that the agent is installed on each node in the cluster and that each node in the cluster is registered to the same storage sync service.

Configure cloud tiering

Azure File Sync uses a process called cloud tiering to ensure that there is capacity on the volume that hosts the share. Cloud tiering means that you don’t need to worry about constantly freeing up space for new files. You can configure Azure File Sync on a per-file share basis to tier files based on when the file was last accessed, how much free space there is on the volume that hosts the share, or both. For example, you might configure Azure File Sync so that any file that hasn’t been accessed in 14 days on a particular share is automatically tiered to Azure. You could also specify that the least recently accessed files be automatically tiered to Azure in the event that the volume has only 30 percent free space remaining. If you have both a policy to tier files that exceed a certain age and a requirement that a certain amount of space still be available on the volume, Azure File Sync will ensure that requirement for free space is met by tiering least recently accessed files until the free space requirement is met.

From the users’ perspective, a tiered file still appears as though it’s on the file server that they are accessing. If users try to open the file, it syncs down from the back-end Azure File Share to the Azure File Sync file share endpoint and then opens normally. Cloud tiering can be configured on a per-server endpoint basis in the Azure console.

Monitor File Sync

You can monitor Azure File Sync using Azure Monitor, the Storage Sync Service, and Windows Server. Azure Monitor provides the following data:

• Bytes synced

• Cloud tiering cache hit rate

• Cloud tiering recall size

• Cloud tiering recall size by application

• Cloud tiering recall success rate

• Cloud tiering recall throughput

• Files not syncing

• Files synced

• Server cache size

• Server online status

• Sync session results

The Storage Sync Service in the Azure portal provides you with the following data:

• Registered server health

• Server endpoint health

  • Files not syncing

  • Sync activity

  • Cloud tiering efficiency

  • Files not tiering

  • Recall errors

• Metrics

You can also view the Telemetry event log in Event Viewer on a server endpoint under Applications and ServicesMicrosoftFileSyncAgent to view sync health information. Azure File Sync performance counters are available in Performance Monitor that allow you to view bandwidth utilization and performance of the Azure File Sync agent.

Migrate DFS to Azure File Sync

When you migrate DFS to Azure File Sync, you replace the older DFS file replication technology with Azure File Sync. You’ll learn about both these technologies in more detail later in the chapter. The technology that is relevant to Azure File Sync is the namespace technology.

When you use DFS Namespaces, you can configure a single UNC path to map to multiple SMB shares. For example \adatumshareshovercraft can map to \Adelaide-fs01hovercraft as well as \Melbourne-fs01hovercraft. When a client attempts to access the DFS UNC path, they are directed by DFS to the closest SMB endpoint. When used with DFS replication, it meant that a user attempting to access a share would be connected to the closest DFS endpoint. When you use DFS Namespaces with Azure File Sync, a client that navigates to the DFS address will be directed to the closest Azure File Sync endpoint.

To migrate from DFS replication to Azure File Sync replication, perform the following steps:

1. Create a new sync group that will be used as the substitute for the DFS replication topology you are replacing.

2. Start on the server that has the full set of data in your DFS replication topology to migrate. Install Azure File Sync on that server.

3. Register that server and create a server endpoint for the first server to be migrated. Do not enable cloud tiering.

4. Let all the data on that server sync to your Azure File Share cloud endpoint.

5. Install and register the Azure File Sync agent on each of the remaining servers that host DFS replicas.

6. Disable DFS replication on each server.

7. Create an Azure File Sync server endpoint on each of the previous servers that participated in DFS replication. Do not enable cloud tiering.

8. Ensure that the sync process completes and test your topology.

9. Retire DFS-R.

10. Enable cloud tiering on any server endpoint as desired.

Configure Windows Server File Share access

The basic idea with shared folders is that you create a folder and assign permissions to a group, such as a department within your organization, and the people in that group use that space on the file server to store files to be shared with the group.

For example, you create a shared folder named Managers on a file server named FS1. Next, you set share permissions on the shared folder and file system permissions on the files and folders within the shared folder. Permissions allow you to control who can access the shared folder and what users can do with that access. For example, permissions determine whether they are limited to just read-only access or whether they can create and edit new and existing files.

When you set share permissions and file system permissions for a shared folder, the most restrictive permissions apply. For example, if you configure the share permission so that the Everyone group has Full Control and then configure the file permission so that the Domain Users group has Read Access, a user who is a member of the Domain Users group accessing the file over the network has Read Access.

Things get a little more complicated when a user is a member of multiple groups; in this case, the most cumulative permission applies. For example, in a file where the Domain Users group has Read Access, but the Managers group has Full Control, a user who is a member of both Domain Users and Managers who accesses the file over the network has the Full Control permission. This is great for a certification exam question, but it can be needlessly complex when you’re trying to untangle permissions to resolve a service desk ticket.

You can create shared folders in a variety of ways. The way that many administrators do it, often out of habit, is by using the built-in functionality of File Explorer. If you are using File Explorer to share folders, you have two general options when it comes to permissions:

• Simple Share Permissions. When you use the Simple Share Permissions option, you specify whether a user or group account has Read or Read/Write permissions to a shared folder. When you use Simple Share Permissions, both the share permissions and the file and folder level permissions are set at the same time. It is important to note that any files and folders in the shared folder path have their permissions reset to match those configured through the File Sharing dialog box. This, however, doesn’t happen with other forms of share permission configurations.

• Advanced Share Permissions. Advanced Share Permissions are what administrators who have been managing Windows file servers since the days of Windows NT 4 are likely to be more familiar with. With Advanced Permissions, you configure share permissions separately from file system permissions. You configure Advanced Share Permissions through the Advanced Sharing button on the Sharing tab of a folder’s Properties dialog box. When you configure Advanced Sharing Permissions, permissions are only set on the share and are not reset on the files and folders within the share. If you are using Advanced Sharing Permissions, you set the file system permissions separately.

You can manage shares centrally through the Shares area of the Server Manager console. An advantage of the Server Manager console is that you can use it to connect to manage shares on remote servers, including servers running the Server Core installation option. When you edit the properties of a share through Server Manager, you can also edit share permissions. This functions in the same way as editing Advanced Share Permissions through File Explorer in that it won’t reset the permissions on the file system itself; permissions are only reset on the share.

You can also use the Server Manager’s share properties interface when File Server Resource Manager is installed to edit the following settings:

• Enable Access-Based Enumeration. Enabled by default, this setting ensures that users can only see files and folders to which they have access.

• Allow Caching of Share. Allows files to be used offline. An additional setting, Enable BranchCache on the file share, allows use of BranchCache if the appropriate group policies are applied. You’ll learn more about BranchCache later in this chapter. You can configure this option when the Settings tab is selected.

• Encrypt Data Access. When you enable this option, traffic to and from the shared folder is encrypted if the client supports SMB 3.0 (Windows 8 and later). You can configure this option when the Settings tab is selected.

• Folder Owner Email. Setting the folder owner’s email addresses can be useful when resolving access-denied assistance requests. You can configure this when the Permission tab is selected.

• Folder Usage. Folder-usage properties allow you to apply metadata to the folder that specifies the nature of the files stored there. You can choose between User Files, Group Files, Application Files, and Backup and Archival Files. You can use folder usage properties with data classification rules.

Windows Admin Center (WAC) also provides basic file share configuration functionality, though this is not currently as sophisticated as what can be accomplished through Server Manager or File Explorer.

Configure file screens

File screens allow you to block users from writing files to file shares based on file name extension. For example, you can use a file screen to stop people from storing video or audio files on file shares. File screens are implemented based on file name. Usually, this just means file screens are implemented by file extension, but you can configure file screens based on a pattern match of any part of a file name. You implement file screens using file groups and file screen templates.

A file screen doesn’t block files that are already there; file screens just stop new files from being written to the share. File screens also only work based on file name. If you have users who are especially cunning, they might figure out that it’s possible to get around a file screen by renaming files, so they don’t get blocked by the screen.

Configure File Server Resource Manager quotas

Quotas are important. If you don’t use them, file shares tend to end up consuming all available storage unless you have a solution such as Azure File Sync deployed. Some users dump as much as possible onto a file share unless quotas are in place and unless you are monitoring storage; the first you’ll hear about it is when the service desk gets calls about people being unable to add new files to the file share.

NTFS has had rudimentary quota functionality since the Windows NT days. The reason that most Windows Server administrators don’t bother with quota functionality is that it applies at the volume level and can’t be applied to individual user accounts. Needless to say, if you have 500 users for whom you want to configure quotas, you don’t want to have to individually configure a quota for each one. Even with command-line utilities, you still need to create an entry for each user.

File Server Resource Manager (FSRM) provides far more substantial quota functionality that makes quotas more practical to implement as a way of managing storage utilization on Windows Server file servers. Quotas in FSRM can be applied on a per-folder basis and are not cumulative across a volume. You can also configure quotas in FSRM so that users are sent warning emails if they exceed a specific quota threshold but before they are blocked from writing files to the file server. You manage quotas using FSRM by creating a quota template and then applying that quota template to a path.

Creating a quota template involves setting a limit, specifying a quota type, and then configuring notification thresholds. You can choose between the following quota types:

• Hard Quota. Do Not Allow Users To Exceed Limit A hard quota blocks users from writing data to the file share after the quota value is exceeded.

• Soft Quota. Allow Users To Exceed Limit (Use For Monitoring) A soft quota allows you to monitor when users exceed a specific storage utilization value, but it doesn’t block users from writing data to the file share after the quota value is exceeded.

Notification thresholds allow you to configure actions to be taken after a certain percentage of the assigned quotas are reached. You can configure notifications via email, get an item written to an event log, run a command, or have a report generated.

After you’ve created the quota template, you can apply it to a folder. To do this, select the Quotas node under Quota Management, and from the Action menu, select Create Quota. In the Create Quota dialog box, select the path to which the quota applies and the quota template you want to apply. You then choose between applying the quota to the whole path or setting up an auto-apply template. Auto-apply templates allow separate quotas to be applied to any new and existing quota path subfolders. For example, if you applied a quota to the C:Example path using the 2 GB template, the quota would apply cumulatively for all folders in that path. If you chose an auto-apply template, a separate 2 GB quota would be configured for each new and existing folder under C:Example.

Use additional FSRM functionality

File Server Resource Manager includes advanced functionality that you can use to manage file servers in on-premises and hybrid environments.

Configure BranchCache

BranchCache speeds up access to files stored on shared folders that are accessed across medium-to high-latency WAN links. For example, suppose several users in a company’s Auckland, New Zealand branch office need to regularly access several files stored on a file server in the Sydney, Australia head office. The connection between the Auckland and Sydney office is low bandwidth and high latency. The files are also fairly large and need to be stored on the Sydney file server. Additionally, the Auckland branch office is too small for a Distributed File System (DFS) replica to make sense. In a scenario such as this, you would implement BranchCache.

BranchCache creates a locally cached copy of files from remote file servers that can be accessed by other computers on the local network, assuming the file hasn’t been updated at the source. In the example scenario, after one person in the Auckland office accesses the file, the next person to access the same file in the Auckland office accesses a copy that is cached locally, rather than retrieving it from the Sydney file server. The BranchCache process performs a check to verify that the cached version is up to date. If it isn’t, the updated file is retrieved and stored in the Auckland network’s BranchCache.

You add BranchCache to a file server by using the following PowerShell command:

Click here to view code image

Install-WindowsFeature FS-BranchCache

After installing BranchCache, you need to configure Group Policies that apply to file servers in your organization that allow them to support BranchCache. To do this, you need to configure the Hash Publication for BranchCache policy, located in the Computer ConfigurationPoliciesAdministrative TemplatesNetworkLanman Server node.

You have three options when configuring this policy:

• Allow Hash Publication Only For Shared Folders On Which BranchCache is enabled This option allows you to selectively enable BranchCache.

• Disallow Hash Publication On All Shared Folders Use this option when you want to disable BranchCache.

• Allow Hash Publication For All Shared Folders Use this option if you want to enable BranchCache on all shared folders.

Generally, there’s rarely a great reason not to enable BranchCache on all shared folders, but should you want to be selective, you do have that option. If you choose to be selective and only enable BranchCache on some shares, you need to edit the properties of the share and enable BranchCache. You do so by selecting Caching on the Advanced Sharing page and then using the Offline Settings options.

After you’ve configured your file server to support BranchCache, you need to configure client computers to support BranchCache. You do so by configuring Group Policy in the Computer ConfigurationPoliciesAdministrative TemplatesNetworkBranchCache node of a GPO. Which policies you configure depends on how you want BranchCache to work at each branch office. You can choose between the following options:

• Distributed Cache Mode When client computers are configured for Distributed Cache mode, each Windows 7 or later computer hosts part of the cache.

• Hosted Cache Mode When you configure Hosted Cache mode, a server at the branch office hosts the cache in its entirety. Any server running Windows Server 2008 R2 or later can function as a hosted cache mode server.

To configure a branch office server to function as a hosted cache mode server, run the following PowerShell commands:

Click here to view code image

Install-WindowsFeature BranchCache
Start-Service BranchCache
Enable-BCHostedServer

Implement and configure Distributed File System

Distributed File System (DFS) has two advantages over a traditional file share. The first is that DFS automatically replicates to create copies of the file share and its content on one or more other servers. The second is that clients connect to a single UNC address, with the client directed to the closest server and redirected to the next closest server in the event that a server hosting a DFS replica fails. Azure File Sync provides most of the first functionality but does not provide the second functionality.

Using DFS, you can push a single shared folder structure out across an organization that has multiple branch offices. Changes made to files on one file share replica propagate across to the other file share replicas, with a robust and built-in conflict-management system present to ensure that problems do not occur when users are editing the same file at the same time.

\FS-1Engineering
\FS-2Accounting
\FS-3Documents

\Contoso.comEngineering
\Contoso.comAccounting
\Contoso.comDocuments

Install-WindowsFeature FS-DFS-Replication

Configure disks and volumes

In Windows Server, a disk is a physical device, which can be traditional magnetic storage, solid-state, or persistent memory device (also termed storage class memory). There are two types of disks available to Windows Server: basic disks and dynamic disks.

Storage pools

A storage pool is a collection of storage devices, usually disks, but can also include items such as virtual hard disks, from which you can create one or more storage spaces. A storage space is a special type of virtual disk that has the following features:

• Resilient storage Configure to use disk mirroring or parity in the structure of the underlying storage (if available). We discuss resilience in a moment.

• Tiering Configure to leverage a combination of SSD and HDD disks to achieve maximum performance. Tiering is also discussed later in this chapter.

• Continuous availability Storage spaces integrate with failover clustering, and you can cluster pools across separate nodes within a single failover cluster.

• Write-back cache If a storage space includes SSDs, a write-back cache can be configured in the pool to buffer small random writes. These random writes are then later offloaded to SSDs or HDDs that make up the virtual disk in the pool.

• Multitenancy You can configure access control lists on each storage pool. This allows you to configure isolation in multitenant scenarios.

Storage space resiliency

When creating a virtual disk on a storage pool that has enough disks, you can choose among several storage layouts. These layout options provide the following benefits:

• Mirror Multiple copies of data are written across separate disks in the pool. This protects the virtual disk from failure of the physical disks that constitute the storage pool. Mirroring can be used with storage tiering. Depending on the number of disks in the pool, storage spaces provide two-way or three-way mirroring. Two-way mirroring writes two copies of data, and three-way mirroring writes three copies of data. Three-way mirroring provides better redundancy, but it also consumes more disk space.

• Parity Parity data is stored on disks in the array that are separate from where data is stored. Parity provides greater capacity than using the Mirror option, but it has the drawback of slower write performance. Windows Server provides two types of parity: Single Parity and Dual Parity. Single Parity provides protection against one failure at a time. Dual Parity provides protection against two failures at a time. You need to have a minimum of three disks for Single Parity and a minimum of seven disks for Dual Parity. You get the option to select between Single Parity and Dual Parity when configuring storage layout when there are more than seven disks.

• Simple This option provides no resiliency for the storage, which means that if one of the disks in the storage pool fails, the data on any virtual hard disks built from that pool will also be lost.

If you configure disks in the storage pool that use the Hot Spare option, storage spaces will be able to automatically repair virtual disks that use the Mirror or Parity resiliency options. It’s also possible for automatic repairs to occur if spare unallocated capacity exists within the pool.

Storage space tiering

Storage space tiering allows you to create a special type of virtual disk from a pool of storage that is a combination of SSD and traditional HDD disks. Storage tiering provides the virtual disk with performance similar to that of an array built out of SSD disks, but without the cost of building a large capacity array comprised of SSD disks. It accomplishes this by moving frequently accessed files to faster physical disks within the pool, thus moving less frequently accessed files to slower storage media.

You can only configure storage tiers when creating a virtual disk if there is a mixture of physical disks with the HDD and the SSD disk type in the pool upon which you want to create the disk. Once the disk is created, you cannot undo storage tiering from a virtual disk. You configure storage tiering for a virtual disk by selecting the Create Storage Tiers On This Virtual Disk option during virtual disk creation.

One challenge when configuring storage tiering is ensuring that you have media marked as SSD and HDD in the pool. While media will usually be recognized correctly, in some cases you must specify that a disk is of the SSD type, which allows storage tiering to be configured.

You can specify the disk media type using the following PowerShell procedure:

1. First determine the storage using the Get-StoragePool cmdlet.

2. To view whether physical disks are configured as SSD or HDD, use the Get-StoragePool cmdlet and then pipe that cmdlet to the Get-PhysicalDisk cmdlet. For example, to view the identity and media type of physical disks in the storage pool named Example-Pool, issue the command:

   Click here to view code image

   Get-StoragePool -FriendlyName ExamplePool | Get-PhysicalDisk | Select UniqueID,
   MediaType, Usage

3. Once you have determined the UniqueIDs of the disks that you want to configure as the SSD type, you can configure a disk to have the SSD type by using the Set-PhysicalDisk cmdlet with the UniqueID parameter and the MediaType parameter set to SSD. Similarly, you can change the type back to HDD by setting the MediaType parameter to HDD.

Thin provisioning and trim

Thin provisioning allows you to create virtual disks where you specify a total size for the disk, but only the space that is actually used will be allocated. For example, with thin provisioning, you might create a virtual hard disk that can grow to 500 GB in size but is only currently 10 GB in size because only 10 GB of data is currently stored on the volumes hosted on the disk.

You can view the amount of space that has been allocated to a thin-provisioned virtual disk, and you can see the total capacity in the Virtual Disks area when the Storage Pools node is selected in the Server Manager console or in Windows Admin Center. When you create a virtual disk, the maximum disk size available is determined by the amount of free space on the physical disks that make up the storage pool, rather than the maximum capacity of the existing thin-provisioned disks. For example, if you have a storage pool with two 10 TB physical disks, you can create more than two thin-provisioned disks that have a maximum size of 10 TB. You can create thin-provisioned disks 10 TB in size as long as the actual allocated space on the storage pool doesn’t exceed 10 out of the 20 available. It is possible to create thin-provisioned disks in such a way that the total thin-provisioned disk capacity exceeds the storage capacity of the underlying storage pool. If you do overallocate space, you’ll need to monitor how much of the underlying storage pool capacity is consumed and add disks to the storage pool because that capacity is exhausted.

Trim is an automatic process that reclaims space when data is deleted from thin-provisioned disks. For example, if you have a 10 TB thin-provisioned virtual disk that stores 8 TB of data, 8 TB will be allocated from the storage pool that hosts that virtual disk. If you delete 2 TB of data from that thin-provisioned virtual disk, Trim ensures that the storage pool that hosts that virtual disk will be able to reclaim that unused space. The 10 TB thin-provisioned virtual disk will appear to be 10 TB in size, but after the trim process is complete, it will only consume 6 TB of space on the underlying storage pool. Trim is enabled by default.

Test-Cluster -Name TestS2DCluster -node S2DN1,S2DN2,S2DN3 -Include "Storage Spaces
Direct", "Inventory", "Network", "System Configuration"

Supported configurations

Storage Replica is supported in the following configurations:

• Server-to-server In this configuration, Storage Replica supports both synchronous and asynchronous replication between two standalone services. Local drives, storage spaces with shared SAS storage, SAN, and iSCSI-attached LUNs can be replicated. You can manage this configuration either using Server Manager or PowerShell. Failover can only be performed manually.

• Cluster-to-cluster In this configuration, replication occurs between two separate clusters. The first cluster might use Storage Spaces Direct, storage spaces with shared SAS storage, SAN, and iSCSI-attached LUNs. You manage this configuration using PowerShell and Azure Site Recovery. Failover must be performed manually.

• Stretch cluster A single cluster where nodes are located in geographically disparate sites. Some nodes share one set of asymmetric storage and other nodes share another set of asymmetric storage. Storage is replicated either synchronously or asynchronously, depending on bandwidth considerations. This scenario supports storage spaces with shared SAS storage, SAN, and iSCSI-attached LUNs. You manage this configuration using PowerShell and the Failover Cluster Manager GUI tool. This scenario allows for automated failover.

The following configurations are not supported on Windows Server, though they may be supported at some point in the future:

• Storage Replica only supports one-to-one replication in Windows Server. You cannot configure Storage Replica to support one-to-many replication or transitive replication. Transitive replication is where there is a replica of the replica server.

• Storage Replica on Windows Server does not support bringing a replicated volume online for read-only access in Windows Server 2016. In Windows Server 2019 and Windows Server 2022, you can perform a test failover and temporarily mount a snapshot of the replicated storage on an unused NTFS or ReFS formatted volume.

• Deploying scale-out file servers on stretch clusters participating in Storage Replica is not a supported configuration.

• Deploying Storage Spaces Direct in a stretch cluster with Storage Replica is not supported.

Storage Replica requirements

Ensure that each server meets the following requirements:

• The servers have two volumes, one volume hosting the data that you want to replicate, the other hosting the replication logs.

• Ensure that both log and data disks are formatted as GPT and not MBR.

• Data volume on the source and destination servers must be the same size and use the same sector sizes.

• Log volume on the source and destination volumes should be the same size and use the same sector sizes. The log volume should be a minimum of 9 GB in size.

• Ensure that the data volume does not contain the system volume, page file, or dump files.

Use the Test-SRTopology cmdlet to verify that all Storage Replica requirements have been met. To do this, perform the following steps:

1. Create a temp directory on the source server that will store the Storage Replica Topology Report.

2. Make a note of the drive letters of the source storage and log volumes and destination storage and log volumes.

When the test completes, view the TestSrTopologyReport.html file to verify that your configuration meets Storage Replica requirements. Once you have verified that the configuration does meet requirements, you can use the New-SRPartnerShip cmdlet to create a Storage Replica partnership.

You can check the status of Storage Replica replication by running the Get-SRPartnership and Get-SRGroup cmdlets. Once Storage Replica is active, you won’t be able to access the replica storage device on the destination computer unless you reverse replication or remove replication. When you run this command, you will receive a warning that data loss may occur, and you will be asked whether you want to complete the operation.

By default, all replication when Storage Replica is configured is synchronous. You can switch between synchronous and asynchronous replication by using the Set-SRPartnership cmdlet with the ReplicationMode parameter.

Storage Replica uses the following ports:

• 445 Used for SMB, which is the replication transport protocol.

• 5985 Used for WSManHTTP, which is the management protocol for WMI/CIM/PowerShell.

• 5445 Used for SMB with iWARP. This port is only required if using iWARP RDMA networking.

Configure filesystems

Windows Server supports the following filesystems:

• NTFS

• ReFS

• FAT and FAT32

New-Volume -FriendlyName "ExampleVolume" -filesystem CSVFS_ReFS -StoragePoolFriendlyName
"ExamplePool" -StorageTierFriendlyNames Performance, Capacity -StorageTierSizes 200GB,
800GB