背景描述：
上午在做Branchcache的站点域的托管式缓存，由于是之前的环境快照过来的，在做的时候遇到了一个错误，
不解决的话无法进行下去，故整理一下分享出来！
实验拓扑
故障描述：
在总部DC上做了策略后，在分支结构的客户端上刷新组策略却报错如图：
由于分支客户端并没有更新到总部下发的组策略，所以我们的Branchcache的实验也就无法在进行下去，我们就来谈谈如何排错吧！
Setup
根据报错，他给出了三个可能的原因：
到当前域控制器的名称解析/网络连接
由于是分支机构的客户端，那么首选我们进行第一步的排错，根据拓扑图他们进行解析分支机构的DC，结果完全没有问题
文件复制服务延迟（在另一域控制器上创建的文件尚未复制到当前域控制器）
由于我们的环境是单域多站点，对于这种现象还是有很大可能的，由于是组策略没有办法应用，我们都知道组策略是存在于sysvol理面的。于是通过在客户端上分别访问DC和File的sysvol共享，结果可以确定在DC上下发的组策略，并没有复制到分支机构File这台DC上，问题基本上可以确定到这里
注意：下图是我已经解决的截图，当时并没有截图，在没有解决之前就像这样一样，File比DC的文件少了三个文件夹！
分布式文件系统（DFS）客户端已被禁用：客户端不存在这个，就不用检查了，等下我们来检查服务器上的DFS功能
根据现有的错误提示，我们基本上锁定到了File的复制问题，那么登陆File来排错！Windows有问题，我们首先想到的就是日志了，迅速的打开日志，开始一个一个的去排查，发现了一下2个报错，从这2个图中可以看出，都有错误来源和错误ID，如果你很熟悉的话，可以直接进行故障的解决，但如果不熟悉的话，还是建议到technet上去看下来源和ID所代表的问题和解决方案：http://technet.microsoft.com/en-us/library/cc727259(v=ws.10).aspx
根据官方的解释和方案，发现并不适用我现在的环境，故没有根据他所提供的方法进行排错！那么我们接下来怎么办呢？有人说GG或BD搜索呗，这也不失为一个方法，但切记，所搜索出来的结果，是专门针对的其他提问的人的环境，可能并不适用你的环境，所以在搜索后根据其环境以及答案，自己要好好的考量一下他们的方案如果在你的环境中操作的话会有多大的影响，一定要在心里有一个谱，看到很多IT人，随便找到一个结果，就跟着他的结果进行操作，到头来发现问题没解决反而更严重了！这就是典型的手欠，严重的话会让够你喝一壶的！
一般情况下，搜索应该是放到你确定了哪里出问题了但不知道如何解决的时候才用，比如DFS无法启动造成复制无法进行，但手动也启动不了DFS服务，这个时候去搜索，缩小的问题点，更能针对我们的环境，所以在看完官方的解释后，我们应该进一步的排查，日志看完了，那么我们就该看看服务了
如果你看到这个图，你会如何想？
没错，你想的是正确的，FRS服务就是负责sysvol复制的，现在FRS服务已经被禁用了，那组策略肯定无法复制了！ 哈哈哈，终于找到原因了，
那么我们就赶紧手动的启用吧
OK，到这里，你该如何？
是否该去利用搜索的强大功能了？一般来说，大多数人都该利用搜索了，但我们要清楚，我们的环境是Windows Server 2012的系统（2008和08R2也一样），并不是2003的系统，如果你仔细的话你应该知道，2008以后开始sysvol的复制已经不是通过FRS这个服务来负责了，而是通过使用DFS服务来复制的：http://technet.microsoft.com/zh-cn/library/cc753479(v=ws.10).aspx
所以FRS服务是被禁用的，但如果你不知道的话，相信你会走很多弯路！那么我们展开dfs服务，并没有问题
在检查了日志，服务，网络都没有问题的情况下，我们的排错开始进入高级阶段，因为表面的排错都已经进行了排除，那么我们开始深入排错，首先复制，我们是有命令来监控的，那么我们登陆DC（有几个dc就登陆几台，都不要放过，尽可能多的搜集情报）可以稍微的看一下
Dcdiag /v >c:\dcdiag.txt
接下来我们打开C盘的dcdiag.txt，会发现这里面有很多的报错信息，而且很清楚的显示了一些帮助文档
从上图中，我们可以发现一些有用的信息，包括报错信息，以及可能的原因，并且给出了一个KB，我们先打开这个KB看下：http://support.microsoft.com/kb/2663685
从下图的KB中可以看到症状，官方所描述的症状和我的环境（直接使用以前的快照恢复的环境）很符合
根据官方提供的方案，在备份了系统之后，我们进行了操作：
1， 备份卷上所有已经复制文件夹中的文件，如果未成功执行操作，则在恢复已复制文件夹期间，可能会因异常冲突解析而导致数据丢失
2， 要恢复此卷的复制，请使用DFSVolueConfig类的WMI方法ResumeReplication
OK通过第一步的操作后，我们进行第二步
打开cmd，输入：wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=”GUID号码” call ResumeReplication
GUID号码可以在dcdiag中找到
执行后的结果如图
完成后，sysvol会自动复制，至于复制完成的时间，我这里是测试环境并且是单域多站点，很迅速的就完成了复制，为了看效果，我们先在总部的DC上新建了一条test策略，然后我们打开File分支机构的DC上的sysvol看下：从图中可以看出，在18：46分2边同时出现了一条组策略文件！
接下来，我们来到客户端进行刷新：可以看出，策略刷新已经没有了问题
至此，我们的排错过程已经完成！
总结：
排错一般是需要一定的理论知识，并且各个知识点需要有一定的连贯性，搜索来的东西可以参考但不能太莽撞
1， 理论知识一定要牢固，要能够足够支撑你100%的断定1+1是=2的，不要那种好像是也好像不是这样2种答案的！因为任何一个排错的解决方案如果有2套，那么终究会有一个套是失败的，如果应用了失败的方案，那结果可想而知！
2， 尽量的对各个知识点进行穿线整合形成一条线可以串起来，不然你永远无法提高，因为各个知识点就是各个单兵作战的士兵，在自己的战场上可能还是拔尖的，一旦跨了战场，由于各个知识点无法有效的串起来组成一个Team，在你进行一个环境排错的时候就没有了一个“团结”的局面，以至于让自己不攻自破！就跟我们的工商，检察，税务一样，个个都是大爷，各自管各自的地方从来不跟对方沟通，没有在统一的战线上，如果他们沟通了站到了统一的战线上，那么那些贪官，黑心的商家还会这么多吗？一有问题，TMD就推来推去的！没有一条线把他们穿起来，他们永远都这样！
3， 微软的系统有一个特点，一般4年更新一次，如果说让你全部搞懂，那也有些困难，但每一个系统的开篇都会介绍他更新了哪些功能，即使你现在不升级，也很有必要认真的去看他所更新了哪些功能，这在你做方案以及后期使用了新版本排错方面都会有很大的帮助！有可能一个小小的更新就会解决你的一个需要二次开发的需求，比如Exchange Server 2010的地址列表的分段需求，在sp1下是达不到的，是需要二次开发，这都是钱啊，但如果你知道sp2里面是支持分段的并且支持个性化的话，那么这个开发成本一下子就没了，降低了IT运维的综合成本！
4， 排错最重要的是思路，不要看到错误就把问题直接丢到群里，论坛上，可以先让自己按照自己的思路去解决，实在解决不了，在问问题之前尽量的描述清楚，特别是所使用的版本，一定要交代清楚！
5， 问题解决后，最好是记录一下，一方面锻炼自己的思维组织能力，会操作会配置但写出来不一定能够让别人看得懂，另一方面给自己一个经验的积累！相信经过长时间的排错总结，你的经验会慢慢的积累起来的！
附录：
如何把知识点串起来，我在这里稍微的做一些介绍，只是个人的方法，可能不适合你，但看看总不是什么坏事
1， 做实验的时候尽量录制视频，这样可以记录你的所有操作，有可能第一次第二次做实验并不成功，在第四次做实验成功了，那么在你做总结的时候可以很容易回顾第一次以及第二次自己是如何做的为什么做错了！
2， 做录制视频的时候尽量的一边操作一边讲解，会配置会操作，但你不一定会讲解，但讲解往往代表的是知识的系统性，连贯性，如果知识点比较零碎，那么你讲解的时候会不知道说什么？说了上句不知道下句该如何去说，可以仔细听自己的录音，看是否经常出现卡壳以及“就是说”这样的现象，特别是“就是说”这句，在初期可能会是你的口头禅，但相信，经过一定时间的积累，你在讲解的时候会摒弃掉“就是说”的！至于为什么是“就是说”这个词？自己现在试着讲解一个技术点，看自己会用几个“就是说”
IT之梦---你---我---他
2013年5月26日星期日
本文转自 IT之梦 51CTO博客，原文链接:http://blog.51cto.com/itmydream/1210603
