Migrating from FRS to DFS-R

Everyone that is using a domain based DFS namespace with more than one target most certainly is using FRS to replicate the data between the replica's. R2 provides a new state-based replication mechanism called 'DFS Replication'.



A summarization of its very cool features and characteristics:

• Unlike NTFRS (which is event-based), a state-based multimaster replication mechanism
• 'DFS Management' MMC for configuration and management
• Replication Group Characteristics:
  • Set of servers that are members of the replication group and participate in the replication of 1 or more replicated folders
  • Set of replicated folders
  • Replication topology (ring, full mesh, custom)
  • Schedule (days and hours) and bandwidth usage
• Replication Folder Characteristics:
  • Replicated between a number of replication group members
  • ‘File’ and ‘Subfolder’ replication filters
  • Staging folder to cache new and changed files for replication, with its own quota that governs when files are purged
• DFS-R uses ‘last writer wins’. Losing file is stored in the ‘ConflictAndDeleted’ folder that resolves the conflict. ‘ConflictAndDeleted’ folder also has its own quota that governs when files are purged and cleaned
• Remote Differential Compression (RDC):
  • By default enabled!
  • Only changes (at bit level!) are replicated between members
  • Data is compressed during replication
  • Not used on files <>
  • On high-speed LANs/WANs it might NOT be beneficial. RDC can be disabled on a per connection basis
  • CROSS-FILE RDC: identifies files that are similar to the file that needs to be replicated from one server to another by using portions from files that are similar. One of the end-point servers must be R2 enterprise or R2 datacenter or R2 Storage edition!
• Scheduling and bandwidth throttling:
  • When configuring the interval you need to specify a start and stop time and the bandwidth usage
  • Schedules in 15 min. increments during 7 period
  • Schedules are based upon: ‘UTC’ or ‘Local time of receiving member’
  • Bandwidth usage options: ‘Full’, ‘No replication’, ‘16Kbps’, ’64Kbps’, ‘128Kbps’, ‘256Kbps’, ‘512Kbps’, ‘1Mbps’, ‘2Mbps’, ‘4Mbps’, ‘8Mbps’, ‘16Mbps’, ‘32Mbps’, ‘64Mbps’, ‘128Mbps’, ‘256Mbps’
  • Schedules and bandwidth usage can be defined for the replication group that applies to all connections or on a per connection basis a custom schedule and bandwidth usage can be defined
• DFS Replication can be used for:
  • Domain based DFS namespaces
  • Stand alone based DFS namespaces
  • Individual folders not part of a DFS namespace
• DFS Replication self-healing
  • For USN journal wrap errors (journal wrap errors can occur when changes are not recorded or are occuring to fast without being recorded)
  • For jet database corruption: Replication is halted but service is still available (unlike NTFRS)
• Member recovery and prestaging
  • DFS-R stores configuration in AD and the server caches same info locally in XML file. File is rebuild easily
  • Servers can be prestaged easily by just copying or restoring the data. Differences are checked…
  • Outdated files are updated by just replication the changes from the source server
  • Files on the prestaged server that do not exist on the source server are moved to the PreExisting folder
  • Unlike NTFRS which needed a non-authoritative restore of the replica set
