安徽快三开奖结果今天开奖号
首頁 | 郵件資訊 | 技術教程 | 解決方案 | 產品評測 | 郵件人才 | 郵件博客 | 郵件系統論壇 | 軟件下載 | 郵件周刊 | 熱點專題 | 工具
網絡技術 | 操作系統 | 郵件系統 | 客戶端 | 電子郵箱 | 反垃圾郵件 | 郵件安全 | 郵件營銷 | 移動電郵 | 郵件軟件下載 | 電子書下載

操作系統

Windows 9X | Linux&Uinx | Windows Server | 其它操作系統 | Vista | FreeBSD | Windows 7 |
首頁 > 操作系統 > Windows Server > AD復制排錯 > 正文

AD復制排錯

出處:www.winitpro.com.cn 作者:www.winitpro.com.cn 時間:2011-5-27 10:09:04

解決方案快照
問題
:AD復制問題排錯
解決方案:使用一種基本的方法,利用Windows Server支持工具監控和修復AD復制的問題。
需要條件:Windows Server 2003或Windows 2000,Windows Server支持工具
難度:3(最高5)
解決方案步驟
1、檢查目標DC的OS和目錄服務是否運行正常;
2、檢查DNS在源和目標DC上是否運行正常;
3、確認目標DC可以解析到源DC;
4、檢查Kerberos和它所依賴的服務;
5、檢查防火墻設置。

AD復制是當一個DC的目錄有變動時,自動復制到其它DC的方法。AD是非常健壯的服務,容錯性很強。由于AD可以是分布式的多DC架構,丟失部分數據并不會影響到整個目錄服務。在AD森林中,我們不僅要監控DC的基本情況,還需要關注DC間復制的運行情況。以我的經驗,如果不對森林中的復制進行監控,經過一段時間之后很可能會崩潰,即使你已經很仔細地進行DC的配置也無濟于事。監控和修復復制中出現的問題比修復那些不斷在森林中累積的問題要容易得多。但不管你是否對AD復制進行了監控,你肯定無法避免地遇到需要在AD中排查錯誤。在本文中我會介紹一些復制的基本原則,以及一些在AD復制排錯時經常用到的簡單的方法。AD復制的排錯有時會很迷糊;按照我的步驟可以讓你覺得這項任務還是有一些方法的,而不是靠魔法或感覺。

基礎
要找出一個最好的復制排錯的方法是很困難的。當然你肯定是希望使用一種能盡可能快的方法來解決問題;不過,也不能跳過最終可能會拖延整個排錯進程的步驟。我發現使用一個邏輯性強,徹底的方法效果是最好的。大家希望直接進入正題,使用一個全能的排錯工具,這種反應是很自然的,但是你應該首先使用一個邏輯性較強的方法來檢驗整個過程是否能順利地進行。在經過多次排錯,經驗豐富之后,你可以跳過其中的許多步驟。但最開始還是要仔細地執行每一步,以確保你不會直接做出錯誤的判斷,或者不得不重來一次。從檢查DC的OS開始,然后檢查目錄服務的情況。接著檢查DC間的基本通信。最后,檢查DC間在互相判斷是否認證時所使用的協議是否能正常運行。按照這些步驟可以幫助大家解決90%以上的復制問題。

