我们有一个小存根办公室，目前有一个单一的服务器2003域控制器，并在我们的主要办公室举行的文件存储的DFS-R副本。 我们大概可以复制大约100Gb的数据，我猜想最大的20Gb在两端都是积极使用的。 我们有（相对）缓慢的站点之间的ADSL链接。
对于我们来说，复制大多对我们非常有效，除了在一些复制文件上对安全性进行更改的情况。 – 这导致了大量积压的变化，似乎需要几天时间才能清除。 我一直在阅读一些关于问题的文章 ，以及Windows 7和Server 2008 R2必须提供的新分支cachingfunction，据我了解，优点和缺点如下：
分支caching
优点
缺点
DFSR
优点
缺点
有没有人testing过分支caching？ 我想知道如果分支caching如何在现实世界中执行？ 对于我们的设置，它会比DFSR更好吗？ 我可以想象，如果我能够预取大块数据（我想我可以用robocopy手动执行并删除！），这可能会非常有用。 我唯一担心的是数据写入会很慢。
我也一直在考虑在我们的主要办公室实施共享点。 我认为这可能只是支持分支caching。
很显然，如果我决定使用分支caching，那么就必须通过testing，但是我只是想知道是否有其他可能会说服我的优点或缺点。
我可能会保留我们的AD部署软件作为DFS-R复制，甚至可能是用户特定的数据（如主页目录和configuration文件），否则写入肯定会导致客户端延迟？
这听起来像BranchCache可能很适合你，虽然你可能也受益于在Server 2008和Server 2008 R2中进行的DFS-R的一些性能改进。
已经有一些关于BranchCache的案例研究可以告诉你更多关于现实世界中BranchCache性能的信息。 只要search“BranchCache案例研究”。
BranchCache小心地始终遵守任何内容（文件，网页…）上最新的访问控制设置。 在客户端PC可以从分支机构的caching（无论是托pipecaching服务器还是对端）下载数据之前，必须从主办公室服务器获取内容标识符。 如果客户端没有权限访问数据，则主办公室服务器将不会发送标识符。 有一堆文件解释了在branchcache.com上的工作原理。
如果需要，可以通过让分支中的一个客户端（或实际的托pipecaching服务器）提前访问数据来预加载BranchCachecaching。 在某些情况下，如果要在工作人员进入之前预先加载caching，则这可能是脚本化的。
如果您打算在分支机构中保留一台服务器，并且要升级到R2，那么没有理由不能部署BranchCache和DFS-R的组合。 一个盒子可以同时充当DFS-R复制点和托pipecaching服务器。 您可以通过这种方式获得SharePoint和SMB优化，通过在两种技术之间传播数据，您可以获得各类数据的最佳属性。
我希望这有帮助！ -Tyler