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