做域控運(yùn)維的這些年“同步域控中的所有內(nèi)容”這句話我?guī)缀趺扛魩滋炀蜁?huì)聽到一次。有人想的是在新加的域控上把全公司用戶和組一次性拉齊有人是發(fā)現(xiàn)同事改了組策略在某臺(tái)域控上死活不生效還有人干脆把同步當(dāng)成萬能藥以為敲一條命令就能讓整片森林立刻數(shù)據(jù)一致。但同樣是這句話背后對(duì)應(yīng)的動(dòng)作完全不同。以我的經(jīng)驗(yàn)“同步域控中的所有內(nèi)容”至少包含四塊AD目錄自身的副本、SYSVOL里的組策略與腳本、AD集成DNS區(qū)域以及域內(nèi)時(shí)間源的對(duì)齊。這幾塊的同步機(jī)制、排查方法和命令都不一樣。下面我按實(shí)操順序把這件事攤開講涉及的命令都是我現(xiàn)在仍在用的適合負(fù)責(zé)域控環(huán)境運(yùn)維、開發(fā)和排障的同學(xué)參考。1. 同步對(duì)象先擺正域控里到底有哪幾份數(shù)據(jù)很多人一提到域控同步腦袋里只有一個(gè)模糊的“把A服務(wù)器上的數(shù)據(jù)復(fù)制到B服務(wù)器”。這個(gè)說法不是全錯(cuò)但域控環(huán)境里的“數(shù)據(jù)”分了好幾種每種數(shù)據(jù)的復(fù)制邏輯和傳播范圍都不一樣。如果在動(dòng)手之前沒擺正對(duì)象后面很容易出現(xiàn)“用戶是同步了但組策略沒有對(duì)象是同步了但DNS解析還是舊的”這樣的半吊子狀態(tài)。1.1 AD目錄副本三個(gè)命名上下文復(fù)制范圍各不相同AD數(shù)據(jù)庫本質(zhì)上是目錄服務(wù)它內(nèi)部按照“命名上下文”組織數(shù)據(jù)。最常見的是三個(gè)架構(gòu)Schema、配置Configuration和域Domain。架構(gòu)分區(qū)保存對(duì)象類定義和屬性定義配置分區(qū)保存站點(diǎn)、域、命名上下文這些邏輯結(jié)構(gòu)域分區(qū)保存用戶、組、計(jì)算機(jī)等實(shí)際業(yè)務(wù)對(duì)象。復(fù)制的范圍取決于分區(qū)類型。架構(gòu)和配置分區(qū)是全森林級(jí)別的也就是說森林里任何一個(gè)域控制器上的改動(dòng)會(huì)復(fù)制到其他所有域控制器。而域分區(qū)只在同一個(gè)域的域控制器之間復(fù)制。一個(gè)森林里如果有多個(gè)域A域的域分區(qū)并不會(huì)自動(dòng)復(fù)制到B域的域控制器上除非你啟用了全局編錄。這個(gè)容易被忽略的點(diǎn)現(xiàn)在想起來還是很值得強(qiáng)調(diào)。某項(xiàng)目環(huán)境里接入了一個(gè)多域森林操作人員在新域的域控上找不到老域的某些用戶第一反應(yīng)是“同步壞了”實(shí)際上是因?yàn)檫@臺(tái)域控根本沒有啟用全局編錄。想要全局搜索所有域的對(duì)象要把對(duì)應(yīng)域控的角色里勾上全局編錄讓所有域的域分區(qū)以只讀副本的形式定向拉過來。1.2 SYSVOL與AD集成DNS對(duì)象關(guān)聯(lián)卻走不同通道除了AD數(shù)據(jù)庫本身域控還有兩個(gè)對(duì)外服務(wù)的“實(shí)體數(shù)據(jù)”SYSVOL共享和DNS區(qū)域。SYSVOL是域控上的一個(gè)共享目錄默認(rèn)路徑通常是C:\Windows\SYSVOL\domain里面裝著組策略模板GPT、登錄腳本、腳本啟動(dòng)文件這些實(shí)實(shí)在在的文件夾內(nèi)容。GPO可以拆成兩部分一部分是AD數(shù)據(jù)庫里的組策略容器GPC記錄GPO的GUID、版本號(hào)另一部分是SYSVOL里的組策略模板GPT存放實(shí)際的策略文件。兩個(gè)部分必須同時(shí)復(fù)制到位GPO才能真正生效。早期環(huán)境用FRS復(fù)制SYSVOL后來的環(huán)境普遍遷移到DFSR這一點(diǎn)后面單獨(dú)說。AD集成DNS區(qū)域則是把DNS記錄放進(jìn)AD數(shù)據(jù)庫分區(qū)里優(yōu)點(diǎn)是避免每臺(tái)DNS服務(wù)器單獨(dú)維護(hù)一份區(qū)域文件記錄跟著AD復(fù)制走。如果你把域內(nèi)DNS區(qū)域的動(dòng)態(tài)更新和同步問題也歸進(jìn)“同步域控中的所有內(nèi)容”那要記住DNS記錄的復(fù)制并不是實(shí)時(shí)的它會(huì)依賴AD復(fù)制的節(jié)拍查詢舊記錄的時(shí)候照樣可能返回過期結(jié)果。1.3 別忘了時(shí)鐘同步之上還有一層“時(shí)間血液”時(shí)鐘和時(shí)間同步平時(shí)不起眼但它才是整個(gè)同步體系的“地基線”。Kerberos 認(rèn)證要求客戶端和服務(wù)端時(shí)間偏差不能太大通常默認(rèn)容忍5分鐘AD復(fù)制本身也要靠時(shí)間戳來處理沖突和最后寫入者獲勝如果兩臺(tái)域控的時(shí)間差得離譜復(fù)制通信會(huì)被直接拒絕日志里出現(xiàn)各種“拒絕”“不支持”的報(bào)錯(cuò)。我處理過一起典型的案例新部署的第二臺(tái)域控怎么同步都報(bào)RPC服務(wù)器不可用端口通、賬號(hào)對(duì)、網(wǎng)絡(luò)通查到最后發(fā)現(xiàn)新域控的系統(tǒng)時(shí)間比現(xiàn)有域控慢了將近10分鐘。用w32tm /resync /rediscover校準(zhǔn)后復(fù)制瞬間恢復(fù)正常。所以我在任何同步排查開始前都會(huì)先看一眼時(shí)間而不是急著敲同步命令。2. 域控同步的引擎是“對(duì)賬”不是簡單拷貝理解同步的對(duì)象之后下一個(gè)要搞懂的是后臺(tái)機(jī)制。域控同步絕對(duì)不是把一份數(shù)據(jù)整體覆蓋到別的機(jī)器上它的核心是“增量對(duì)賬”每臺(tái)域控都記錄自己當(dāng)前知道哪些變化伙伴之間互相拉取對(duì)方比自己新的部分。這個(gè)機(jī)制決定了你日常能用的操作命令也決定了哪些問題能用同步解決、哪些不能。2.1 USN與高水位標(biāo)記增量數(shù)據(jù)怎么追認(rèn)AD復(fù)制用的核心計(jì)數(shù)器叫做更新序列號(hào)USNUpdate Sequence Number由每臺(tái)域控自己維護(hù)。只要本地發(fā)生一次寫操作無論改的是用戶密碼還是部門屬性本機(jī)都會(huì)給這次修改分配一個(gè)遞增的USN并記錄下這個(gè)變更的元數(shù)據(jù)。每臺(tái)接收復(fù)制的目標(biāo)域控也會(huì)為每一個(gè)復(fù)制源伙伴維護(hù)一個(gè)“高水位標(biāo)記”。這個(gè)標(biāo)記說白了就是“上次我成功拿到了你到哪個(gè)USN為止的全部改動(dòng)”。下次復(fù)制時(shí)目標(biāo)域控對(duì)源伙伴說我的高水位停在這里你把這之后的新增USN數(shù)據(jù)發(fā)給我。兩邊一核對(duì)只傳需要傳的增量。這套對(duì)賬機(jī)制的好處很明顯復(fù)制流量小帶寬占用低即便每天有幾百條用戶變更同步也只是一小口一小口地追認(rèn)差異而不是把整個(gè)目錄來回搬運(yùn)。這也是為什么你手動(dòng)發(fā)起同步看到的輸出往往是“同步完成無待復(fù)制對(duì)象”而不是全量刷一遍。2.2 沖突仲裁多主復(fù)制憑什么不亂套AD是多主復(fù)制任何一臺(tái)域控都可以修改同一批用戶對(duì)象。如果是單機(jī)數(shù)據(jù)庫一個(gè)管理員直接改總數(shù)多點(diǎn)并發(fā)寫就是災(zāi)難所以AD必須有一套管用的沖突仲裁規(guī)則。它的處理原則是“屬性級(jí)最后寫入者獲勝”。兩個(gè)域控在短時(shí)間里分別修改了同一個(gè)用戶的不同屬性復(fù)制發(fā)生時(shí)這些屬性變更可以各自保留互不影響。如果改的是同一個(gè)屬性則看時(shí)間戳?xí)r間新的版本勝出。為了處理時(shí)鐘接近時(shí)的情況還有額外的版本號(hào)字段兜底確保仲裁結(jié)果是確定性的。理解這個(gè)機(jī)制后你就不會(huì)去干“為了同步而同步”的傻事。比如某臺(tái)域控離線很久重新上線后復(fù)制過來的“舊數(shù)據(jù)”覆蓋了另一臺(tái)目前在線域控上的新改動(dòng)。這類問題的管理靠的是“權(quán)威還原”或者提前評(píng)估哪臺(tái)域控的數(shù)據(jù)才是真實(shí)源而不是盲目觸發(fā)一次全量同步一旦方向拉反可能把正確數(shù)據(jù)蓋掉。2.3 KCC的拓?fù)渥詣?dòng)布線別手捅拓?fù)渫饺绻恢v究那企業(yè)里N臺(tái)域控互相拉取就是全連接亂聯(lián)網(wǎng)線不夠用。AD的設(shè)計(jì)思路是讓知識(shí)一致性檢查器KCC自動(dòng)生成復(fù)制拓?fù)?。KCC會(huì)定期評(píng)估當(dāng)前每個(gè)站點(diǎn)里的域控?cái)?shù)量、復(fù)制伙伴關(guān)系、站點(diǎn)間鏈接自動(dòng)產(chǎn)生一套有環(huán)冗余的拓?fù)洹Ｕ军c(diǎn)內(nèi)默認(rèn)保證任意兩臺(tái)域控之間最多經(jīng)過幾跳就能同步站點(diǎn)間則通過橋頭堡服務(wù)器交換數(shù)據(jù)而不是每臺(tái)域控都直接建立跨地域連接。這就像快遞中心先收件到分撥站再統(tǒng)一轉(zhuǎn)運(yùn)比每件個(gè)人包裹直飛另一個(gè)城市要省得多。實(shí)際運(yùn)維中你不需要手工修改KCC生成的連接對(duì)象。偶爾有人會(huì)為了強(qiáng)制某臺(tái)DC立即同步而手動(dòng)新建連接但這類手工連接在KCC下一次重算時(shí)有可能會(huì)被自動(dòng)處理反而留下一種“看起來配置了就是好的”錯(cuò)覺。重點(diǎn)是保證KCC正常運(yùn)行然后根據(jù)你的站點(diǎn)和子網(wǎng)定義把網(wǎng)絡(luò)側(cè)的地圖畫正確。3. 同步出問題的排查順序時(shí)間、DNS、復(fù)制拓?fù)?、積壓隊(duì)列域控同步報(bào)錯(cuò)的時(shí)候最忌一上來就敲命令拉數(shù)據(jù)。我踩過太多次“敲了十來分鐘命令結(jié)果發(fā)現(xiàn)根因是時(shí)間偏差”的經(jīng)驗(yàn)也見過同事在DNS記錄缺失時(shí)反復(fù)重啟復(fù)制服務(wù)最終只是把問題變得更亂?，F(xiàn)在我的排查順序非常固定基本能夠覆蓋大部分同步故障。3.1 第一錘確認(rèn)時(shí)鐘源時(shí)間偏了同步全停先在一臺(tái)域控上執(zhí)行w32tm /query /source w32tm /query /status如果輸出的源不是“本地時(shí)鐘”或另一臺(tái)上級(jí)域控就要留意了。域控之間時(shí)間同步的推薦做法是林根域的主域控角色持有者同步外部時(shí)間源其余所有域控默認(rèn)從域?qū)哟紊嫌潍@取時(shí)間。最簡單的校準(zhǔn)命令是w32tm /resync /rediscover在Windows環(huán)境中同步服務(wù)的客戶端模式默認(rèn)開啟網(wǎng)域內(nèi)的成員域控會(huì)自動(dòng)跟隨時(shí)間源。如果你的環(huán)境里有防火墻攔了UDP 123那即使復(fù)制端口全通時(shí)間也可能長期漂移。時(shí)間偏差一旦超過Kerberos默認(rèn)閾值所有依賴認(rèn)證的同步都會(huì)報(bào)“拒絕訪問”或“RPC不可用”非常迷惑人。3.2 第二錘repadmin/replsummary 與 dcdiag 快速定位失敗對(duì)時(shí)間正常后用repadmin做全局面掃描。最容易讀的就是復(fù)制匯總repadmin /replsummary這條命令會(huì)把整個(gè)森林的同步狀態(tài)按域控拉成表格列出成功、失敗、失敗百分比和積壓數(shù)量?？吹侥硞€(gè)目標(biāo)域控失敗率飆高再去把范圍縮小到這一臺(tái)。進(jìn)一步看復(fù)制伙伴關(guān)系repadmin /showrepl它會(huì)輸出當(dāng)前域控的復(fù)制伙伴列表、最近嘗試時(shí)間、失敗時(shí)間、失敗次數(shù)和錯(cuò)誤碼。我通常把repadmin /showrepl的結(jié)果作為定位問題的第二現(xiàn)場(chǎng)因?yàn)樗苤苯痈嬖V我是誰向誰復(fù)制最后一次失敗是幾秒鐘前報(bào)了什么錯(cuò)誤碼。如果repadmin /replsummary的輸出比較漂亮但你在實(shí)際業(yè)務(wù)里仍覺得不同步再跑一次域控綜合診斷dcdiag /test:replications它會(huì)對(duì)復(fù)制相關(guān)的關(guān)鍵項(xiàng)做結(jié)論性檢查明確指出“無法復(fù)制”“復(fù)制被拒絕”“長時(shí)間未復(fù)制”等問題。3.3 第三錘事件日志與常見信號(hào)歸類命令工具給出現(xiàn)象事件日志才給出原因。進(jìn)入“事件查看器 → 應(yīng)用程序和服務(wù)日志 → Directory Service”集中看Error和Warning級(jí)別的事件。常見的復(fù)制問題信號(hào)可以歸類為三類。第一類是拓?fù)渖深?。如果日志中出現(xiàn)KCC無法為某個(gè)命名上下文生成完整生成樹的事件常見編號(hào)比如1311說明KCC計(jì)算拓?fù)涫≡蛲ǔＪ钦军c(diǎn)配置不完整、橋頭堡服務(wù)器不可用或子網(wǎng)覆蓋缺失這時(shí)候需要先解決站點(diǎn)拓?fù)涠皇鞘謩?dòng)同步。第二類是解析和連接類。日志中反復(fù)提示某個(gè)域控名稱或IP無法解析大概率是AD集成DNS區(qū)域里缺少NTDS設(shè)置對(duì)象的DNS記錄。直接用DNS管理工具確認(rèn)伙伴域控的A記錄、CNAME記錄和SRV記錄是否存在缺失的注冊(cè)或重新注冊(cè)。第三類是安全拒絕類。錯(cuò)誤提示“復(fù)制訪問被拒絕”一般指向復(fù)制所使用的連接賬號(hào)被禁用、密碼過期、或在系統(tǒng)賬戶域策略里被限制了從屬關(guān)系。這類錯(cuò)誤尤其容易發(fā)生在重裝域控或恢復(fù)舊虛擬機(jī)之后因?yàn)闄C(jī)器賬戶和NTDS設(shè)置的安全標(biāo)識(shí)符對(duì)不上。3.4 深水區(qū)長期脫機(jī)導(dǎo)致的殘留對(duì)象與墓碑風(fēng)險(xiǎn)還有一類問題不在常規(guī)排查順序里但一旦遇上就是大坑。某臺(tái)域控長時(shí)間離線超過墓碑生存期后再重新上線它數(shù)據(jù)庫里仍然保存著一些已經(jīng)被AD標(biāo)記為刪除并剪除的對(duì)象。這些對(duì)象在同步時(shí)會(huì)被當(dāng)作“殘留對(duì)象”導(dǎo)致復(fù)制行為異?；驁?bào)錯(cuò)。這類情況用普通同步命令是修不好的。思路是聯(lián)系在線域控把這臺(tái)離線段上存在的殘留對(duì)象清理干凈。微軟也提供類似移除殘留對(duì)象的工具性能力可以通過repadmin /removelingeringobjects處理但執(zhí)行前要謹(jǐn)慎評(píng)估參數(shù)方向避免誤刪正常對(duì)象。說句實(shí)在話遇到這種情況最穩(wěn)妥的方案往往是直接退域、重建這臺(tái)域控再做元數(shù)據(jù)清理成本往往比在舊機(jī)器上反復(fù)搶救要低。4. 手動(dòng)觸發(fā)同步的操作清單repadmin 參數(shù)逐項(xiàng)拆解正常情況下AD復(fù)制是自動(dòng)進(jìn)行的不需要人為干預(yù)。但“一切正?！辈坏扔凇坝肋h(yuǎn)不需要手動(dòng)”。新建域控進(jìn)入生產(chǎn)環(huán)境后為了盡快讓它在短時(shí)間內(nèi)拿到全量數(shù)據(jù)我們會(huì)主動(dòng)觸發(fā)一次同步排查過程中為了驗(yàn)證網(wǎng)絡(luò)和賬號(hào)連通性也會(huì)手動(dòng)拉一次。手動(dòng)同步的入口幾乎都集中在repadmin上。4.1 第一板斧 repadmin /syncall /AdeP到底做了什么域控同步圈里最廣為人知的命令大概就是這一條repadmin /syncall /AdeP我一般在當(dāng)前域控上執(zhí)行它會(huì)做幾件事/A 表示同步所有目錄分區(qū)/d 配合 /A 表示只同步目錄分區(qū)/e 把同步范圍擴(kuò)展到整個(gè)企業(yè)森林/P 表示由當(dāng)前域控向所有復(fù)制伙伴主動(dòng)推送數(shù)據(jù)。如果只想安靜地等結(jié)果加上 /q。這條命令跑完后屏幕會(huì)逐條列出向哪些伙伴、哪個(gè)分區(qū)進(jìn)行了同步。輸出的初衷是讓你看到每一條連接的狀態(tài)所以信息量偏大看重點(diǎn)不是“輸出越長越好”而是末尾有沒有“成功完成的同步請(qǐng)求”以及有沒有伴隨錯(cuò)誤碼。需要提醒的是/AdeP并不是“重新復(fù)制整個(gè)AD數(shù)據(jù)庫”它仍然基于現(xiàn)有的高水位機(jī)制拉增量。只是在拓?fù)渥兇?、連接很多時(shí)它能把這些增量請(qǐng)求一次性全部發(fā)出去提高同步效率。4.2 分區(qū)級(jí)與伙伴級(jí)同步從全局到單點(diǎn)的粒度控制有時(shí)候全量同步太吵而且會(huì)驚動(dòng)一大堆不需要連接的伙伴。這時(shí)可以把操作縮小到“某個(gè)分區(qū)”或“某個(gè)伙伴”。用repadmin /syncall加上指定分區(qū)名可以只同步域分區(qū)此時(shí)命令的大致形式是先把視圖羅列出來再針對(duì)分區(qū)執(zhí)行同步請(qǐng)求。如果要對(duì)著某一個(gè)具體伙伴來同步可以先看repadmin /showrepl輸出里的伙伴標(biāo)識(shí)再同步指定目標(biāo)。實(shí)際場(chǎng)景中用的較多的反而是“域控間兩兩同步”repadmin /syncall DC2 /AdeP這個(gè)寫法指的是“當(dāng)前這臺(tái)域控以DC2為同步目標(biāo)把相關(guān)分區(qū)同步過去”。理解這一點(diǎn)很重要因?yàn)锳D里的方向是有語義的。你總是希望“源持最新數(shù)據(jù)的一方把數(shù)據(jù)拉向需要補(bǔ)數(shù)據(jù)的一方”如果拉反方向相當(dāng)于用舊的增量嘗試覆蓋新的數(shù)據(jù)輕則無變化重則把版本向量搞得一團(tuán)糟。4.3 腳本化觸發(fā)同步與失敗重試手動(dòng)命令適合排障但要想讓同步可靠還是要讓命令能編排、能量化。我習(xí)慣把同步觸發(fā)做成一個(gè)小腳本先探測(cè)所有域控再逐個(gè)執(zhí)行同步。比如用 PowerShell 拿到域內(nèi)所有域控制器列表$dcs Get-ADDomainController -Filter * foreach ($dc in $dcs) { repadmin /syncall $dc.HostName /AdeP /q }這只是最簡版實(shí)際項(xiàng)目里建議把日志重定向到文件同時(shí)在命令完成后讀取$LASTEXITCODE判斷成功與否再將結(jié)果寫入統(tǒng)一的日志目錄。這樣第二天巡檢翻日志時(shí)一眼就能看到哪臺(tái)域控曾經(jīng)出現(xiàn)過同步失敗。4.4 “全量同步”的邊界別把增量復(fù)制神話成重置鍵我要專門潑一盆冷水很多人在“同步不了”的時(shí)候期望用強(qiáng)制同步來解決一切但強(qiáng)制同步不是萬能重置鍵。AD復(fù)制的底層是增量對(duì)賬如果源端數(shù)據(jù)本身已經(jīng)損壞、伙伴關(guān)系被破壞、或者長時(shí)間未復(fù)制的狀態(tài)已經(jīng)越過墓碑周期單純觸發(fā)同步并不能讓目標(biāo)域控“重新認(rèn)識(shí)”一臺(tái)源域控。真正意義上的全量初始化通常出現(xiàn)在“重新加入域控”“刪除并重建復(fù)制伙伴關(guān)系”“恢復(fù)系統(tǒng)狀態(tài)備份”這些場(chǎng)景里。普通在線域控之間的“全量同步”更多只是“把所有分區(qū)的待復(fù)制對(duì)象一次性請(qǐng)求完成”而不是把整本數(shù)據(jù)庫推倒重鋪。因此在遇到深層次異常之前不要迷信命令先把根因查清楚。5. SYSVOL的同步坑位最密集組策略和登錄腳本在這里如果要在域控同步的維護(hù)主題里挑一個(gè)最容易出幺蛾子的點(diǎn)我會(huì)選SYSVOL。原因很現(xiàn)實(shí)AD數(shù)據(jù)庫部分一旦出問題報(bào)錯(cuò)往往非常顯眼日志會(huì)明確指出來而SYSVOL出了問題表現(xiàn)可能只是“這臺(tái)域控的組策略不生效”“登錄腳本時(shí)有時(shí)沒有”讓人很難第一眼聯(lián)想到同步。5.1 先判斷SYSVOL是否同步成功共享、日志、DFSR狀態(tài)三件套我接到SYSVOL相關(guān)的同步問題第一件事永遠(yuǎn)是看三樣?xùn)|西。第一共享是否發(fā)布成功。在域控上執(zhí)行net share正常情況下應(yīng)該能看到SYSVOL共享路徑指向C:\Windows\SYSVOL\sysvol下的域名目錄。如果共享不存在說明這臺(tái)域控的SYSVOL初始化還沒有完成自然不可能參與同步。第二DFSR服務(wù)是否在運(yùn)行。用Get-Service DFRSDFSR是當(dāng)前Windows Server主流環(huán)境里負(fù)責(zé)復(fù)制SYSVOL組策略模板副本的服務(wù)。如果服務(wù)停止同步一定中斷。第三看事件日志中有關(guān)DFSR的記錄。DFSR 在運(yùn)行到某個(gè)穩(wěn)定狀態(tài)后會(huì)周期產(chǎn)生同步健康相關(guān)事件。如果事件日志一直反復(fù)提示伙伴不可達(dá)、接入失敗或初始同步未完成就要對(duì)狀態(tài)進(jìn)行深挖。5.2 常見的SYSVOL滯后根因與修復(fù)路徑從經(jīng)驗(yàn)看SYSVOL不同步的根因集中在三個(gè)方向。第一個(gè)是Dc整體復(fù)制鏈路故障。SYSVOL依賴AD整體的連接對(duì)象和站點(diǎn)拓?fù)淙绻鲝?fù)制鏈路本身有問題SYSVOL的DFSR同樣走不通。因此排查SYSVOL之前我仍然會(huì)先跑一遍repadmin /showrepl確保AD復(fù)制沒有大問題。第二個(gè)是DNS解析異常。DFSR復(fù)制伙伴之間靠DNS解析對(duì)方全名如果某臺(tái)域控的DNS記錄沒注冊(cè)DFSR可能一直找不到目標(biāo)。處理辦法是確認(rèn)該域控的網(wǎng)絡(luò)并重置其DNS注冊(cè)。第三個(gè)是老環(huán)境遷移不徹底。歷史遺留環(huán)境中有的域控還在用早期文件復(fù)制服務(wù)FRS有的已經(jīng)遷移到DFSR兩套機(jī)制之間的狀態(tài)就會(huì)出現(xiàn)“每個(gè)域控各自為政”。這時(shí)候不要自己手忙腳亂去操作建議基于可靠環(huán)境下檢查功能級(jí)別確認(rèn)同域所有域控是否都進(jìn)入同一套復(fù)制機(jī)制。5.3 GPO的“面”與“里”容器對(duì)象和模板文件要一條心GPO是AD對(duì)象與SYSVOL文件的“混合體”這也是同步時(shí)最隱蔽的坑。組策略容器GPC在AD域分區(qū)里復(fù)制組策略模板GPT在SYSVOL目錄里復(fù)制兩邊都有版本號(hào)字段。域控在應(yīng)用組策略時(shí)會(huì)同時(shí)讀取這兩個(gè)副本的信息比較內(nèi)部版本號(hào)。如果兩邊不一致客戶端往往會(huì)取到不完整的策略呈現(xiàn)為“策略未更新”“某條設(shè)置未生效”等模糊現(xiàn)象。驗(yàn)證方法并不復(fù)雜。在新建或修改GPO之后等復(fù)制周期完成到另一臺(tái)域控上打開組策略管理確認(rèn)GPO狀態(tài)正常再打開SYSVOL里對(duì)應(yīng)的策略文件夾看版本文件中的版本號(hào)與AD側(cè)是否遞增一致?？缬蚩仳?yàn)證GPO版本的時(shí)候可以借助此方法確認(rèn)“面”和“里”都同步到位。6. 同步完成后的自證驗(yàn)證順序和常態(tài)化巡檢同步動(dòng)作做完之后不能憑感覺“應(yīng)該是OK了”就收工。域控同步這件事結(jié)果必須可驗(yàn)證而且要能長期驗(yàn)證。我自己在做完任何一次主動(dòng)同步后至少會(huì)完成三個(gè)層次的檢查。6.1 復(fù)制延遲、隊(duì)列長度與失敗計(jì)數(shù)的三張報(bào)告第一層看的是“復(fù)制本身是否健康”。用以下命令組合快速拉出結(jié)論repadmin /replsummary repadmin /showqueue/replsummary看宏觀失敗率/showqueue看某一臺(tái)域控當(dāng)前復(fù)制隊(duì)列里還堆積著多少條待復(fù)制對(duì)象。如果隊(duì)列長度長時(shí)間不為零說明它一直在努力追但追不上要順著源伙伴往下細(xì)查。repadmin /showrepl則能看每一個(gè)伙伴連接的最后成功與最后失敗時(shí)間這個(gè)輸出是我最常留檔的證據(jù)。6.2 對(duì)象級(jí)一致性抽查用一個(gè)小腳本做跨DC對(duì)比報(bào)告級(jí)檢查只能說明復(fù)制鏈路本身是通的不能直接證明“某個(gè)對(duì)象已經(jīng)出現(xiàn)在所有域控上”。因此真正要自證“同步域控中的所有內(nèi)容”我會(huì)做一次對(duì)象計(jì)數(shù)對(duì)比。簡單腳本示例$dcs Get-ADDomainController -Filter * foreach ($dc in $dcs) { $count (Get-ADObject -Filter * -Server $dc.HostName -SearchBase (Get-ADDomain).DistinguishedName).Count [PSCustomObject]{ DC $dc.Name; ObjectCount $count } }這個(gè)腳本的效率不算高只適合做抽樣驗(yàn)證而非高頻任務(wù)。我一般是在做重大項(xiàng)目變更或者新域控上線后用它做一次“全量對(duì)象數(shù)量對(duì)齊”各域控之間的總數(shù)差異在個(gè)位數(shù)以內(nèi)就可以接受。如果差異很大再按對(duì)象類型細(xì)分比如用戶、計(jì)算機(jī)、組別單獨(dú)對(duì)比。6.3 我的日常巡檢習(xí)慣固化“同步健康”為周任務(wù)同步故障最怕的不是出問題而是出了問題沒人知道。AD復(fù)制通常是靜默的一旦隊(duì)列持續(xù)積壓往往是在用戶開始抱怨“策略不生效、賬號(hào)不統(tǒng)一、地址解析不對(duì)”時(shí)才被發(fā)現(xiàn)。為了避免這種被動(dòng)我把同步健康檢查固化成了每周任務(wù)。每周固定時(shí)間跑一次repadmin /replsummary把結(jié)果追加到一個(gè)日志文件里再跑一次dcdiag /test:replications無錯(cuò)誤則通過。腳本發(fā)現(xiàn)失敗記錄時(shí)自動(dòng)把前一天的事件日志摘要寫入額外告警目錄。這個(gè)動(dòng)作本身并不重幾分鐘搞定但能把很多“還沒變成故障”的異常提前暴露出來。最后再分享一個(gè)小習(xí)慣。每次做手動(dòng)同步前我都把時(shí)間和DNS狀態(tài)先拍一張“快照”w32tm /query /status ipconfig /displaydns同步結(jié)束后再對(duì)照一次。如果同步前后連時(shí)間和解析都變了那說明底層地基本來就沒穩(wěn)。先把這兩個(gè)干凈再來談“同步域控中的所有內(nèi)容”事半而功倍。