檢查基礎架構
第一步是檢查DC的OS是否工作正常。復制錯誤可能是由于DC上的一些本地錯誤而導致的,你需要確認服務器的基礎服務是正常的。如果你之前沒有做過,那要在所有生產系統上先安裝最新的Windows Server支持工具。(本文我介紹的所有工具都是Windows Server支持工具。)可以從微軟下載中心下載這些工具(http://www.microsoft.com/downloads)。輸入關鍵字“support tools”,按照你的操作系統版本和SP版本來查找。在一個大環境中解決所有問題可能是不切實際的;不過,你可以使用Internet搜索引擎和微軟知識庫(KB,http://support.microsoft.com/search/?adv=1)來解決大部分影響重大的問題。
安裝好Windows Server支持工具后,先查看事件日志。首先,檢查系統日志中的警告和錯誤。如果在系統日志中發現錯誤,試試運行NetDiag。即使不用它的命令行選項,NetDiag也會運行23個和系統網絡配置相關的測試。這些測試中包括一些和域成員關系、DNS、客戶端配置、信任關系、Kerberos和LDAP功能相關的測試。如果你發現某個測試有問題,用/test:testname和/v選項再運行一次NetDiag,獲取關于這個測試的詳細分析結果。本文稍后還會用到另外一個重要的NetDiag選項/fix,它可以重新注冊服務器的DNS入口。
如果目錄服務日志有錯誤,運行DCDiag。DCDiag是一款用于對DC進行全面測試的工具。即使不使用命令行選項,DCDiag都可以運行27個和DC相關的測試。和NetDiag相似,如果你發現某個測試有問題,用/test:testname和/v選項再運行一次DCDiag,獲取詳細測試分析數據。別把太多時間花在這些系統日志測試的錯誤上;系統日志中任何最近的錯誤都可能導致測試失敗。
如果在上面的測試中沒有發現什么問題——即,NetDiag和DCDiag沒有發現任何OS或目錄服務相關的錯誤——那就請開始檢查復制吧。最佳的方法是從檢查DCDiag測試結果開始,因為DCDiag會運行一些擴展的復制測試。
現在我們使用如圖1所示的域來看看如何排查一個常見的錯誤。這個域的名稱是Deuby.net,有3臺DC。名為Godan和Kohai的DC位于Hub站點中。名為Sandan的DC位于Branch站點中,通過一個帶有復制的站點鏈接,連接到Hub站點,該復制的時間間隔是15分鐘。假設更新沒有從Kohai復制到Godan。復制總是入站的操作,因此,即使站點中的復制是由一臺DC的修改而觸發的,你也需要考慮到目標DC上已經從其它DC上主動“拉”過來的更新。從應該接收更新的DC上開始你的排錯吧。在我的示例中,這臺DC是Godan。

圖1:有3臺DC的域的示例

圖2是在Godan上運行DCDiag輸出結果的一部分。注意復制測試會因為錯誤“[KOHAI] DsBindWithSpnEx()由于錯誤1722失敗,RPC服務器不可用。”失敗,盡管這個錯誤信息很難理解,我們仍然可以通過這個信息找到問題的原因。這個問題很明顯和Kohai這臺DC相關。但“DsBindWithSpnEx()”是什么意思?“BindWithSpn”告訴我們的是當Godan試圖綁定(即,連接和認證)到Kohai時出現錯誤了。因而這個問題似乎是因為Godan無法和Kohai進行通信而導致的。

圖2:DCDiag的輸出

我們需要判斷Godan是否可以定位到它的復制伙伴Kohai。第一個要做的測試是ping Kohai的IP地址,檢查最基本的網絡連接。如果沒有問題,可以用Kohai的名字來ping(即,用DNS的A記錄)。不過,利用這種方法并不能做出結論,因為DC并不是通過解析它復制伙伴的A記錄(例如,dc1.mycompany.com)來找到它們的,而是通過解析一個特定的DNS規范名稱(即CNAME Alias),這個名稱在森林中是唯一的。
森林中的每臺DC都必須為DsaGuid._msdcs.ForestName名稱注冊它的CNAME;這個CNAME可以在復制系統中標識出這是一臺DC。CNAME記錄會映射到DC的A記錄,A記錄中包含了它的IP地址。例如,DNS CNAME為dc1.mycompany.com的可能是d40c01da-23fa-46e6-8bf3798503e2590f._msdcs.mycompany.com。CNAME記錄是d40c01da-23fa-46e6-8bf3798503e2590f._msdcs.mycompany.com CNAME dc1.mycompany.com。注意目錄服務代理(DSA,Directory Service Agent)的GUID(全球唯一標識)中第一部分的GUID是DC的CNAME(確切地說是objectGUID屬性),而不要誤解為DC計算機對象的GUID。實際上,它是站點容器DC中的NTDS Settings對象的GUID。例如,如果DC1在Hub站點中,它的DN(Distunguished Name)可能是CN=NTDS Settings,CN=DC1,CN=Servers,CN=Hub,CN=sites,CN=configuration,DC=mycompany,DC=com。
如果出現問題的DC不能解析它復制伙伴的CNAME,那它就接收不到更新。因此,你首先要找出Kohai基于GUID的DNS CNAME;然后看看Godan能否解析到這個CNAME。可能最簡單的方法是啟動AD站點和服務(dssite.msc),展開到Godan的站點(即,Hub,Server容器,KOHAI計算機對象),然后在NTDS Settings容器上點擊右鍵,選擇屬性。Kohai的CNAME存儲在DNS Alias字段中,如圖3所示。將該字符串復制并粘貼到Godan的命令行中,如圖4所示,用于判斷復制引擎是否能解析Kohai。如果DNS不能通過Kohai的CNAME來解析它,復制就不能進行。注意使用與Godan的CNAME類似的查詢就可以正確地解析。

圖3:查看Kohai的CNAME

圖4:判斷復制引擎是否能解析Kohai

現在我們已經找到了問題,可能是Kohai的DNS CNAME丟失了。有兩種方法可以進行重新注冊。最直接的方法是重啟Netlogon服務;不過,這種方法會使得Kohai和它的活動用戶間的通信暫時不可用。而如果DC出現了復制問題就要導致它的服務暫時不可用,這并不是我們想要的。另外一種影響較小的方法是運行NetDiag /fix。/fix參數是專門用于重新注冊DC需要的所有DNS記錄。注冊好了DNS記錄后,NetDiag可以干凈地運行,但會報一個警告,新添加的CNAME需要一段時間才能復制到第二臺DNS服務器上(即網卡的DNS配置中指定的第二臺DNS服務器)。

DNS的錯誤配置
從上面的例子可以看出,DNS的配置錯誤是導致AD出現問題的最主要的根源。DNS配置很復雜,而且與AD的功能緊密地集成在一起;許多錯誤的方法都可能導致DNS配置出現問題。如果你的DC出現DNS查找失敗或其它“無法定位”等類型的錯誤,你需要檢查以下設置。
檢查DC上的客戶端設置的IP地址是否正確(本地連接的TCP/IP屬性)。如果DC同時還是DNS服務器,建議的配置是將主DNS入口指向它自己。(在Longhorn Server中,如果Dcpromo在運行,系統會自動將DNS入口指向自己,即127.0.0.1。)第二臺DNS服務器應該指向相同域中的另一臺DC。要了解更多關于DC上不同類型的DNS客戶端配置的利弊,請參見微軟的文章“Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003”(http://support.microsoft.com/kb/825036)。
DC的主DNS服務器是它定位網絡資源的唯一方法。因此,你可以通過控制DC的主DNS入口來控制它可以訪問哪些服務器和域。如果你不知道DC自己的DNS服務是否在正常運行,把主DNS入口指向另外一臺正常的DNS服務器。
確認DC是否已經注冊了它所需要的資源記錄。和復制相關的有3條記錄。兩個CNAME(前面已經討論了)及A記錄(即,主機名到IP地址的解析)。可以運行DCDiag /test:connectivity來檢查這些記錄是否已經注冊到DC的主DNS服務器上,如果沒有注冊或有問題,還可以用NetDiag命令來重新注冊這些記錄。如果仍然注冊失敗,運行DCDiag /test:Registerindomain /Dns Domain:dnsdomainname來檢查當前DC的配置是否能正確地進行注冊。A記錄必須映射到正確的IP地址。記住,這些注冊項必須復制到該DC的復制伙伴使用的DNS服務器上。(注意IPConfig /RegisterDNS命令并不能完全注冊好這些DC需要的DNS記錄。)
對于在森林配置中的子域DC,你需要再檢查第三條記錄:Glue記錄。Glue記錄是DNS服務器提供給森林的子域使用的A記錄,保存在根域的正向查找區域中。Glue記錄可以解決一系列catch-22循環引用的問題:要從域外查找子域中的一臺主機,需要先查詢已經通過域認證的DNS服務器;不過,你無法解析到認證服務器,因為它的A記錄正位于你要獲取DNS信息的域中!在根域上為子域的DNS服務器設置第二套A記錄就可以解決這個引用問題,從而可以將子域連接到根域。使用DCDiag /DnsDelegation參數(DCDiag /test:DNS /DnsDelegation)可以對DC的Glue記錄進行測試。

訪問拒絕
第二種常見的錯誤一般是DC和它的復制伙伴的訪問被拒絕。在常規情況,訪問的問題不會出現,因為所有DC的機器帳戶都是Enterprise Domain Controllers組的成員。因此,出現了訪問拒絕的錯誤就意味著在復制成員間存在認證問題。最常見的根源是其中一臺DC上的時間不同步。復制自身并不依賴于時間——但是Kerberos卻依賴于時間。Kerberos要求DC間必須進行時間同步;如果它們的內部時鐘出現5分鐘以上的時差(默認值),Kerberos就會出錯,你會收到訪問源DC被拒絕的錯誤信息。系統日志中會記錄Kerberos錯誤,同時還很可能包含W32Time錯誤。
使用Net Time /QuerySNTP命令來查看哪些DC的時間服務器有問題。從定義上說,DC是域的成員。如果DC不是根域的PDC競爭者,它的時間服務器的配置應該是空的,因為非PDC的DC,它的默認Network Time Protocol(NTP)服務器是域中的PDC。如果出現問題的DC位于子域中,PDC會把根域中的DC當作時間源,而且這些DC反過來會把父域(通常是根域)的PDC當作整個森林的權威時間源。使用Net Time /SetSNTP:命令移除對某個指定時間服務器的引用。然后可以用手動用W32tm命令來控制DC的NTP設置。要強制DC定位一個時間源并和它進行同步,運行W32tm /Resync /Rediscover命令。還可以運行W32tm /Config /Syncfromflags:DOMHIER命令和域中的DC進行同步。要檢查域中所有DC的NTP設置,運行W32tm /Monitor命令。看看系統托盤上的時鐘何時會發生變化。
如果時間已經很久未進行同步,DC自己的Kerberos票據已經過期,遇到這種情況就必須在DC上禁用掉Key Distribution Center(KDC),然后重啟。(要禁用KDC,在控制面板的服務程序中,停止服務,并將啟動類型設置為禁用。)這些操作會清空Kerberos票據,并強制讓DC從其它DC上獲取新的票據。

其它說明
首先,要有耐心。企業環境中的復制可能需要一段時間才能完成,在排錯時同樣如此。例如,如果一臺DC沒有響應,Knowledge Consistency Checker(KCC)會等待90分鐘才重新計算DC的連接對象。
在現在這個安全至上的時代,要考慮到防火墻設置的變化也可能會導致復制失敗。還要檢查那些無法ping通的服務器,盡管它們自身是正常運行的,以及那些某些協議正常,但有些協議卻沒有響應的服務器。要了解防火墻所需的DC端口,請參閱微軟的文章“Active Directory Replication over Firewalls”(http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx)。
關于各種Windows Server產品所需要的端口,請參閱微軟知識庫文章“Service overview and network port requirements for the Windows Server system”(http://support.microsoft.com/kb/832017)。
如果你覺得目錄日志提供的信息仍然不夠,訪問注冊表的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics子鍵,啟用NTDS日志。要啟用哪個鍵值取決于你需要調查的區域(例如,Knowledge Consistency Checker,Name Resolution,Replication Events)。默認值是0,最大值是5。通常你可以設置為3。監控目錄日志以外的日志,如果你不再需要日志那就禁用它。
信任KCC。不要在KCC看起來沒有按照你的預期那樣創建拓撲時去懷疑它。如果KCC并沒有像預期那樣運行,你的站點拓撲很可能并沒有按照你預計的那樣進行配置。例如,你可能需要確認和該DC所屬站點相關聯的子網是否能連接到DC的IP地址。
最后,如果你看到DC已經很長一段時間沒有進行復制的錯誤,你最好不要再浪費時間進行排錯了。你必須重裝DC,從AD中移除它的元數據,然后重新加入AD。一位MVP同事曾經說過,“DC就像一隊士兵一樣;你可以踢走其中一個,把另一個類似的放在他的位置上。”

放下你的指揮棒
復制是AD的關鍵功能,但給復制排錯通常被認為是一種黑色藝術。要減少復制的神秘因素,首先要使用一種邏輯性很強的方法來保證這種方法是可行的;然后,檢查DC的操作系統是否能正常工作,檢查它的目錄服務、DNS配置、DC間的通信、Kerberos和它的依賴項(例如,Windows時間服務),以及防火墻配置。按照本文提供的這些步驟進行操作,可以把AD復制排錯的過程從妖術變成靠得住的方法。

相關文章 熱門文章
  • 如何在iPhone/iPod touch/iPad郵件應用程序Mail中使用QQ郵箱Exchange移動終端同步服務?
  • 避免AD攻擊 防止密碼破解和其它常用目錄攻擊
  • AD 1058與1030錯誤日志過多解決辦法
  • AD災難恢復
  • 通過腳本實現AD用戶自動連接打印機與共享文件夾
  • 實現微軟AD與Domino OA系統的互連互用
  • ADMT 3.2 遷移密碼
  • 在Exchange Server 2010中啟用結構化地址簿(Hierarchical Address Book)
  • 從Windows 2000 AD升級到Windows Server 2003 R2時遇到的一點小麻煩
  • 明明白白AdminSDHolder對象
  • 解決IPad和IPhone接收exchange郵件的問題
  • postfix+dovecot+postfixadmin+mysql架設郵件服務器
  • “http 500內部服務器錯誤”的解決方法
  • 利用Windows 2000 Server的RRAS實現VPN服務器
  • 用鳳凰萬能啟動盤解決本地/域管理員密碼丟失
  • Win2003 Server企業版安裝配置
  • Active directory 災難恢復
  • Windows 2000/03域和活動目錄
  • 如何在vmware4上創建windows 2003群集
  • MSI文件制作全過程
  • Win2000命令全集(一)
  • Windows 2000/AD技巧
  • 此系統的本地策略不允許您采用交互式登錄解決方法
  • Win2000路由的安裝與設置實現不同網段互通
  • 自由廣告區
     
    最新軟件下載
  • SharePoint Server 2010 部署文檔
  • Exchange 2010 RTM升級至SP1 教程
  • Exchange 2010 OWA下RBAC實現的組功能...
  • Lync Server 2010 Standard Edition 標..
  • Lync Server 2010 Enterprise Edition...
  • Forefront Endpoint Protection 2010 ...
  • Lync Server 2010 Edge 服務器部署文檔
  • 《Exchange 2003專家指南》
  • Mastering Hyper-V Deployment
  • Windows Server 2008 R2 Hyper-V
  • Microsoft Lync Server 2010 Unleashed
  • Windows Server 2008 R2 Unleashed
  • 今日郵件技術文章
  • 騰訊,在創新中演繹互聯網“進化論”
  • 華科人 張小龍 (中國第二代程序員 QQ...
  • 微軟推出新功能 提高Hotmail密碼安全性
  • 快壓技巧分享:秒傳郵件超大附件
  • 不容忽視的郵件營銷數據分析過程中的算..
  • 國內手機郵箱的現狀與未來發展——訪尚..
  • 易觀數據:2011Q2中國手機郵箱市場收入..
  • 穿越時空的愛戀 QQ郵箱音視頻及賀卡郵件
  • Hotmail新功能:“我的朋友可能被黑了”
  • 入侵鄰居網絡發騷擾郵件 美國男子被重..
  • 網易郵箱莫子睿:《非你莫屬》招聘多過..
  • 中國電信推廣189郵箱綠色賬單
  • 最新專題
  • 鳥哥的Linux私房菜之Mail服務器
  • Exchange Server 2010技術專題
  • Windows 7 技術專題
  • Sendmail 郵件系統配置
  • 組建Exchange 2003郵件系統
  • Windows Server 2008 專題
  • ORF 反垃圾郵件系統
  • Exchange Server 2007 專題
  • ISA Server 2006 教程專題
  • Windows Vista 技術專題
  • “黑莓”(BlackBerry)專題
  • Apache James 專題
  • 分類導航
    郵件新聞資訊:
    IT業界 | 郵件服務器 | 郵件趣聞 | 移動電郵
    電子郵箱 | 反垃圾郵件|郵件客戶端|網絡安全
    行業數據 | 郵件人物 | 網站公告 | 行業法規
    網絡技術:
    郵件原理 | 網絡協議 | 網絡管理 | 傳輸介質
    線路接入 | 路由接口 | 郵件存儲 | 華為3Com
    CISCO技術 | 網絡與服務器硬件
    操作系統:
    Windows 9X | Linux&Uinx | Windows NT
    Windows Vista | FreeBSD | 其它操作系統
    郵件服務器:
    程序與開發 | Exchange | Qmail | Postfix
    Sendmail | MDaemon | Domino | Foxmail
    KerioMail | JavaMail | Winwebmail |James
    Merak&VisNetic | CMailServer | WinMail
    金笛郵件系統 | 其它 |
    反垃圾郵件:
    綜述| 客戶端反垃圾郵件|服務器端反垃圾郵件
    郵件客戶端軟件:
    Outlook | Foxmail | DreamMail| KooMail
    The bat | 雷鳥 | Eudora |Becky! |Pegasus
    IncrediMail |其它
    電子郵箱: 個人郵箱 | 企業郵箱 |Gmail
    移動電子郵件:服務器 | 客戶端 | 技術前沿
    郵件網絡安全:
    軟件漏洞 | 安全知識 | 病毒公告 |防火墻
    攻防技術 | 病毒查殺| ISA | 數字簽名
    郵件營銷:
    Email營銷 | 網絡營銷 | 營銷技巧 |營銷案例
    郵件人才:招聘 | 職場 | 培訓 | 指南 | 職場
    解決方案:
    郵件系統|反垃圾郵件 |安全 |移動電郵 |招標
    產品評測:
    郵件系統 |反垃圾郵件 |郵箱 |安全 |客戶端
    廣告聯系 | 合作聯系 | 關于我們 | 聯系我們 | 繁體中文
    版權所有:郵件技術資訊網©2003-2010 www.mpmgk.icu, All Rights Reserved
    www.mpmgk.icu Web Team   粵ICP備05009143號
    安徽快三开奖结果今天开奖号 白小姐历史开奖结果 381818白小姐中特网站 极速快三官网手机平台 后三万能大底稳赚 开奖日必出特肖规律 快3和值跨度走势图 内蒙的快三现在出的什么号 查看上期的六个平码号 上海快三开奖最新走 广西福利彩票手机投注