实战:创建基于域的分布式文件系统（DFS）
1.1 实战:创建基于域的分布式文件系统（DFS）
如果局域网中有多台服务器，并且共享文件夹也分布在不同的服务器上，这就不利于管理员的管理和用户的访问。而使用分布式文件系统，系统管理员就可以把不同服务器上的共享文件夹组织在一起，构建成一个目录树。这在用户看来，所有共享文件仅存储在一个地点，只需访问一个共享的DFS根目录，就能够访问分布在网络上的文件或文件夹，而不必知道这些文件的实际物理位置。
DFS 复制是一种有效的多主机复制引擎，可用于保持跨有限带宽网络连接的服务器之间的文件夹同步。它将文件复制服务 (FRS) 替换为用于 DFS 命名空间以及用于复制使用 Windows Server 2008 域功能级别的域中的 Active Directory 域服务 (AD DS) SYSVOL 文件夹的复制引擎。
DFS 复制使用一种称为远程差分压缩 (RDC) 的压缩算法。RDC 检测对文件中数据的更改，并使 DFS 复制仅复制已更改文件块而非整个文件。
若要使用 DFS 复制，必须创建复制组并将已复制文件夹添加到组。复制组、已复制文件夹和成员在下图中进行了说明。
此图所示复制组是一组称为“成员”的服务器，它参与一个或多个已复制文件夹的复制。“已复制文件夹”是在每个成员上保持同步的文件夹。图中有两个已复制文件夹：Projects 和 Proposals。每个已复制文件夹中的数据更改时，将通过复制组成员之间的连接复制更改。所有成员之间的连接构成复制拓扑。
如果在一个复制组中创建多个已复制文件夹，可以简化部署已复制文件夹的过程，因为该复制组的拓扑、计划和带宽限制将应用于每个已复制文件夹。若要部署其他已复制文件夹，可以使用 Dfsradmin.exe 或按照向导中的说明来定义新的已复制文件夹的本地路径和权限。
每个已复制文件夹具有唯一的设置，例如文件和子文件夹筛选器，以便可以为每个已复制文件夹筛选出不同的文件和子文件夹。
存储在每个成员上的已复制文件夹可以位于成员中的不同卷上，已复制文件夹不必是共享文件夹也不必是命名空间的一部分。但是，“DFS 管理”管理单元使得易于共享已复制文件夹，并选择性地在现有命名空间中发布它们。
冲突和已删除文件夹
在两个或更多成员修改文件并且每个成员没有看到其他成员的版本时，“DFS 复制”使用“最后写入者优先”的方法来确定要保留的文件版本。放弃的文件存储在解决冲突的成员的冲突和已删除文件夹中。冲突和已删除文件夹还可以用于存储从已复制文件夹中删除的文件。每个冲突和已删除文件夹都有配额，用于控制为进行清理而清除文件的时间。
DCServer是域的域控制器和DNS服务器， FileServer和ProfileServer是两个文件服务器，Research是研发部门的计算机，Sales是销售部门的计算机。这些计算机都加入了域
为了让域用户访问FileServer和ProfileServer以及Research服务器上共享资源方便，将分布在这些服务器上的资源逻辑的整合在在DCServer上创建一个“常用文件”中。
为了使FileServer服务器上的“安装文件”夹容错和负载均衡，将ProfileServer的“安装文件”添加到DCServer上“常用文件”中“安装文件”目标。
DFS还为有分支办公室的网络环境提供了很好的支持。可以将用户透明的定向到网络连接较好的服务器上。
ü DCServer 安装了Windows Server 2008企业版操作系统
ü FileServer 安装了Windows Server 2008企业版操作系统
ü Research 安装了Windows Server 2008企业版操作系统
ü ProfileServer安装Windows Server 2008企业版核心
ü Sales 安装了Vista操作系统
如上图，在文件服务器Research有个共享文件夹“技术资料”，在FileServer上有共享文件夹“安装文件”。我们在DCServer服务器上创建一个共享文件夹“常用文档”，这个常用文档就是DFS的根，然后就添加两个连接指向“安装文件”和“技术资料”两个共享文件，这两个连接在用户看来就是“常用文件”夹中的两个子文件夹。用户点击“常用文件”中的“技术资料”文件夹将会把用户透明的定位到\\Research\技术资料。
在DCServer上“常用文档”中的“安装文件”，连接指向了\\FileServer\安装文件 和 \\ProfileServer\安装文件 两个网络文件夹。这两个文件夹会实现自动同步。大量用户访问时\\DCServer\常用文档\安装文件 时，将会把用户均匀的定位到两个服务器上，因此实现负载均衡，如果其中ProfileServer服务坏掉了，用户会自动全部定位到fileServer服务器上“安装文件”文件夹，这样实现容错。
ü 创建基于域的分布式文件系统
ü 访问基于域的分布式文件系统
ü 实现对分支办公室的支持
1.1.1 任务：创建基于域的DFS
在FileServer安装“分布式文件系统”，“DFS复制”，“文件服务器”。
在Research安装“分布式文件系统”，“DFS复制”，“文件服务器”。
在DCServer上安装“DFS命名空间”。并创建命名空间，在该命名空间中添加文件夹。
1. 以域管理员用户帐户登录FileServer。
2. 打开“服务器管理器”，点击“文件服务”，可以看到有些文件服务器角色服务没有安装。
3. 点击“添加角色”。
4. 在出现的选择角色服务对话框，选中“分布式文件系统”、“DFS命名空间”、“DFS复制”、“文件服务器”
5. 在出现的配置存储使用情况监视对话框，点击“下一步”，完成安装。
6. 以域管理员用户帐户登录到DCServer。
7. 打开服务器管理器，如下图，点击“添加角色”。
8. 在出现的选择服务器角色对话框，选中“文件服务”，点击“下一步”。
9. 在出现的选择角色服务对话框中，选中“FDS命名空间”，点击“下一步”。
10. 在出现的对话，点击“下一步”。
11. 在出现的创建DFS命名空间对话框，选中“立即使用此向导创建命名空间”，输入“常用文件”，点击“下一步”。
12. 在选择命名空间类型对话框，选择“基于域的命名空间”，选中“启用Windows Server 2008模式”，点击“下一步”。
13. 在配置命名空间对话框中，点击“下一步”，完成向导。
14. 点击服务器管理器中的“文件服务”à“DFS管理”à“命名空间”à“\\\常用文件”，点击“创建文件夹”。
15. 在出现的对话框，输入名称“技术资料”，文件夹目标，点击“添加”，输入\\Research\技术资料，点击“确定”。
16. 点击“确定”，完成新建文件夹。
可以看到，您还可以继续点击“添加”按钮添加多个目标，这些目标文件夹将会自动同步，这样可以避免硬件故障造成的数据丢失，同时多个访问者被均匀的定位到多个目标文件夹，这样实现负载均衡。
17. 使用相同的方法，在该命名空间中，添加指向\\FileServer\安装文件 的“安装文件”。
1.1.2 任务：添加多个名称空间
在一个域中可以有多个命名空间，您也可以在使用DFS管理工具管理DFS命名空间。以下示例演示，在域中创建一个“人力资源”的名称空间。名称空间服务器仍然是DCServer。这样您就可以在“人力资源”命名空间，组织人力资源相关的文件夹了。
1. 点击“开始”à“程序”à“管理工具”à“DFS Management”。
2. 再出现的DFS管理对话框，点击“新建命名空间”。
3. 在出现的命名空间服务器对话框，输入DCServer 点击“下一步”。
4. 在命名空间名称和设置对话框，输入名称“人力资源”，点击“下一步”。
5. 在命名空间类型对话框，选择“基于域的命名空间”，选中“启用Windows Server 2008模式”，点击“下一步”。
6. 在复查设置并创建命名空间对话框，注意观察命名空间名称 \\\人力资源，点击“创建”。
1.1.3 任务：访问命名空间中的文件夹
用于者使用名称空间访问共享资源。
1. 使用域用户帐户administrator在Sales计算机登录。
2. 点击“开始”à“运行”，输入\\ 点击“确定”。
使用命名空间访问共享文件夹，可以看到域中所有的名称空间。
3. 点击“常用文件”，您可以看到该名称空间下的两个文件夹。
4. 双击“安装文件“，您将被透明的定位到\\FileServer\安装文件。
5. 您也可以直接访问命名空间服务，访问到共享资源。
1.1.4 任务：在Server Core计算机上添加DFS冗余
在ProfileServer计算机上安装以下服务。
ü 文件复制服务(FRS-Infrastructure)
ü 分布式文件系统服务(DFSN-Server)
ü 分布式文件系统复制(DFSR-Infrastructure-ServerEdition)
在DCSever上添加“安装文件”的冗余文件夹。
1. 以域管理员的用户帐户登录ProfileServer计算机
2. 如下图定位到c:\windows\system32目录下，输入cscript scregedit.wsf /cli 显示可用的命令汇总。
3. 输入Oclist 显示该计算机安装的和没有安装的角色和服务。
4. 输入Start/w Ocsetup FRS-Infrastructure 按回车键。
5. 输入Start/w Ocsetup DFSN-Server按回车键。
6. 输入 Start/w Ocsetup DFSR-Infrastructure-ServerEdition按回车键。
注：角色和角色服务名字区分大小写。
7. 以域管理员的用户帐户登录到DCServer。
8. 点击“开始”à“程序”à“管理工具”à“DFS Management”。
9. 在DFS管理对话框，如下图，点击“常用文件“命名空间下”安装文件“，双击”“添加文件夹目标”。
10. 在新建文件夹目标对话框，点击“浏览”。
11. 在浏览共享文件夹对话框，服务器输入profileServer，点击显示共享文件夹，发现没有共享的文件夹，点击“创建共享文件夹”。
12. 在创建共享对话框，输入共享名“安装文件”，点击“浏览”。
13. 在出现的浏览文件夹，选中c$，点击“创建文件夹”，输入文件夹的名称。点击“确定”。
14. 在创建文件夹目标对话框，点击“确定”。
15. 在出现的复制对话框，点击“是”。
16. 在复制组和已复制文件夹名对话框，点击“下一步”。
17. 在复制合格对话框，点击“下一步”。
18. 在主成员对话框，选中主成员Fileserver。
注：在这里指定的主成员，只是在初次复制时以那个服务器的文件夹中的数据为主，配置好了之后，就不存在主和辅的区别，用户可以修改两个文件服务器上文件，通过复制达到数据同步。
19. 在拓扑选项对话框，选择“交错”，点击“下一步”。
20. 在复制计划和带宽对话框，选择“使用指定带宽连续复制”，点击“下一步”。
21. 在复查设置并创建复制组对话框，点击“下一步”。
22. 在确认对话框，点击“关闭”，完成添加目标文件夹。
1.1.5 任务：验证DFS的复制和容错
验证“安装文件”的复制和容错。
1. 以域管理员用户帐户登录到FileServer。
2. 在E盘“安装文件”中创建一个记事本文件“FileServer.txt”
3. 点击“开始”à“运行”，输入\\profileserver\安装文件。
4. 您会发现，在Profileserver服务器的安装文件上也会立即出现。
5. 点击“VM”à“Removable Devices”à“Ethernet”à“Disconnect”，断开FileServer服务器的网卡，这样用户就不能访问其共享的“安装文件”了。
6. 在Sales计算机访问\\\常用文件中的“安装文件”，发现等稍长的时间用户还是能够打开安装文件。
1.1.6 任务：管理DFS复制
默认DFS中多个目标文件夹是相互复制的，如图，右击接收成员FileServer，点击“禁用”，这样只能实现FileServer到ProfileServer的复制。
也可以点击“立即复制副本”。
点击“删除”，可以删除连接。
点击“创建连接”，在出现的对话框，可以指定发送成员，接收成员，如果不选中“在相反方向创建另一个连接”，只能创建单向连接。
1.1.7 任务：支持分支办公室
如下图，某公司创建了一个域，分公司在石家庄，网络中心在北京，分公司和网络中心通过广域网连接，网络中心的子网10.7.10.0 255.255.255.0，分公司的子网192.168.1.0 255.255.255.0。
公司的“安装文件”存放在FileServer服务器上，分公司用户访问FileServer跨越广域网，速度较慢。为了让分公司的员工访问公司安装文件，在分公司放一个文件服务器ProfileServer创建“安装文件”文件夹并共享，然后利用DFS将“安装文件”在这两个服务器上同步。
当石家庄的用户访问输入\\\常用文件 访问该域中的命名空间时，用户最好被定位到位于石家庄站点的ProfileServer服务器上。当北京的用户访问输入\\\常用文件 访问该域的命名空间时，最好被定位到位于北京站点的FileServer服务器上。
要实现将用户自动定位到同一站点的服务器上，您需要配置活动目录站点和子网对象。这样命名空间服务器将会根据用户计算机的IP地址，将用户定位到同一站点的文件服务器上。
首先按照上图配置计算机的IP地址。需要在DCServer计算机的网络连接添加两个Ip地址，来模拟两个网卡，然后将其配置成路由器，允许在网络中心和分公司之间转发数据包。
在DCServer上创建创建活动目录站点和子网对象。
1. 以域管理员的身份登录到域控制器DCServer上。
2. 打开服务器管理器，点击“角色”，点击“添加角色”。在出现的对话，点击“下一步”。
3. 在选择角色服务对话框，选中“网络策略和访问服务”，点击“下一步”。
4. 选中“路由”和“远程访问服务”，点击“下一步”，在确认选择对话，点击“安装”，完成安装。
5. 点击“开始”à“程序”à“管理工具”à“路由和远程访问”。
6. 右击DCServer服务器，点击“配置并启用路由和远程访问”。
7. 在配置对话框，选择“自定义配置”，点击“下一步”。
8. 在自定义配置对话框，选中“LAN路由”，点击“下一步”，完成配置。现在已经将DCServer配置路由器了，通常将Windows配置成的路由器称为软路由。
9. 点击“开始”à“程序”à“管理工具”à“Active Directory 站点和服务”。
10. 右击Default-First-Site-Name，点击“重命名”，输入“北京”。
11. 右击Site，点击“新站点”，输入“石家庄”，选中下面的连接“DEFAULTIPSITELINK”，点击“确定”。
12. 出现提示对话框，点击“确定”。
13. 右击Subnet，点击“创建子网”，输入10.7.10.0/24，选中北京站点，点击“确定”。
14. 创建子网对象 192.168.1.0/24，选中石家庄站点，点击“确定”。
15. 再次打开DFS您会发现，“安装文件”的文件夹目标，FileServer服务器在北京站点，ProfileServer在石家庄站点。这说明活动目录根据服务器的IP地址对照活动目录站点子网对象将其划分到不同的站点中。
1.1.8 任务：测试到DFS的连接
以上的操作根据网络的物理结构创建了活动目录站点和子网对象。现在活动目录就可以针对FileServer和ProfileServer的IP地址来断定其所在的活动目录站点。
客户端访问命名空间时，命名空间服务器DCServer会根据客户端的IP地址，优先将用定位到和用户在同一站点的文件服务器上。
示例：验证DFS连接
1. 以域管理员的用户帐户登录Sales计算机。
2. 将其Ip地址设置成10.7.10.56，子网掩码设置成 255.255.255.0 网关设置成10.7.10.123，DNS设置成10.7.10.123。这个地址属于是北京站点。
3. 点击“开始”à“运行”，输入\\ ，点击“确定”。
4. 打开“常用文件”中的“安装文件”。
5. 在FileServer计算机上，点击“开始”à“程序”à“管理工具”à“共享和存储管理”。
6. 可以看到，Sales计算机计算机访问DFS被定为到FileServer计算机。FileServer属于北京站点。
7. 将Sales计算机的IP地址设置成192.168.1.56 子网掩码 255.255.255.0 网关设置成192.168.1.100 DNS设置成192.168.1.100。
8. 再次打开\\\常用文件 名称空间，点击“安装文件”。
9. 在ProfileServer上运行netstat –n 可以看到Sales计算机访问profileServer共享文件夹建立的会话。访问共享文件夹使用的端口是TCP的445端口。
足以验证上面设置活动目录站点和子网对象对用户访问DFS的影响。
更多相关文章
近日学习了windows2008 的NLB的应用.在学习的过程中,采用3台虚拟机作为服务器. coputer1: 计算机名:test1 ip:172.16.75.245 作用:配置dns和域控制器. computer2:计算机名:hz-zjjtest02 公网ip:172.16.59.50 内网ip ...
近日学习了windows2008 的NLB的应用.在学习的过程中,采用3台虚拟机作为服务器.coputer1: 计算机名:test1ip:172.16.75.245作用:配置dns和域控制器.computer2:计算机名:hz-zjjtest02公网ip:172.16.59.50内网ip:10.0. ...
在上一篇文章server 2012网络负载均衡NLB介绍的文章中,我们当时做实验的时候为了能够把效果表现出来,所以NLB2和NLB3两台机器上装IIS的index.htm文件我们分别创建了不同的两个文件,而实际工作中,我们搭建一台web服务器,如果做NLB的时候,往往都是为了一台机器down掉,另外 ...
近日一直在闭关修炼,近得闲暇,特浮出水面,把修炼中的一些所得和各位同道论坛论坛,以光我CTO之道门. 在中国,中小企业当然是大把大把滴,其OA环境多以几十台PC据多,有一些重要的数据,都是存储在具有镜像阵列磁盘的服务器上,但问题是磁盘阵列要是挂了呢?就算是数据能恢复,它也要花时间来鼓捣啊,这中间也误 ...
如果网络中的共享文件夹比较多,而且位置又比较分散,那当用户需要访问多个共享文件夹时,就要逐台搜索并登录相应的服务器.而利用分布式文件系统(Distributed File System,DFS),管理员就可以把不同计算机上的共享文件夹组织在一起,构建成一个目录树,用户只需访问一个共享DFS根目录,就 ...
分布式文件系统(DFS)基础分布式文件系统概述DFS是一种服务,它允许系统管理员将分布式的网络共享资源组织到一个逻辑名称空间中,从而使用户不用指定文件的物理位置和提供网络共享的负载就能访问文件.使用DFS可以创建一个目录树,该树中包含一个组.部门或企业内的多个文件服务器和文件共享.这样可使用户很轻松 ...
如果网络中的共享文件夹比较多,而且位置又比较分散,那当用户需要访问多个共享文件夹时,就要逐台搜索并登录相应的服务器.而利用分布式文件系统(Distributed File System,DFS),管理员就可以把不同计算机上的共享文件夹组织在一起,构建成一个目录树,用户只需访问一个共享DFS根目录,就 ...
一.分布式文件系统 1.简介 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连.分布式文件系统的设计基于客户机/服务器模式.一个典型的网络可能包括多个供多用户访问的服务器.另外,对等特性允许一些系统 ...
上一篇:&CSS3小分队——进击的border-radius& 写在前面: 上 ...
在简单环境下大家想让自己的虚拟机上网,网卡设为桥接就是完全ok的,但是如果真实机是通过AD ...
有的是自己拍的,人后进行P图,有的是在别的店家盗用的.还有在百度上下载的自己更改一下,还有就是厂家提供的.转:/question/6784668. ...
无论网页或是移动APP的设计,很重要的一点是如何能在小而美和功能复杂性之间找到平衡点.本文 ...
转载:/article-4623-weixin.html#r ...
这是一个比较常见的需求,研究了一下,找到设置图片灰度显示和恢复彩色显示的方法,接下来,将用 ...
一.建立服务器连接文档二.建立函件收集数据库三.进行两个Domino服务器之间的交叉验证(用当前服务器cert.id验证对方的server.id) 第一步:建立服务器连接文档1.打开管理端,在配置标签下打开服务器 ...
64位 Fedora 11 硬盘安装 配置全解 转贴:/viewthread.php?tid=7428&extra=page%3D1 硬盘安装 Fedora ...
1 什么是多点地图?“多点地图”是51ditu为用户提供的傻瓜地图编辑工具,在“多点地 ...
sudo apt-get -y install bzr
build-essential automake libboost-dev libxml2-dev libsdl-image1.2-dev libsdl-mi ...500 - 内部服务器错误。
500 - 内部服务器错误。
您查找的资源存在问题，因而无法显示。DFS Replication: Frequently Asked Questions (FAQ)
Expand the table of content
DFS Replication: Frequently Asked Questions (FAQ)
Published: October 16, 2006Updated: October 9, 2013Applies To: Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
This FAQ answers questions about Distributed File System (DFS) Replication (also known as DFS-R or DFSR) for the Windows Server 2012 R2, Windows Server 2012, Windows Server(R) 2008 R2, Windows Server 2008, and Windows Server 2003 R2 operating systems.
For information about DFS Namespaces, see .
For information about what’s new in DFS Replication, see the following topics:
(in Windows Server 2012)
For a list of recent changes to this topic, see the
section of this topic.
No. DFS Replication does not communicate with File Replication Service (FRS). DFS Replication and FRS can run on the same server at the same time, but they must never be configured to replicate the same folders or subfolders because doing so can cause data loss.
Yes, DFS Replication can replace FRS for SYSVOL replication on servers running Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008. Servers running Windows Server 2003 R2 do not support using DFS Replication to replicate the SYSVOL folder.
For more information about replicating SYSVOL by using DFS Replication, see the .
Yes. To migrate replication from FRS to DFS Replication, see the following documents:
To migrate replication of folders other than the SYSVOL folder, see
(/fwlink/?LinkID=195437).
To migrate replication of the SYSVOL folder to DFS Replication, see .
Yes. Although DFS Replication only supports replicating content between servers running Windows Server, UNIX clients can access file shares on the Windows servers. To do so, install Services for Network File Systems (NFS) on the DFS Replication server.
You can also use the SMB/CIFS client functionality included in many UNIX clients to directly access the Windows file shares, although this functionality is often limited or requires modifications to the Windows environment (such as disabling SMB Signing by using Group Policy).
DFS Replication interoperates with NFS on a server running a Windows Server operating system, but you cannot replicate an NFS mount point.
Yes. DFS Replication is supported on Volume Shadow Copy Service (VSS) volumes and previous snapshots can be restored successfully with the Previous Versions Client.
No, using Windows Backup (Ntbackup.exe) on a computer running Windows Server 2003 or earlier to back up the contents of a replicated folder on a computer running Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008 is not supported.
To back up files that are stored in a replicated folder, use Windows Server Backup or Microsoft(R) System Center Data Protection Manager. For information about Backup and Recovery functionality in Windows Server 2008 R2 and Windows Server 2008, see . For more information, see
(/fwlink/?LinkId=182261).
Yes. Do not configure file system policies on replicated folders. The file system policy reapplies NTFS permissions at every Group Policy refresh interval. This can result in sharing violations because an open file is not replicated until the file is closed.
No. DFS Replication cannot be used to replicate mailboxes hosted on Microsoft Exchange Server.
Yes. However, the File Server Resource Manager (FSRM) file screening settings must match on both ends of the replication. In addition, DFS Replication has its own filter mechanism for files and folders that you can use to exclude certain files and file types from replication.
The following are best practices for implementing file screens or quotas:
The hidden DfsrPrivate folder must not be subject to quotas or file screens.
Screened files must not exist in any replicated folder before screening is enabled.
No folders may exceed the quota before the quota is enabled.
You must use hard quotas with caution. It is possible for individual members of a replication group to stay within a quota before replication, but exceed it when files are replicated. For example, if a user copies a 10 megabyte (MB) file onto server A (which is then at the hard limit) and another user copies a 5 MB file onto server B, when the next replication occurs, both servers will exceed the quota by 5 megabytes. This can cause DFS Replication to continually retry replicating the files, causing holes in the version vector and possible performance problems.
Yes, DFS Replication in Windows Server 2012 R2, Windows Server 2012 and Windows Server 2008 R2 includes the ability to add a failover cluster as a member of a replication group. For more information, see
(/fwlink/?LinkId=155085).The DFS Replication service on versions of Windows prior to Windows Server 2008 R2 is not designed to coordinate with a failover cluster, and the service will not fail over to another node.
DFS Replication does not support replicating files on Cluster Shared Volumes.
Yes, DFS Replication can replicate folders on volumes that use Data Deduplication in Windows Server.
Yes. DFS Replication replicates volumes on which Single Instance Storage (SIS) is enabled. SIS is used by Remote Installation Services (RIS), Windows Deployment Services (WDS), and Windows Storage Server.
You can safely use DFS Replication and Offline Files together in scenarios when there is only one user at a time who writes to the files. This is useful for users who travel between two branch offices and want to be able to access their files at either branch or while offline. Offline Files caches the files locally for offline use and DFS Replication replicates the data between each branch office.
Do not use DFS Replication with Offline Files in a multi-user environment because DFS Replication does not provide any distributed locking mechanism or file checkout capability. If two users modify the same file at the same time on different servers, DFS Replication moves the older file to the DfsrPrivate\ConflictandDeleted folder (located under the local path of the replicated folder) during the next replication.
Antivirus applications can cause excessive replication if their scanning activities alter the files in a replicated folder. For more information,
(/fwlink/?LinkId=73990).
Windows(R) SharePoint(R) Services provides tight coherency in the form of file check-out functionality that DFS Replication does not. If you are concerned about multiple people editing the same file, we recommend using Windows SharePoint Services. Windows SharePoint Services 2.0 with Service Pack 2 is available as part of Windows Server 2003 R2. Windows SharePoint Services can be downloaded from the Microsoft W it is not included in newer versions of Windows Server. However, if you are replicating data across multiple sites and users will not edit the same files at the same time, DFS Replication provides greater bandwidth and simpler management.
Yes—assuming that there is a private Wide Area Network (WAN) link (not the Internet) connecting the branch offices. However, you must open the proper ports in external firewalls. DFS Replication uses the RPC Endpoint Mapper (port 135) and a randomly assigned ephemeral port above 1024. You can use the Dfsrdiag command line tool to specify a static port instead of the ephemeral port. For more information about how to specify the RPC Endpoint Mapper, see
in the Microsoft Knowledge Base (/fwlink/?LinkId=73991).
No. DFS Replication will not replicate files or folders that are encrypted using the Encrypting File System (EFS). If a user encrypts a file that was previously replicated, DFS Replication deletes the file from all other members of the replication group. This ensures that the only available copy of the file is the encrypted version on the server.
DFS Replication can safely replicate Microsoft Outlook personal folder files (.pst) and Microsoft Access files only if they are stored for archival purposes and are not accessed across the network by using a client such as Outlook or Access (to open .pst or Access files, first copy the files to a local storage device). The reasons for this are as follows:
Opening .pst files over network connections could lead to data corruption in the .pst files. For more information about why .pst files cannot be safely accessed from across a network, see
in the Microsoft Knowledge Base (/fwlink/?LinkId=125363).
.pst and Access files tend to stay open for long periods of time while being accessed by a client such as Outlook or Office Access. This prevents DFS Replication from replicating these files until they are closed.
No. DFS Replication relies on Active Directory(R) Domain Services for configuration. It will only work in a domain.
Yes. DFS Replication can replicate numerous folders between servers. Ensure that each of the replicated folders has a unique root path and that they do not overlap. For example, D:\Sales and D:\Accounting can be the root paths for two replicated folders, but D:\Sales and D:\Sales\Reports cannot be the root paths for two replicated folders.
No. DFS Replication and DFS Namespaces can be used separately or together. In addition, DFS Replication can be used to replicate standalone DFS namespaces, which was not possible with FRS.
No. DFS Replication does not explicitly require time synchronization between servers. However, DFS Replication does require that the server clocks match closely. The server clocks must be set within five minutes of each other (by default) for Kerberos authentication to function properly. For example, DFS Replication uses time stamps to determine which file takes precedence in the event of a conflict. Accurate times are also important for garbage collection, schedules, and other features.
Yes. However, you must first install Windows Server 2003 Service Pack 2 or the hotfix. For more information, see
in the Microsoft Knowledge Base (/fwlink/?LinkId=76776). Additionally, replicating an entire volume can cause the following problems:
If the volume contains a Windows paging file, replication fails and logs DFSR event 4312 in the system event log.
DFS Replication sets the System and Hidden attributes on the replicated folder on the destination server(s).
This occurs because Windows applies the System and Hidden attributes to the volume root folder by default. If the local path of the replicated folder on the destination server(s) is also a volume root, no further changes are made to the folder attributes.
When replicating a volume that contains the Windows system folder, DFS Replication recognizes the %WINDIR% folder and does not replicate it. However, DFS Replication does replicate folders used by non-Microsoft applications, which might cause the applications to fail on the destination server(s) if the applications have interoperability issues with DFS Replication.
Yes. DFS Replication is independent of the connection type.
No. DFS Replication supports volumes formatted with the NTFS the Resilient File System (ReFS) and the FAT file system are not supported. DFS Replication requires NTFS because it uses the NTFS change journal and other features of the NTFS file system.
Yes. You can replicate sparse files. The Sparse attribute is preserved on the receiving member.
No. DFS Replication is a service that runs under the local system account, so you do not need to log in as administrator to replicate. However, you must be a domain administrator or local administrator of the affected file servers to make changes to the DFS Replication configuration.
For more information, see "DFS Replication security requirements and delegation" in the
(/fwlink/?LinkId= 182294).
To upgrade or replace a DFS Replication member, see this blog post on the Ask the Directory Services Team blog: .
Yes. Certain scenarios are supported when replicating roaming user profiles. For information about the supported scenarios, see
(/fwlink/?LinkId=201282).
Windows and DFS Replication support folder paths with up to 32 thousand characters. DFS Replication is not limited to folder paths of 260 characters.
No. Replication groups can span across domains within a single forest but not across different forests.
The following list provides a set of scalability guidelines that have been tested by Microsoft on Windows Server 2012 R2:
Size of all replicated files on a server: 100 terabytes.
Number of replicated files on a volume: 70 million.
Maximum file size: 250 gigabytes.
When creating replication groups with a large number or size of files we recommend exporting a database clone and using pre-seeding techniques to minimize the duration of initial replication. For more information, see .
The following list provides a set of scalability guidelines that have been tested by Microsoft on Windows Server 2012, Windows Server 2008 R2, and Windows Server 2008:
Size of all replicated files on a server: 10 terabytes.
Number of replicated files on a volume: 11 million.
Maximum file size: 64 gigabytes.
There is no longer a limit to the number of replication groups, replicated folders, connections, or replication group members.
For a list of scalability guidelines that have been tested by Microsoft for Windows Server 2003 R2, see
(/fwlink/?LinkId=75043).
Do not use DFS Replication in an environment where multiple users update or modify the same files simultaneously on different servers. Doing so can cause DFS Replication to move conflicting copies of the files to the hidden DfsrPrivate\ConflictandDeleted folder.
When multiple users need to modify the same files at the same time on different servers, use the file check-out feature of Windows SharePoint Services to ensure that only one user is working on a file. Windows SharePoint Services 2.0 with Service Pack 2 is available as part of Windows Server 2003 R2. Windows SharePoint Services can be downloaded from the Microsoft W it is not included in newer versions of Windows Server.
DFS Replication uses new objects in the domain-naming context of Active Directory Domain Services to store configuration information. These objects are created when you update the Active Directory Domain Services schema. For more information, see
(/fwlink/?LinkId=182264).
Yes. There are three ways to automate health reports:
Use the DFSR Windows PowerShell module included in Windows Server 2012 R2 or DfsrAdmin.exe in conjunction with Scheduled Tasks to regularly generate health reports. For more information, see
(/fwlink/?LinkId=74010).
Use the DFS Replication Management Pack for System Center Operations Manager to create alerts that are based on specified conditions.
Use the DFS Replication WMI provider to script alerts.
Yes. For more information, see the
in the Microsoft Download Center (/fwlink/?LinkId=182265).
Yes. DFS Replication supports remote management using the DFS Management console and the Add Replication Group command. For example, on server A, you can connect to a replication group defined in the forest with servers A and B as members.
DFS Management is included with Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 R2. To manage DFS Replication from other versions of Windows, use Remote Desktop or the .
To view or manage replication groups that contain read-only replicated folders or members that are failover clusters, you must use the version of DFS Management that is included with Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, the , or the .
No. DFS Replication has its own set of monitoring and diagnostics tools. Ultrasound and Sonar are only capable of monitoring FRS.
To recover lost files, restore the files from the file system folder or shared folder using File History, the Restore previous versions command in File Explorer, or by restoring the files from backup. To recover files directly from the ConflictAndDeleted or PreExisting folder, use the Get-DfsrPreservedFiles and Restore-DfsrPreservedFiles Windows PowerShell cmdlets (included with the DFSR module in Windows Server 2012 R2), or the
sample script from the MSDN Code Gallery. This script is intended only for disaster recovery and is provided AS-IS, without warranty.
Yes. There are a number of ways to monitor replication:
DFS Replication has a management pack for System Center Operations Manager
that provides proactive monitoring.
DFS Management has an in-box diagnostic report for the replication backlog, replication efficiency, and the number of files and folders in a given replication group.
The DFSR Windows PowerShell module in Windows Server 2012 R2 contains cmdlets for starting propagation tests and writing propagation and health reports. For more information, see .
Dfsrdiag.exe is a command-line tool that can generate a backlog count or trigger a propagation test. Both show the state of replication. Propagation shows you if files are being replicated to all nodes. Backlog shows you how many files still need to replicate before two computers are in sync. The backlog count is the number of updates that a replication group member has not processed. On computers running Windows Server 2012 R2, Windows Server 2012 or Windows Server 2008 R2, Dfsrdiag.exe can also display the updates that DFS Replication is currently replicating.
Scripts can use WMI to collect backlog information—manually or through MOM.
Although DFS Replication will work at dial-up speeds, it can get backlogged if there are large numbers of changes to replicate. If small changes are made to existing files, DFS Replication with Remote Differential Compression (RDC) will provide a much higher performance than copying the file directly.
No. DFS Replication does not perform bandwidth sensing. You can configure DFS Replication to use a limited amount of bandwidth on a per-connection basis (bandwidth throttling). However, DFS Replication does not further reduce bandwidth utilization if the network interface becomes saturated, and DFS Replication can saturate the link for short periods. Bandwidth throttling with DFS Replication is not completely accurate because DFS Replication throttles bandwidth by throttling RPC calls. As a result, various buffers in lower levels of the network stack (including RPC) may interfere, causing bursts of network traffic.
If you configure bandwidth throttling when specifying the schedule, all connections for that replication group will use that setting for bandwidth throttling. Bandwidth throttling can be also set as a connection-level setting using DFS Management.
No. DFS Replication uses the topology defined by the administrator, which is independent of Active Directory Domain Services site costing.
To learn about different methods of tuning replication performance, see
In DFS Replication you set the maximum bandwidth you want to use on a connection, and the service maintains that level of network usage. This is different from the Background Intelligent Transfer Service (BITS), and DFS Replication does not saturate the connection if you set it appropriately.
Nonetheless, the bandwidth throttling is not 100% accurate and DFS Replication can saturate the link for short periods of time. This is because DFS Replication throttles bandwidth by throttling RPC calls. Because this process relies on various buffers in lower levels of the network stack, including RPC, the replication traffic tends to travel in bursts which may at times saturate the network links.
DFS Replication in Windows Server 2008 includes several performance enhancements, as discussed in the
topic in .
DFS Replication is much faster than FRS, particularly when small changes are made to large files and RDC is enabled. For example, with RDC, a small change to a 2 MB PowerPoint(R) presentation can result in only 60 kilobytes (KB) being sent across the network—a 97 percent savings in bytes transferred.
RDC is not used on files smaller than 64 KB and might not be beneficial on high-speed LANs where network bandwidth is not contended. RDC can be disabled on a per-connection basis using DFS Management.
Data replicates according to the schedule you set. For example, you can set the schedule to 15-minute intervals, seven days a week. During these intervals, replication is enabled. Replication starts soon after a file change is detected (generally within seconds).
The replication group schedule may be set to Universal Time Coordinate (UTC) while the connection schedule is set to the local time of the receiving member. Take this into account when the replication group spans multiple time zones. Local time means the time of the member hosting the inbound connection. The displayed schedule of the inbound connection and the corresponding outbound connection reflect time zone differences when the schedule is set to local time.
The disk, memory, and CPU resources used by DFS Replication depend on a number of factors, including the number and size of the files, rate of change, number of replication group members, and number of replicated folders. In addition, some resources are harder to estimate. For example, the Extensible Storage Engine (ESE) technology used for the DFS Replication database can consume a large percentage of available memory, which it releases on demand. Applications other than DFS Replication can be hosted on the same server depending on the server configuration. However, when hosting multiple applications or server roles on a single server, it is important that you test this configuration before implementing it in a production environment.
If the connection goes down, DFS Replication will keep trying to replicate while the schedule is open. There will also be connectivity errors noted in the DFS Replication event log that can be harvested using MOM (proactively through alerts) and the DFS Replication Health Report (reactively, such as when an administrator runs it).
Yes. Changed portions of files are compressed before being sent for all file types except the following (which are already compressed): .wma, .wmv, .zip, .jpg, .mpg, .mpeg, .m1v, .mp2, .mp3, .mpa, .cab, .wav, .snd, .au, .asf, .wm, .avi, .z, .gz, .tgz, and .frx. Compression settings for these file types are not configurable in Windows Server 2003 R2.
Yes. You can turn off RDC through the property page of a given connection. Disabling RDC can reduce CPU utilization and replication latency on fast local area network (LAN) links that have no bandwidth constraints or for replication groups that consist primarily of files smaller than 64 KB. If you choose to disable RDC on a connection, test the replication efficiency before and after the change to verify that you have improved replication performance.
You can change the RDC size threshold by using the Dfsradmin Connection Set command, the DFS Replication WMI Provider, or by manually editing the configuration XML file.
Yes. RDC computes differences at the block level irrespective of file data type. However, RDC works more efficiently on certain file types such as Word docs, PST files, and VHD images.
DFS Replication uses RDC, which computes the blocks in the file that have changed and sends only those blocks over the network. DFS Replication does not need to know anything about the contents of the file—only which blocks have changed.
The Standard Editions of Windows Server do not support cross-file RDC. However, it is automatically enabled when you upgrade to an edition that supports cross-file RDC, or if a member of the replication connection is running a supported edition. For a list of editions that support cross-file RDC, see
No. RDC is a general purpose protocol for compressing file transfer. DFS Replication uses RDC on blocks at the file level, not at the disk block level. RDC divides a file into blocks. For each block in a file, it calculates a signature, which is a small number of bytes that can represent the larger block. The set of signatures is transferred from server to client. The client compares the server signatures to its own. The client then requests the server send only the data for signatures that are not already on the client.
DFS Replication renames the file on all other members of the replication group during the next replication. Files are tracked using a unique ID, so renaming a file and moving the file within the replica has no effect on the ability of DFS Replication to replicate a file.
Cross-file RDC allows DFS Replication to use RDC even when a file with the same name does not exist at the client end. Cross-file RDC uses a heuristic to determine files that are similar to the file that needs to be replicated, and uses blocks of the similar files that are identical to the replicating file to minimize the amount of data transferred over the WAN. Cross-file RDC can use blocks of up to five similar files in this process.
To use cross-file RDC, one member of the replication connection must be running an edition of Windows that supports cross-file RDC. For a list of editions that support cross-file RDC, see
Remote differential compression (RDC) is a client-server protocol that can be used to efficiently update files over a limited-bandwidth network. RDC detects insertions, removals, and rearrangements of data in files, enabling DFS Replication to replicate only the changes when files are updated. RDC is used only for files that are 64 KB or larger by default. RDC can use an older version of a file with the same name in the replicated folder or in the DfsrPrivate\ConflictandDeleted folder (located under the local path of the replicated folder).
RDC is used when the file exceeds a minimum size threshold. This size threshold is 64 KB by default. After a file exceeding that threshold has been replicated, updated versions of the file always use RDC, unless a large portion of the file is changed or RDC is disabled.
To use cross-file RDC, one member of the replication connection must be running an edition of the Windows operating system that supports cross-file RDC. The following table shows which editions of the Windows operating system support cross-file RDC.
Operating System Version
Standard Edition
Enterprise Edition
Datacenter Edition
Windows Server 2012 R2
Not available
Windows Server 2012
Not available
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003 R2
* You can optionally disable cross-file RDC on Windows Server 2012 R2.
No. If you need to change the path of a replicated folder, you must delete it in DFS Management and add it back as a new replicated folder. DFS Replication then uses Remote Differential Compression (RDC) to perform a synchronization that determines whether the data is the same on the sending and receiving members. It does not replicate all the data in the folder again.
No, you cannot configure which file attributes that DFS Replication replicates.
For a list of attribute values and their descriptions, see
on MSDN (/fwlink/?LinkId=182268).
The following attribute values are set by using the SetFileAttributes dwFileAttributes function, and they are replicated by DFS Replication. Changes to these attribute values trigger replication of the attributes. The contents of the file are not replicated unless the contents change as well. For more information, see
in the MSDN library (/fwlink/?LinkId=182269).
FILE_ATTRIBUTE_HIDDEN
FILE_ATTRIBUTE_READONLY
FILE_ATTRIBUTE_SYSTEM
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED
FILE_ATTRIBUTE_OFFLINE
The following attribute values are replicated by DFS Replication, but they do not trigger replication.
FILE_ATTRIBUTE_ARCHIVE
FILE_ATTRIBUTE_NORMAL
The following file attribute values also trigger replication, although they cannot be set by using the SetFileAttributes function (use the GetFileAttributes function to view the attribute values).
FILE_ATTRIBUTE_REPARSE_POINTNote
DFS Replication does not replicate reparse point attribute values unless the reparse tag is IO_REPARSE_TAG_SYMLINK. Files with the IO_REPARSE_TAG_DEDUP, IO_REPARSE_TAG_SIS or IO_REPARSE_TAG_HSM reparse tags are replicated as normal files. However, the reparse tag and reparse data buffers are not replicated to other servers because the reparse point only works on the local system.
FILE_ATTRIBUTE_COMPRESSED
FILE_ATTRIBUTE_ENCRYPTEDNote
DFS Replication does not replicate files that are encrypted by using the Encrypting File System (EFS). DFS Replication does replicate files that are encrypted by using non-Microsoft software, but only if it does not set the FILE_ATTRIBUTE_ENCRYPTED attribute value on the file.
FILE_ATTRIBUTE_SPARSE_FILE
FILE_ATTRIBUTE_DIRECTORY
DFS Replication does not replicate the FILE_ATTRIBUTE_TEMPORARY value.
Yes. You can choose a topology when you create a replication group. Or you can select No topology and manually configure connections after the replication group has been created.
Yes. DFS Replication supports copying files to a replication group member before the initial replication. This "prestaging" can dramatically reduce the amount of data replicated during the initial replication.
The initial replication does not need to replicate contents when files differ only by real attributes or time stamps. A real attribute is an attribute that can be set by the Win32 function SetFileAttributes. For more information, see
in the MSDN library (/fwlink/?LinkId=182269). If two files differ by other attributes, such as compression, then the contents of the file are replicated.
To prestage a replication group member, copy the files to the appropriate folder on the destination server(s), create the replication group, and then choose a primary member. Choose the member that has the most up-to-date files that you want to replicate because the primary member's content is considered "authoritative." This means that during initial replication, the primary member's files will always overwrite other versions of the files on other members of the replication group.
For information about pre-seeding and cloning the DFSR database, see .
For more information about the initial replication, see .
Yes. DFS Replication overcomes three common FRS issues:
Journal wraps: DFS Replication recovers from journal wraps on the fly. Each existing file or folder will be marked as journalWrap and verified against the file system before replication is enabled again. During the recovery, this volume is not available for replication in either direction.
Excessive replication: To prevent excessive replication, DFS Replication uses a system of credits.
Morphed folders: To prevent morphed folder names, DFS Replication stores conflicting data in a hidden DfsrPrivate\ConflictandDeleted folder (located under the local path of the replicated folder). For example, creating multiple folders simultaneously with identical names on different servers replicated using FRS causes FRS to rename the older folder(s). DFS Replication instead moves the older folder(s) to the local Conflict and Deleted folder.
No. Files may be replicated out of order.
If an application opens a file and creates a file lock on it (preventing it from being used by other applications while it is open), DFS Replication will not replicate the file until it is closed. If the application opens the file with read-share access, the file can still be replicated.
DFS Replication replicates NTFS file permissions and alternate data streams.
Microsoft does not support creating NTFS hard links to or from files in a replicated folder – doing so can cause replication issues with the affected files. Hard link files are ignored by DFS Replication and are not replicated. Junction points also are not replicated, and DFS Replication logs event 4406 for each junction point it encounters.
The only reparse points replicated by DFS Replication are those that use the IO_REPARSE_TAG_SYMLINK however, DFS Replication does not guarantee that the target of a symlink is also replicated. For more information, see the .
Files with the IO_REPARSE_TAG_DEDUP, IO_REPARSE_TAG_SIS, or IO_REPARSE_TAG_HSM reparse tags are replicated as normal files. The reparse tag and reparse data buffers are not replicated to other servers because the reparse point only works on the local system. As such, DFS Replication can replicate folders on volumes that use Data Deduplication in Windows Server 2012, or Single Instance Storage (SIS), however, data deduplication information is maintained separately by each server on which the role service is enabled.
No, DFS Replication does not replicate files for which the only change is a change to the timestamp. Additionally, the changed timestamp is not replicated to other members of the replication group unless other changes are made to the file.
Yes. DFS Replication replicates permission changes for files and folders. Only the part of the file associated with the Access Control List (ACL) is replicated, although DFS Replication must still read the entire file into the staging area.
Changing ACLs on a large number of files can have an impact on replication performance. However, when using RDC, the amount of data transferred is proportionate to the size of the ACLs, not the size of the entire file. The amount of disk traffic is still proportional to the size of the files because the files must be read to and from the staging folder.
DFS Replication does not merge files when there is a conflict. However, it does attempt to preserve the older version of the file in the hidden DfsrPrivate\ConflictandDeleted folder on the computer where the conflict was detected.
Yes. DFS Replication uses Remote Procedure Call (RPC) connections with encryption.
No. The DFS Replication service uses remote procedure calls (RPC) over TCP to replicate data. To secure data transfers across the Internet, the DFS Replication service is designed to always use the authentication-level constant, RPC_C_AUTHN_LEVEL_PKT_PRIVACY. This ensures that the RPC communication across the Internet is always encrypted. Therefore, it is not possible to disable the use of encrypted RPC by the DFS Replication service.
For more information, see the following Microsoft Web sites:
There is one update manager per replicated folder. Update managers work independently of one another.
By default, a maximum of 16 (four in Windows Server 2003 R2) concurrent downloads are shared among all connections and replication groups. Because connections and replication group updates are not serialized, there is no specific order in which updates are received. If two schedules are opened, updates are generally received and installed from both connections at the same time.
You can force replication immediately by using DFS Management, as described in . You can also force replication by using the Sync-DfsReplicationGroup cmdlet, included in the DFSR PowerShell module introduced with Windows Server 2012 R2, or the Dfsrdiag SyncNow command. You can force polling by using the Update-DfsrConfigurationFromAD cmdlet, or the Dfsrdiag PollAD command.
No. If the schedule is open, DFS Replication will replicate changes as it notices them. There is no way to configure a quiet time for files.
Yes. If you are using Windows Server 2012 or Windows Server 2008 R2, you can create a read-only replicated folder that replicates content through a one-way connection. For more information, see
(/fwlink/?LinkId=156740).
We do not support creating a one-way replication connection with DFS Replication in Windows Server 2008 or Windows Server 2003 R2. Doing so can cause numerous problems including health-check topology errors, staging issues, and problems with the DFS Replication database.
If you are using Windows Server 2008 or Windows Server 2003 R2, you can simulate a one-way connection by performing the following actions:
Train administrators to make changes only on the server(s) that you want to designate as primary servers. Then let the changes replicate to the destination servers.
Configure the share permissions on the destination servers so that end users do not have Write permissions. If no changes are allowed on the branch servers, then there is nothing to replicate back, simulating a one-way connection and keeping WAN utilization low.
No. If DFS Replication considers the files identical, it will not replicate them. If changed files have not been replicated, DFS Replication will automatically replicate them when configured to do so. To overwrite the configured schedule, use the WMI method ForceReplicate(). However, this is only a schedule override, and it does not force replication of unchanged or identical files.
During initial replication, the primary member's files will always take precedence in the conflict resolution that occurs if the receiving members have different versions of files on the primary member. The primary member designation is stored in Active Directory Domain Services, and the designation is cleared after the primary member is ready to replicate, but before all members of the replication group replicate.
If the initial replication fails or the DFS Replication service restarts during the replication, the primary member sees the primary member designation in the local DFS Replication database and retries the initial replication. If the primary member's DFS Replication database is lost after clearing the primary designation in Active Directory Domain Services, but before all members of the replication group complete the initial replication, all members of the replication group fail to replicate the folder because no server is designated as the primary member. If this happens, use the Dfsradmin membership /set /isprimary:true command on the primary member server to restore the primary member designation manually.
For more information about initial replication, see .
The primary member designation is used only during the initial replication process. If you use the Dfsradmin command to specify a primary member for a replicated folder after replication is complete, DFS Replication does not designate the server as a primary member in Active Directory Domain Services. However, if the DFS Replication database on the server subsequently suffers irreversible corruption or data loss, the server attempts to perform an initial replication as the primary member instead of recovering its data from another member of the replication group. Essentially, the server becomes a rogue primary server, which can cause conflicts. For this reason, specify the primary member manually only if you are certain that the initial replication has irretrievably failed.
If remote differential compression (RDC) is enabled on the connection, inbound replication of a file larger than 64 KB that began replicating immediately prior to the schedule closing (or changing to No bandwidth) continues when the schedule opens (or changes to something other than No bandwidth). The replication continues from the state it was in when replication stopped.
If RDC is turned off, DFS Replication completely restarts the file transfer. This can delay when the file is available on the receiving member.
When DFS Replication detects a conflict, it uses the version of the file that was saved last. It moves the other file into the DfsrPrivate\ConflictandDeleted folder (under the local path of the replicated folder on the computer that resolved the conflict). It remains there until Conflict and Deleted folder cleanup, which occurs when the Conflict and Deleted folder exceeds the configured size or DFS Replication encounters an Out of disk space error. The Conflict and Deleted folder is not replicated, and this method of conflict resolution avoids the problem of morphed directories that was possible in FRS.
When a conflict occurs, DFS Replication logs an informational event to the DFS Replication event log. This event does not require user action for the following reasons:
It is not visible to users (it is visible only to server administrators).
DFS Replication treats the Conflict and Deleted folder as a cache. When a quota threshold is reached, it cleans out some of those files. There is no guarantee that conflicting files will be saved.
The conflict could reside on a server different from the origin of the conflict.
No. DFS Replication does not continue to stage files outside of scheduled replication times, if the bandwidth throttling quota has been exceeded, or when connections are disabled.
No. DFS Replication opens files in a way that does not block users or applications from opening files in the replication folder. This method is known as "opportunistic locking."
Yes. The staging folder location is configured on the Advanced tab of the Properties dialog box for each member of a replication group.
Files are staged on the sending member when the receiving member requests the file (unless the file is 64 KB or smaller) as shown in the following table. If Remote Differential Compression (RDC) is disabled on the connection, the file is staged unless it is 256 KB or smaller. Files are also staged on the receiving member as they are transferred if they are less than 64 KB in size, although you can configure this setting between 16 KB and 1 MB. If the schedule is closed, files are not staged.
RDC enabled
RDC disabled
Sending member
Receiving member
64 KB by default
64 KB by default
If any part of the file is already being transmitted, DFS Replication continues the transmission. If the file is changed before DFS Replication begins transmitting the file, then the newer version of the file is sent.
Description
October 9th, 2013
Updated the
section with results from tests on Windows Server 2012 R2.
Updates for the latest version of Windows Server
January 30th, 2013
Customer questions
October 31st, 2012
Edited the
entry to increase the tested number of replicated files on a volume.
Customer feedback
August 15, 2012
Edited the
entry to further clarify how DFS Replication handles hard links and reparse points.
Feedback from Customer Support Services
June 13, 2012
Edited the
entry to add discussion of ReFS.
Customer feedback
April 25, 2012
Edited the
entry to clarify how DFS Replication handles hard links.
Reduce potential confusion
March 30, 2011
Edited the
entry to correct the potential impact of using DFS Replication with .pst and Access files.
Customer questions about the previous entry, which incorrectly indicated that replicating .pst or Access files could corrupt the DFS Replication database.
January 26, 2011
Customer feedback
October 20, 2010
Customer feedback
Was this page helpful?
Additional feedback?
1500 characters remaining
Thank you!
We appreciate your feedback.
Did the page load quickly?
Do you like the page design?
Tell us more