我计划设置一个 DFS 根目录来存放我们所有部门的共享，我还计划拥有通过 AD 配置文件自动挂载的主目录。我们将使用 NetApp 进行存储。我应该将主目录作为 DFS 的一部分吗？还是将它们放在 NetApp 的单独分区/卷上更有意义？
答案1
我不会这么做。我使用 DFSN（DFS 命名空间）的两个主要原因不适用于主文件夹：使用 DFSR 复制文件夹并让 AD 找出最近的副本，其次，如果您希望用户无论在哪个文件服务器上都能拥有一致的文件路径。我喜欢 DFS 并将其用于许多客户端/作业，但我认为将其用于主目录的优势不大（也许有一些缺点）。以下是一些想法（无特定顺序）：
- 不要使用 AD 配置文件路径设置。它们完全是 NT 遗留设置，已被 GPO 文件夹重定向取代。当您设置 AD 配置文件路径时，它实际上会将计算机设置为使用该网络路径作为各种事物的默认位置，这会减慢从登录到启动 Word 的所有操作。只需保留该选项卡并学会喜欢 GPO 文件夹重定向，它能做更多事情，并且更易于管理人群。这一点再怎么强调也不为过。微软应该警告管理员该选项卡可能导致的问题。
- 在 XP 中，我记得如果是 DFSN，文件夹重定向会出现问题。在 XP/2003 时代，我们必须将用户文件夹重定向设置为 //server/share 路径。其他所有东西的 DFSN 仍然运行良好。
- 您应该很少让用户浏览彼此的主文件夹。通常规则是，如果多个用户需要访问权限，则它不会进入用户主文件夹，而是属于 DFSN 中的其他地方。您可能在 GPO 中设置文件夹重定向，因此如果您移动这些用户主文件夹，您将在 GPO 中更改它，并且不需要 DFSN 链接的优势。
- 仅供参考，如果您有任何 Mac 用户，任何早于 Lion 10.7 的版本都无法很好地执行 DFS，或者根本无法执行。
- 请注意，如果您使用 NetApp 作为 DFSN 的 NAS，则无法使用它进行 DFSR（上次我在 2009 年使用 7.0 时使用过它）。您需要使用 Windows Server 作为 NetApp 的前端，并使用 iSCSI 来存储文件。
- 就我个人而言，如果你的客户端几乎都是 Windows 客户端（Vista 或更新版本），那么除了 Windows 操作系统之外，我已经放弃了任何文件共享。SMB 2.0，然后是 2.1，以及现在 3.0使 Windows 客户端和服务器之间的文件共享速度更快、功能更丰富，在我看来，所有其他供应商都在追赶微软。如果整个行业能够共同前进，那就太好了，但现实是，即使是 NetApp 也在这个协议上落后微软好几年。如果您需要企业始终在线的文件共享，请在 NetApp iSCSI 前面使用文件服务器集群。