我正在configuration一个新的DFS设置，它将利用命名空间和复制。 这两台成员服务器是运行Windows Server 2012 R2的虚拟机。 由于许多份额从几百吉字节到几吉字节，所以我希望将这些份额存储在自己的虚拟磁盘上，而不是为所有份额存储一个大的（10兆兆字节）虚拟磁盘。 我不希望为每个磁盘分配驱动器号，而是希望能够使用联结创build统一的逻辑结构，如下所示，其中每个共享文件夹实际上是指向另一个卷上的文件夹的结点（当然，在每个成员服务器上相应的卷有不同的标识符，路口说明了这一点）： C:\File Shares\ Share1\ === Junction ===> \\?\Volume{11111111-1111-1111-1111-111111111111}\File Shares\Share1\ Share2\ === Junction ===> \\?\Volume{22222222-2222-2222-2222-222222222222}\File Shares\Share2\ Share3\ === Junction ===> \\?\Volume{33333333-3333-3333-3333-333333333333}\File Shares\Share3\ Windows资源pipe理器和命令提示符等应用程序在导航此结构时没有任何问题，并且可以从每个C:\File Shares\ShareX联结中创build共享并无任何问题地访问它们。 然而，DFS-R似乎并不喜欢它。 使用上述连接之一创build复制组之后，事件日志中将生成事件6064： DFS复制服务无法在本地pathC：\ File Shares \ Share1上复制已复制的文件夹，因为本地path不是现有可访问本地文件夹的全限定path名。 我怀疑问题是DFS-R不支持使用联结作为复制文件夹。 DFS复制：常见问题（FAQ）状态“连接点也不复制，并且DFS复制日志事件4406遇到的每个交接点”，但这似乎指的是复制文件夹何时包含交接，而不是一个复制的文件夹是一个连接点。 事实上，如果我将驱动器号分配给上面的卷，那么DFS-R 就可以与这些连接器一起工作： C:\File Shares\ Share1\ === Junction ===> X:\File Shares\Share1\ Share2\ === Junction ===> Y:\File Shares\Share2\ Share3\ […]
我们有在Windows Server 2012R2上运行的SCOM 2012R2的function实现。 最近我已经开始尝试使DFS复制监视工作; 专门积压监测。 但是，似乎只有某些监视器正在发现成功。 有问题的文件服务器也都是Windows Server 2012 R2。 我们的文件服务器已经开始为至less一个DFSRpipe理包中的许多规则/监视器抛出以下事件ID 1102。 每个事件中的规则/监视器名称都以[Microsoft.Windows.Fileserver.DFSR.6.3。]或[Microsoft.Windows.Fileserver.DFSR。]之一开头。 见下文： 规则/监视器“Microsoft.Windows.FileServer.DFSR.BacklogDiscovery”运行例如“DFS-14”与id：“{6E648D77-AD11-AADC-E91B-B7F57FAE74C6}”不能被初始化，将不会被加载。 pipe理组“Tervis” 我已经确保该操作帐户具有pipe理权限，并且每个节点都configuration为代理。 奇怪的是，我发现积压监测通常似乎至less有一次，一个代理重新安装后， 然后再次开始错误。 这通过反映更新指标的“Microsoft Windows DFS复制 – >积压监测”监视器得到证实。 有没有人解决这个问题，否则可以提供一些方向，以确保configuration是正确的？
我一直在这里窥探一下，看起来glusterfs可能是我的问题的答案。 不过，我对这个还是比较陌生的，所以一个理智的检查将非常感激！ 我的设置是在两个不同地点的两个Samba盒子。 两者都将作为两个位置访问共享的文件服务器。 我想到的是某种实时文件镜像到/从位置1和位置2，所以两台机器都会有一组最新的用户文件。 当然，某种写locking也会很好。 两个地点的上游都是可靠的10Mb / s。 从我收集的信息来看，在Windows环境下，DFS-R可能就是我正在寻找的东西。 在Linux世界里，什么是明智的select？ 任何指针不胜感激！ 麦克风
我已经在6个Windows 2012 R2服务器之间设置了DFS-R（Hub和spoke）共享。 所有服务器上的共享被称为“网站$”，为每个人提供“完全访问”权限。 所有服务器都具有高性能4个Xeon-Cores，32 GB RAM，8 GB RAM是免费的，并通过10Gb VMware Connections连接。 Server1被定义为主服务器（集线器） Server2 – Server6是成员服务器（辐条） 原始NTFS权限已正确复制到成员。 我对共享根级别“D：\网站”权限的第一次更改也正确传输到所有子文件夹。 现在我必须更改子文件夹“D：\网站\特别”的权限。 应删除“用户”组，并且本地组“IIS IUSRS”应在此子文件夹中具有读取权限。 所以我阻止inheritance这个文件夹，保留所有权限，删除“用户”组，并添加读取权限的“IIS IUSRS”组。 “D：\网站\特别”中的所有子文件夹都具有相应的权限。 这对成员来说有点奇怪。 在成员服务器上，“D：\ Websites \ Special”上的inheritance也被阻止，“users”组被删除，并添加“IIS IUSRS”。 某些子文件夹的权限configuration正确，但在其他一些子文件夹（例如“D：\ Websites \ Special \ Website1”）上，旧权限处于活动状态，不pipe更改主服务器上的哪些权限。 当我删除文件夹“D：\网站\特殊\ Website1”，并从备份中复制旧的内容一切正常，权限是正确的。 我可以在主服务器上configuration新的权限，并将其复制。 在更改了一些权限之后，该文件夹会再次在成员上损坏，并且不会从主服务器获得新的权限。 所有文件夹中只有less数（<20）小（<20kb）文件。 我不知道这个奇怪的行为的根源是什么。 你有什么线索我做错了什么？
我似乎无法find有关此主题的任何信息。 我们已经build立了一个IIS服务器和WebDav的支持，这似乎是一个很好的解决scheme，但是我们得到一个特定的文件夹性能相当缓慢。 虽然这个文件夹中有大约2600个项目，但是如果我使用net use映射一个驱动器并尝试打开它，则需要很长时间（大约60秒）。 我试过closuresIE中的自动检测设置，这没有帮助。 我不确定在哪里继续解决这个问题。 任何帮助，将不胜感激。 谢谢。 编辑 – 连接到远程服务器上的DFS共享似乎是一个问题，因为我将驱动器连接到IIS服务器，滞后时间相当短。 在IIS中通过命名空间共享连接是否有任何原因会导致这种滞后？
我在两台服务器之间运行了一份关于我的DFS复制的诊断报告，并在我的报告中得到了以下错误： The DFS Replication service stopped replication on volume D:. This failure can occur because the disk is full, the disk is failing, or a quota limit has been reached. Event ID: 2004 事件ID 2004甚至不显示在目标服务器的事件日志中。 我检查了目标服务器上的D:驱动器，它有足够的可用空间; 4TB。 即使是DFS诊断报告显示有足够的空间。 我检查了目标D:驱动器的权限， SYSTEM对驱动器和我试图复制的目录拥有完全权限。 我检查了硬件事件日志，并没有错误。 我错过了什么吗？ 当复制服务认为目标磁盘已满时，如何解决DFS复制问题，但实际上不是？
我的一台服务器最近重新启动，CHKDSK运行。 当我在其上运行DFS诊断报告时，DFS环境显示重新启动的服务器现在处于“自动恢复”状态。 但是，现在已经有48个小时了。 我知道这可能需要一些时间，因为复制组中的文件夹有数千个文件，而且它们相对较大，但48小时似乎相当长。 我已经阅读了几篇有关DFS在“脏”关机后启动的文章，但是在我的服务器中没有错误2213或2004。 此外，此registry项HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery已被设置为0 有什么方法可以看到发生了什么？ 有没有一种方法可以提高自动恢复状态的性能？ 有没有办法让我确定自动恢复状态是否正在做任何事情？
我们有11台运行2012 R2的服务器，configuration了Active Directory，并使用DFS-R将漫游configuration文件和常规数据同步到VPN上的“共享”文件夹中。 所有的服务器都运行完美 – 除了一个。 它同步sysvol和用户configuration文件正确，但“共享”文件夹内的内容不是。 服务器以前工作，但它开始玩（根本没有同步文件夹），我试图删除和重新创buildDFSRconfiguration，但无法让它再次工作，所以我决定重新加载它。 由于重新加载服务器只能同步一个文件夹。 例如，我们已经得到了文件夹A，B，C，D，E，F，G，而且它只能同步文件夹“F”中的数据。 我尝试从DFS-R中删除它，并等待4010事件，删除“共享”文件夹和重新创build的一切，但它只是同步“F”内的数据。 我也尝试在违规的服务器上创build空文本文件，然后在另一台服务器上的另一个文本文件上查看是否同步，但不是。 我已检查文件夹的权限，以确保系统具有完全访问文件夹（它所做的）.. 我猜测它与DFSR数据库有关，但是我猜测你不能仅仅删除一个成员的信息呢？ 有什么build议么？
Dcdiag /e /test:sysvolcheck /test:advertising repadmin /replsum repadmin /showrepl repadmin /bridgeheads dcdiag /v 我find了一个从FRS转换到DFSR的指南，因为它更高效。 该指南会要求您确保您的域正在有效地复制。 我运行了所有这些命令，但在Dcdiag /e /test:sysvolcheck /test:advertising命令我得到了以下结果： Doing primary tests Testing server: LSITE\LAD001 Starting test: Advertising ……………………. LAD001 passed test Advertising Starting test: SysVolCheck ……………………. LAD001 failed test SysVolCheck Testing server: Default-First-Site-Name\C1AD001 Starting test: Advertising ……………………. C1AD001 passed test Advertising Starting test: SysVolCheck ……………………. […]
一个DFS-R有两台服务器。 ServerA在一个位置，ServerB在另一个位置 自从昨天上午以来，我们处于一个不知如何摆脱这种状况的情况。 情况： 我们收到一个呼叫，人们无法再访问特定的DFS命名空间。 检查一下，我们发现，在ServerA上，有人首先删除这个文件夹上的共享，并且没有更多的ACL在那里。 第一步，在DFS命名空间中，我们禁用了ServerA上的Folder目标。 允许用户访问他们的文件。 复制看起来非常缓慢。 drfsdiag backlog在复制的两边都提供了101000+和78000+个文件。 可能是由于ACL不匹配我猜。 回到这种情况的最好方法是什么？ 停止ServerA到ServerB的复制？ 删除ServerA上的文件夹？ 用ServerB作为主要来源重新创build复制？ 重新创buildACL并在ServerA上共享？ 所有这些步骤都按特定的顺序？ 等待积压已经结束，然后移动？ 真的是新的DFS-R，我们不知道如何进行，所有可能的影响。 任何线索将不胜感激。