背景描述：
上午在做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日星期日