場景描述：
一朋友公司，遇到這樣一個問題，不管用戶端的DNS是手動指定還是DHCP自動分配，都解析不了，如圖，手動指定的是192.168.1.5，但nslookup的時候卻是192.168.1.88
網絡拓撲：根據朋友的描述，我畫了一個拓撲圖
192.168.1.88 是原來2003的dc地址
192.168.1.5 是08R2的dc地址
由於公司需要，公司從2003的域模式遷移到了08R2上，並確認信息複製沒有問題的情況下，退出了2003的dc並降級刪除！遷移步驟絕對沒有報錯！
然而現在出現的現象就如開頭所看到的，不管是手動還是DHCP自動配置ＤＮＳ，都不能進行解析，他會首先找原來的2003DC作爲解析源
問題分析：
1，問題發生時間：自動2003dc遷移到08R2，並且2003dc降級退出以後，由此我們可以知道大概是在什麼樣的情景下隱患的造成了我們現有的故障
2，問題發生的對象：所有加入域的計算機都這個現象，沒有加入域的計算機一切正常，由此可以知道，問題大概出在服務器端，並且DNS沒有問題，可能是某個全局設置有問題？
3，由以上2點，我們大概已經把目標鎖定到了組策略，因爲只有組策略的設置可以是全局的，可以控制計算機的所有相關設置，爲了驗證這一點，我讓他弄了一臺新電腦在Workgroup一切正常，加入域後就不正常了，這就說明了問題，計算機加入域之後，設置的變化只有組策略能做到！而且是全局策略！
問題解決：
1， 打開服務器的gpmc，查看我們現有的策略，發現存在的全局策略太多，如果一個一個的去看很費時間，那麼我們可以通過2個方法來快速的定位，第一個就是點中其中一個策略，然後在右邊查看設置一欄，一個一個的去看，這個時效性也不是很高！但不失爲一個辦法！
2， 打開一臺客戶端的運行，並收集客戶端所應用的策略，通過對每個策略的檢查，發現在計算機策略—管理模板—網絡—DNS客戶端，已經被啓用，並可以看到GPO的名字是DNS_Client，這個方法效率相對來說高了一點！
3， 定位好了以後，我們就可以到服務器上進行修改，刪除原來2003的設置，並添加爲08R2的設置即可恢復網絡
總結：
從這個事故當中，我們可以看到，就算你記憶力在好，真都不如爛筆頭，不要太高估自己，在IT運維過程中，自己所更改的設置，所操作的步驟，特別是不是細節的細節，還是儘量的記錄下來，這對於後期的排錯會很有幫助，這不是危言聳聽，值得你借鑑！
IT之夢---你---我---他
2013年05月13日 23：45