我们当前的设置使用两台 DFS 服务器作为我们 DFS 命名空间的引用服务器。数据从实时服务器复制到我们第二个位置的 DR 服务器。目的是让第二台服务器始终处于实时引用状态，但文件夹目标仅适用于实时站点。
在正常情况下，如果没有任何问题，这一切都会正常工作，我们遇到的问题是，在测试两个办公室之间的链接时，命名空间变得不可用，我们无法创建新的命名空间。在此事件期间运行诊断程序后，发现 DFS 命名空间需要访问主域控制器才能与命名空间交互。因此，现在在“链接关闭”测试期间，我们将 FSMO 角色转移到 DR 域控制器，以便可以访问 PDC。现在，我们能够创建新的命名空间，但仍然无法与当前命名空间交互。
我们进行了活动目录健康测试、升级到 2012 R2 域并全面清理和重建 DFS 系统，并且每当链接断开时，即使 PDC 可用，DFS 也会抱怨它无法再看到域或命名空间。
我现在完全没有主意了，所以如果有人有这方面的经验并且可以提供测试建议的话。当前的解决方案是，在这种情况下，我们基本上不能使用 DFS 命名空间，而是必须运行脚本将漫游配置文件的路径和文件夹重定向移动到 DR 服务器，而不仅仅是移动 DFS 上的文件夹引用，这似乎不应该是这种情况，必须有一种方法始终能够使用命名空间。
设置：
AD 域 - Windows 2012 R2。2 个 DC 处于实时状态，2 个 DC 处于 DR 状态。
实时 DFS 服务器 - Windows 2012 R2。已启用引荐服务器，已启用文件夹目标。已启用命名空间服务器。DR DFS 服务器 - Windows 2012
R2。已启用引荐服务器，已禁用文件夹目标。已启用命名空间服务器。
数据复制方法 - Bvckup2。
我们在用户主驱动器中使用漫游配置文件和文件夹重定向。
答案1
我已经弄清楚了这个问题，这一切都源于 DFS 命名空间环境的默认设置。
我们正在使用仅 DNS 环境，因此需要将 DFS 命名空间重新创建为仅 DNS 并接受 FQDN 引用，主要遵循本文：
https://support.microsoft.com/en-us/kb/244380
我过去曾计划这样做，但发现由于当时正在进行其他工作，风险相对较高，而且对我们的环境影响不大，直到我们发现 PDC 这个特定的特殊情况变得不可用（即使进行了 FSMO 角色转移）。
希望这可以帮助处于这种特殊情况的其他人。