Export (0) Print
Expand All
6 out of 9 rated this helpful - Rate this topic

What's New in DFS Replication in Windows Server 2012 R2

Published: June 24, 2013

Updated: June 24, 2013

Applies To: Windows Server 2012 R2



This topic describes the features that were added to Distributed File System (DFS) Replication (DFSR or DFS-R) in Windows Server 2012 R2.

For information about the features that were added in Windows Server 2012, see What's New in DFS Namespaces and DFS Replication in Windows Server 2012.

DFS Replication is a role service in the File and Storage Services role. It enables you to efficiently replicate folders (including those referred to by a DFS namespace path) across multiple servers and sites. DFS Replication uses a compression algorithm known as remote differential compression (RDC). RDC detects changes to the data in a file, and it enables DFS Replication to replicate only the changed file blocks instead of the entire file.

The following table describes the changes in DFS Replication functionality that are available in this release.

 

Feature/functionality New or updated? Description

Windows PowerShell module for DFS Replication

New

Provides Windows PowerShell cmdlets for performing the majority of administrative tasks for DFS Replication, in addition to new functionality.

DFS Replication Windows Management Infrastructure provider

New

Provides the latest Windows Management Infrastructure (WMI)-based methods to manage DFS Replication.

Database cloning for initial sync

New

Provides support for bypassing initial replication when creating new replicated folders, replacing servers, or recovering from a disaster.

Database corruption recovery

New

Provides support for rebuilding corrupt databases without unexpected data loss caused by nonauthoritative initial sync.

Cross-file RDC disable

New

Provides the option to disable cross-file remote differential compression (RDC) between servers.

File staging tuning

New

Provides the option to configure variable file staging sizes on individual servers.

Preserved file restoration

New

Provides the capability to restore files from the ConflictAndDeleted and PreExisting folders.

Unexpected shutdown database recovery improvements

Updated

Enables automatic recovery after a loss of power or an unexpected stoppage of the DFS Replication service.

Membership disabling improvements

Updated

Stops DFS Replication private folder cleanup when disabling a server’s membership in a replicated folder.

The DFS Replication module provides Windows PowerShell cmdlets for performing the majority of administrative tasks for DFS Replication, in addition to the new functionality described in this topic.

What value does this change add?

Administrators can use the extensive Windows PowerShell cmdlets to perform common administrative tasks, and optionally automate them by using Windows PowerShell scripts. These tasks include operational actions such as creating, modifying, and removing replication settings. New functionality is also included with the cmdlets, such as the ability to clone DFS Replication databases and restore preserved files.

What works differently?

Instead of using DFS Management or DFS Replication command-line tools, administrators can perform all common tasks by using the Windows PowerShell cmdlets.

The Windows PowerShell cmdlets are available on computers that run Windows Server 2012 R2 or Windows 8.1 and that have the DFS Management Tools feature (part of the Remote Server Administration Tools) installed.

TipTip
To use the Windows PowerShell module for DFS Replication from a computer that doesn’t have the module installed, use the Enter-PSSession or Invoke-Command cmdlets to establish a session with a computer that has the DFS Management Tools feature installed.

Windows Server 2012 R2 includes new Windows Management Infrastructure (sometimes referred to as WMI v2) provider functionality, which provides programmatic access to manage DFS Replication.

What value does this change add?

Management programs can use the latest Windows Management Infrastructure-based methods to manage DFS Replication.

What works differently?

Windows Management Infrastructure-based management access occurs over a firewall friendly Windows Remote Management (WinRM) transport protocol. The WMI v1 namespace is still available for backwards compatibility.

For more information about the new WMI classes, see What’s New.

Windows Server 2012 R2 includes new database cloning functionality, which can accelerate initial replication when you create new replicated folders, replace servers, or recover from disaster.

What value does this change add?

You can now export a DFS Replication database from a volume on one server, and then preseed replicated files and import the database on multiple servers. The replicated folders begin replicating with a greatly reduced initial setup time (the setup time is usually reduced approximately 99%).

What works differently?

In Windows Server 2012 and earlier operating systems, initial sync replication required that a destination server populate its database over the network through a resource-expensive version-vectoring process with the source server. For larger datasets, this can take considerable time (days or weeks), even when you preseed data on the destination server.

Now the Export-DfsrClone cmdlet allows you to export the DFS Replication database and volume configuration .xml file settings for a given volume from the local computer to clone that database on another computer. Running the cmdlet triggers the export in the DFS Replication service and then waits for the service to complete the operation. During the export, DFS Replication stores file metadata in the database as part of the validation process. After you preseed the data and copy the exported database and .xml file to the destination server, you use Import-DfsrClone to import the database to a volume and validate the files in the file system. Any files that perfectly match don’t require expensive interserver metadata and file synchronization, which leads to dramatic performance improvements during the initial sync.

For more information, see Export a Clone of the DFS Replication Database.

Windows Server 2012 R2 provides support for rebuilding corrupt databases without unexpected data loss caused by a nonauthoritative initial sync.

What value does this change add?

When DFS Replication detects database corruption, it rebuilds the database and then resumes replication normally, with no files arbitrarily losing conflicts. When replicating with a Read-only partner, DFS Replication resumes replication without waiting indefinitely for an administrator to manually set the primary flag.

What works differently?

Previously, a corrupt database would trigger DFS Replication to delete the database and start the nonauthoritative initial sync process again, as if replication was being set up for the first time. Any files on the recovering server would lose all conflicts automatically, even if they were the latest version of the file. Those conflicts would move into the ConflictAndDeleted or PreExisting folders, leading to perceived or real data loss.

