我不太熟悉 DFS 的工作原理，而且由于其他人管理相关服务器，我不知道 DFS 设置是什么样子。我只是想知道是否有可能。
基本上，我们将 3 台服务器设置为带有 1 个文件夹的复制组，该文件夹是 IIS 中 .NET webapp 设置的根目录。当我们将更改部署到应用程序时，我们会将更改部署到一台服务器（服务器 #1），并允许 DFS 将更改传播到组中的其他两台服务器。部署后，环境出现很多奇怪的行为，应用程序需要很长时间才能重新启动，但 IIS 日志中没有任何内容表明应用程序池循环是花费很长时间的部分。我想这可能是由于奇怪的 DFS 复制行为造成的，因此我请求管理员向我提供 DFSR 健康报告和传播报告。传播报告表明复制很快，所有内容都在 1 秒内完成。
运行状况报告显示 1 台服务器上出现 1 个错误：由于持续的共享冲突，DFS 复制无法复制上面列出的已复制文件夹中的文件。此问题影响 1 个已复制文件夹中的 114 个文件。事件 ID：4302
MS KB 在此处：http://support.microsoft.com/kb/968429说 4302 事件是由于“接收”文件期间发生的错误，这让我很担心，因为这个错误发生在服务器＃1上，而服务器＃1应该将文件发送到另外两台服务器。
在使另外两台服务器中的一台同步并由于仍在进行向第三台服务器的复制而被拒绝权限后，DFSR 是否可能尝试将文件复制回源服务器？或者我是否可以在日志中查找其他内容，以查看服务器之间的复制实际花费了多长时间，以尝试获取 MSDeploy 结束和应用程序再次可用之间发生的事情的准确时间表？
答案1
如果文件在其他成员服务器之一上发生变化，DFS 可能会复制回源服务器。请记住，即使 DFS 有一个主服务器，该服务器也仅用于将初始副本集复制并分发到其他新成员服务器。之后，文件可以复制回主机。
一个很好的可能性是，存储在 App_Data 目录中的任何日志文件或数据文件都可能同步到复制组中的所有其他服务器。
一般来说，不推荐使用 DFS 来将更新和应用程序更改部署到多个 Web 服务器。您可能需要了解 Microsoft Web Farm Framework，它在管理应用程序文件和其他服务器相关设置的复制和部署方面做得更好。从这个意义上讲，它实际上比 DFS 能做的更多。