• Built-in health metrics and diagnostic events
• Built-in WMI providers are available for monitoring DFS Replication
• Separate DFS Replication event log available
• Built-in diagnostic reports can be created with the 'DFS Management' snap-in (watch out for the RPC bug! -->

• http://blogs.dirteam.com/blogs/jorge/archive/2006/01/02/360.aspx)
• MOM MP for DFS Replication

With the legacy 'Distributed File System' a namespace was created with underlying DFS folders. When one of the DFS folders had two or more DFS folder targets, replication could be setup using FRS and by choosing one of the DFS folder targets as primary master replica to start replication from that same replica to the other replicas.

With the new 'DFS Namespaces' a namespace was created with underlying DFS folders. When one of the DFS folders had two or more DFS folder targets, replication could be setup using DFS-R by creating a NEW replication group that contain the DFS folder targets a replication group members and contain the DFS folder as a replicated folder. Unfortunately, when working from the 'DFS Namespaces' node it is not possible to add the DFS folder as a replicated folder to an existing replication group. To be able to do that you first select an existing replication group, add a new replicated folder and select the replication group members that host that replicated folder. Last step is to SHARE and PUBLISH the replicated folder as a DFS folder in a DFS namespace. For the last part to succeed that DFS folder must not yet exist in the desired DFS namespace (very important!). Each replication group can contain one or more replicated folders.

So what is different in the concept between FRS and DFS-R? The main difference here is that each DFS folder using FRS for replication can be compared to ONE replication group only having ONE replicated folder. And as you just have read DFS-R can have replication groups with MULTIPLE replicated folders.

When migrating from FRS to DFS-R you have to possibilties:

(1) Configure each existing DFS folder using FRS replication within A SEPARATE DFS-R replication group with one replicated folder

(2) Configure each existing DFS folder using FRS replication within A SEPARATE OR EXISTING DFS-R replication group. This way one replication group can contain one or more DFS folders as replicated folders that share the same replication topology, replication schema and bandwidth usage.



Before starting with the migration from FRS to DFS-R, I do recommend that one first reads the following document as it contains information on how to setup/design DFS Namespaces and DFS Replication:

• Designing Distributed File Systems
  • http://technet2.microsoft.com/WindowsServer/en/Library/1aa249c0-40f3-4974-b67f-e650b602415e1033.mspx
    
    

The high-level steps to migrate from FRS to DFS-R are:

• Inventory all DFS folders within legacy DFS namespaces that use FRS replication
• Inventory for each DFS folder the following information:
  • DFS namespace path (e.g. \\ domain>\\)
  • Replication topology
  • Replication schema
  • File and subfolder filters (replicated folder specific)
  • Staging size (replicated folder specific for each specific replication group member)
  • DFS folder targets and the local path of the folder
  • Delegated tasks (can now be delegated at different level within DFS Namespaces and DFS Replication groups!)
• From the inventory see which DFS folders have the following characteristics in common and for those design a replication group that contains the DFS folders as replicated folders:
  • Replication topology
  • Replication schema
  • Delegated tasks
• Perform the following tasks for each DFS folder:
  • Remove FRS replication configuration by using the legacy 'Distributed File System snap-in', selecting the DFS folder, right-clicking it and select 'stop replication' (after doing that replication is stopped for that folder and configuration is removed!)
  • Wait for AD replication to complete or force replication through (without the quotes) -> "repadmin /syncall /e /d /A /P /q"
  • Wait for each DFS folder target to poll the new configuration from AD or force the folling through (without the quotes) -> "ntfrsutl poll /now "
  • Depending on the inventory create a new replication group or use an existing replication
  • Assign the DFS folder as a replicated folder, select the primary replica and select additional replicas
  • Configure the File and subfolder filters if different from the default
  • Configure the Staging Folder size if different from the default

REMARK: from this point the DFS folder is available through the DFS namespace and replication is working. However when looking from the DFS Namespaces node by selecting the DFS folder and then the Replication TAB it will show: "Replication status: not configured". And when looking from the DFS Replication node by selecting the replication group and then the replicated folders TAB it will show: "Publication status: not published". The main reason for this is because an attribute is not populated (we will take care of that later!)



REMARK: sharing and publishing the folder into the desired DFS namespace will not work because the DFS folder already exists in the DFS namespace

• Use ADSIEDIT.MSC to populate the attribute "msDFSR-DfsPath" of the object "CN=,CN=Content,CN=,CN=DFSR-GlobalSettings,CN=System,DC=,DC=" with the DFS namespace path of the DFS folder that was collected earlier during inventory
• Wait for AD replication to complete or force replication through (without the quotes) -> "repadmin /syncall /e /d /A /P /q"
• Wait for each new DFS-R based DFS folder target to poll the new configuration from AD (by default 60 minutes) or force the folling through (without the quotes) -> "dfsrdiag PollAD /Member:"
• Remove the hidden folders used by FRS from the DFS folder (e.g. "DO_NOT_REMOVE_NtFrs_PreInstall_Directory") (do not touch the "DfsrPrivate" folder as that is used by DFS-R)
• After migrating all DFS folders that used FRS to DFS-R cleanup the staging directories used by FRS (e.g. "Frs-Staging")
• If a DFS Namespace was created using the legacy 'Distributed File System' MMC then you might want to enable SITECOSTING at DFS namespace level. The legacy 'Distributed File System' MMC does not enable sitecosting by default as the 'DFS Management' MMC does

To create and configure DFS replication groups and to assign and configure replicated folder the 'DFS Management' MMC can be used or the command utility 'dfsradmin.exe' can be used. The latter, of course. can be usefull in performing repeated tasks!

Well.... this is it! ENJOY!



If you use this information, please be so kind to post any comments you have!



And of course: TRY IT FIRST IN A TEST ENVIRONMENT AND SEE IF THE RESULTS ARE SATISFYING!!!