In Windows Server 2012 R2, when DFS Replication detects database corruption, it rebuilds the database by using local file and update sequence number (USN) change journal information, and then marks each file with a Normal replicated state. DFS Replication then contacts its partner servers and merges the changes, which allows the last writer to save the most recent changes as if this was normal ongoing replication.

Windows Server 2012 R2 provides the option to disable cross-file remote differential compression between servers.

What value does this change add?

You can now specifically choose to use the cross-file remote differential compression (RDC) capability, depending on your data and network topologies. For servers on LANs, turning off cross-file RDC may reduce server resource overhead and increase replication performance.

What works differently?

In Windows Server 2012, DFS Replication always enables cross-file RDC. Cross-file RDC uses up to five existing previously replicated files on a volume to seed a new replicating file. Applying cross-file RDC over low-bandwidth network connections with files that are similar results in large bandwidth savings and potentially large time savings. However, when you use cross-file RDC on high-bandwidth network connections, cross-file RDC might increase local processing time and negatively affect performance. In extremely large datasets (millions of files on a volume with a great deal of similarity), cross-file RDC might also negatively affect CPU and disk utilization.

In Windows Server 2012 R2, DFS Replication allows you to choose whether to use cross-file RDC on a per-connection basis between partners. Disabling cross-file RDC might increase performance at the cost of higher bandwidth usage.

Windows Server 2012 R2 provides the option to configure variable file staging sizes on individual servers.

What value does this change add?

You can now choose a minimum file size for a file to stage if you have not configured RDC for a smaller size. For servers on LANs with larger files, increasing the minimum staging size for files can increase replication performance.

What works differently?

In Windows Server 2012 and earlier operating systems, DFS Replication uses a hard-coded 256 KB file size to determine staging requirements. If RDC is enabled and the RDC minimum size (by default, this is 64 KB) is larger than 256 KB, a file will be staged before it replicates. Usually this means that files smaller than 64 KB don’t get staged on servers running Windows Server 2012 and earlier operating systems. File staging adds replication time to allow for performing RDC operations and to lower the chance of files not replicating because they are in use by applications that created file locks on them.

DFS Replication now allows you to configure the staging minimum size from as little as 256 KB to as large as 512 TB. When you are not using RDC or staging, files are no longer compressed or copied to the staging folder, which can increase performance at the cost of much higher bandwidth usage.

Windows Server 2012 R2 provides the ability to restore files from the ConflictAndDeleted and PreExisting folders.

What value does this change add?

This allows recovery of obfuscated user data from hidden DFS Replication private folders.

What works differently?

Windows Server 2012 and earlier operating systems don’t provide any tools to recover these files.

DFS Replication now enables you to inventory and retrieve the conflicted, deleted, and preexisting files by using the Get-DfsrPreservedFiles and Restore-DfsrPreservedFiles cmdlets. You can restore these files and folders to their previous location or to a new location. You can choose to move or copy the files, and you can keep all versions of a file or only the latest version.

Windows Server 2012 R2 enables automatic recovery after a loss of power or an unexpected stoppage of the DFS Replication service.

What value does this change add?

When DFS Replication detects an unexpected database shutdown (for example, after a power outage or service termination), it automatically validates the database against the file system and then resumes replication normally, settling any file conflicts normally.

What works differently?

In Windows Server 2012 and Windows Server 2008 R2, an unexpected shutdown required you to re-enable replication manually by using a WMI method. You could disable this default behavior by using a per-computer registry value.

When DFS Replication detects an unexpected shutdown in Windows Server 2012 R2, it defaults to triggering the automatic recovery process. You must opt out of this behavior by using the registry value. In addition, if the only replicated folder on a volume is the built-in SYSVOL folder of a domain controller, it automatically triggers recovery regardless of the registry setting.

Windows Server 2012 R2 stops DFS Replication private folder cleanup when disabling a server’s membership in a replicated folder.

What value does this change add?

Files that had previously moved to the ConflictAndDeleted or PreExisting folders are no longer deleted when you disable a server’s replication group membership. Additionally, the message that is displayed by the management tools now states the processing that occurs after memberships are disabled. The message also explains that re-enabling a membership starts nonauthoritative synchronization.

What works differently?

In Windows Server 2012 and earlier operating systems, disabling a membership immediately deleted the DfsrPrivate folder for that membership, including the Staging, ConflictAndDeleted, and PreExisting folders. After these folders are deleted, you can’t easily recover data from them without reverting to a backup.

DFS Replication now leaves the DfsrPrivate folder untouched when you disable a membership. You can recover conflicted, deleted, and preexisting files from that location if the membership is not re-enabled. (Enabling the membership deletes the content of all private folders.)

The following features are included in Windows Server 2012 R2, but they are being phased out, and they likely will be removed from future versions of the Windows Server operating system.

 

Deprecated feature Replacement

DFS Namespaces command-line tool, Dfscmd

DFS Namespaces module for Windows PowerShell

File Replication Service (FRS)

DFS Replication

In Windows Server 2012 R2, it is no longer possible to use Windows PowerShell or Server Manager to create new domains with a Windows Server 2003 domain functional level. This means that new FRS deployments are blocked, and DFS Replication is always used for SYSVOL replication in new domains.

To use FRS to replicate SYSVOL on domain controllers running Windows Server 2012 R2, the domain controllers must belong to an existing domain that uses the Windows Server 2003 domain functional level.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.