AD Replication ו-KCC: המדריך המקצועי המלא בעברית לרפליקציה של Active Directory

אחד הרגעים המביכים בראיון עבודה לתפקיד סיסטם הוא כשהמראיין שואל שאלה שנשמעת פשוטה: "יש לך שני Domain Controllers. אחד בתל אביב ואחד בחיפה. שינית סיסמה למשתמש בתל אביב — מתי זה יגיע לחיפה, ומי בכלל החליט דרך איזה נתיב זה יעבור?". מי שעונה "זה מסתנכרן לבד" — לא עבר. מי שיודע להסביר מה זה KCC, מה זה Connection Object ולמה בכלל יש הבדל בין רפליקציה בתוך אתר לבין רפליקציה בין אתרים — כבר מדבר בשפה של אנשי תשתיות.

במדריך הזה נפרק את מנגנון הרפליקציה של Active Directory לגורמים, בשפה של השטח: מה נשלח, מתי, דרך מי, ואיך מאבחנים כשזה נתקע.

מה זה בכלל AD Replication? 🔁

Active Directory הוא Multi-Master. כלומר, כמעט כל שינוי אפשר לבצע בכל Domain Controller בארגון — יצירת משתמש, שינוי סיסמה, הוספה לקבוצה או עדכון תכונה. מכאן נולדת הבעיה: אם השינוי יכול להיווצר בכל מקום, מישהו צריך לוודא שכל שאר ה-DCs יקבלו אותו, בסדר הגיוני, בלי לולאות אינסופיות ובלי להעמיס את הקווים בין הסניפים. המנגנון שאחראי לזה הוא הרפליקציה.

חשוב להבין נקודה בסיסית: AD לא משכפל "את כל מסד הנתונים". הוא משכפל שינויים ברמת התכונה (Attribute-Level Replication). אם שיניתם רק את מספר הטלפון של משתמש — רק התכונה הזו תעבור ברשת, לא כל אובייקט המשתמש. זו אחת הסיבות שרפליקציה של AD חסכונית להפליא בפס רוחב לעומת מה שאנשים מדמיינים.

Partitions — מה בעצם משוכפל ולאן

מסד הנתונים של AD (הקובץ NTDS.dit) מחולק למחיצות לוגיות, ולכל מחיצה יש היקף שכפול משלה:

• ▸🗂️ Schema Partition — הגדרת סוגי האובייקטים והתכונות. משוכפלת לכל ה-DCs ביער כולו.
• ▸🌲 Configuration Partition — מבנה היער: Sites, Site Links, Subnets, Services. משוכפלת גם היא לכל היער.
• ▸🏠 Domain Partition — האובייקטים עצמם: משתמשים, מחשבים, קבוצות ו-OUs. משוכפלת רק בין ה-DCs של אותו דומיין.
• ▸🌍 Global Catalog — עותק חלקי (Partial Attribute Set) של אובייקטים מכל הדומיינים ביער, נמצא רק על DCs שהוגדרו כ-GC ומשרת חיפושים וכניסות.
• ▸📡 Application Partitions — למשל DomainDnsZones ו-ForestDnsZones, שבהן יושבות רשומות ה-DNS כאשר האזור משולב ב-AD.

מי מחליט מי מדבר עם מי? נכיר את ה-KCC 🧠

KCC — ראשי תיבות של Knowledge Consistency Checker — הוא תהליך שרץ על כל Domain Controller כחלק משירות ה-Directory. התפקיד שלו: לבנות ולתחזק אוטומטית את טופולוגיית הרפליקציה. בפועל, ה-KCC יוצר אובייקטים בשם Connection Objects, שכל אחד מהם אומר בעצם "ה-DC הזה ימשוך שינויים מה-DC ההוא". שימו לב לניסוח: הרפליקציה ב-AD היא Pull ולא Push — כל DC מושך את השינויים מהשותפים שלו.

ה-KCC רץ כברירת מחדל כל 15 דקות ובודק אם הטופולוגיה עדיין תקינה. נפל DC? שינית Site Links? הוספת שרת חדש? ה-KCC יחשב מחדש את הנתיבים ויבנה חיבורים חלופיים בלי שתצטרכו לעשות דבר. זו הסיבה שבתוך Active Directory Sites and Services תראו אובייקטי חיבור שנקראים <automatically generated> — אלה יצירי הכפיים של ה-KCC.

בתוך אתר (Intra-Site) ה-KCC בונה טופולוגיה טבעתית (Ring Topology) עם כלל אצבע חשוב: לא יותר משלושה "קפיצות" (Hops) בין כל שני DCs. כשמספר ה-DCs באתר גדל, ה-KCC פשוט יוצר חיבורי רוחב (Shortcut Connections) שחוצים את הטבעת כדי לשמור על הכלל הזה. המטרה: לצמצם השהיה (Latency) בהתכנסות של שינויים.

ISTG — ה-KCC של הרפליקציה בין אתרים 🌐

כשמדובר בשכפול בין אתרים, לא כל DC בונה חיבורים לעצמו. בכל אתר נבחר שרת אחד בתפקיד ISTG (Inter-Site Topology Generator), והוא זה שאחראי לחשב את חיבורי הרפליקציה היוצאים והנכנסים מהאתר שלו לאתרים אחרים. ה-ISTG מחשב את הנתיב לפי עלות ה-Site Links (Cost), ואם ה-ISTG נופל — אתר בוחר אוטומטית ISTG חלופי. גם כאן, אפס התערבות ידנית ברוב הארגונים.

Intra-Site מול Inter-Site — ההבדל שחייבים להכיר ⚖️

• ▸⚡ בתוך אתר: אין דחיסה (חוסך CPU), ומופעל מנגנון Change Notification — ה-DC ששינה מודיע לשותפיו תוך כ-15 שניות, כך שההתכנסות מהירה מאוד.
• ▸🗜️ בין אתרים: התעבורה נדחסת (בערך פי 10-15) כדי לחסוך פס רוחב בקו ה-WAN, אבל השכפול מתבצע לפי לוח זמנים — ברירת מחדל של פעם ב-180 דקות, וניתן לרדת עד 15 דקות.
• ▸🧮 Site Link Cost — ככל שהערך נמוך יותר, כך הקו "מועדף" יותר. כך גורמים לרפליקציה לזרום דרך הקו המהיר ולא דרך קו הגיבוי הסלולרי.
• ▸🚚 Bridgehead Server — ה-DC שמשמש שער יציאה/כניסה לאתר עבור תעבורת רפליקציה בין אתרים.

טעות נפוצה בשטח: מגדירים סניף חדש, שוכחים לשייך לו Subnet באובייקט ה-Site, ואז כל המחשבים בסניף מדברים עם DC בתל אביב במקום עם ה-DC שנמצא איתם בבניין. התוצאה: כניסות איטיות, GPO שמתעכב ותלונות שמגיעות ל-Helpdesk. שיוך Subnets ל-Sites הוא לא פרט טכני שולי — הוא מה שמלמד את AD מי "קרוב" למי.

USN, High-Watermark ו-UTD Vector — הלב של המנגנון 🩺

כאן מגיע החלק שמפריד בין שינון לבין הבנה. AD לא משתמש בחותמות זמן כדי להחליט מה חדש — הוא משתמש במונים. לכל DC יש מונה פנימי בשם USN (Update Sequence Number) שעולה בכל שינוי מקומי. כשה-DC מבקש עדכונים משותף, הוא אומר לו: "בפעם הקודמת הגעתי אצלך עד USN מסוים — תן לי רק מה שקרה מאז". הערך הזה נקרא High-Watermark.

בנוסף, כל DC מחזיק Up-to-dateness Vector — טבלה שאומרת עד איזה USN הוא כבר מכיר מכל DC אחר ביער. בזכות הטבלה הזו נמנעת רפליקציה כפולה (Propagation Dampening): אם השינוי כבר הגיע דרך שכן אחד, ה-DC לא יבקש אותו שוב מהשכן השני. זה מה שמונע לולאות אינסופיות בטופולוגיה טבעתית.

ומה קורה כששני אדמינים שינו את אותה תכונה בו זמנית בשני DCs שונים? זהו Replication Conflict, ו-AD פותר אותו בסדר עדיפויות קבוע: קודם לפי Version Number של התכונה (הגבוה מנצח), אם שווה — לפי חותמת הזמן, ואם גם זה שווה — לפי ה-GUID של ה-DC. כלומר, תמיד יש מנצח דטרמיניסטי, בלי שאיש יצטרך להתערב.

מחיקות: Tombstone, Deleted Objects ו-Recycle Bin 🗑️

מחיקה ב-AD אינה מחיקה מיידית. האובייקט מסומן כמחוק (isDeleted=TRUE), מועבר למיכל Deleted Objects ומשוכפל כך גם לשאר ה-DCs — אחרת DC שהיה כבוי היה "מחזיר לחיים" משתמשים מחוקים. תקופת ה-Tombstone Lifetime בגרסאות מודרניות היא 180 יום, ורק אחריה תהליך ה-Garbage Collection מסלק את השאריות פיזית. חשוב: DC שהיה מנותק יותר מ-180 יום נחשב Lingering Object Risk ואסור להחזיר אותו לרשת כמו שהוא.

אבחון תקלות רפליקציה — ארגז הכלים של האדמין 🧰

:: תמונת מצב מלאה של כל השותפים והשגיאות
repadmin /replsummary

:: מצב הרפליקציה הנכנסת של DC מסוים
repadmin /showrepl DC01

:: כפיית סנכרון מיידי של כל השותפים
repadmin /syncall /AdeP

:: הצגת אובייקטים שלא הסתנכרנו (Lingering Objects)
repadmin /removelingeringobjects DC02 <Source-DC-GUID> "dc=netme,dc=local" /advisory_mode

:: בדיקת תקינות כוללת של ה-DC
dcdiag /test:replications /v

:: ב-PowerShell: כשל רפליקציה בפורמט קריא
Get-ADReplicationFailure -Target DC01 | Format-List
Get-ADReplicationPartnerMetadata -Target DC01 | Select Partner,LastReplicationSuccess

ומה בדרך כלל שובר רפליקציה בשטח? ברוב המכריע של המקרים זה לא AD עצמו אלא התשתית סביבו: DNS שגוי (DC שמצביע על עצמו בלבד), הפרשי שעון של יותר מ-5 דקות ששוברים את Kerberos, פיירוול שחוסם RPC דינמי או פורט 135, ו-Site Links שהוגדרו עם לוח זמנים חוסם. תבדקו את ארבעת אלה — ותפתרו את רוב התקלות עוד לפני שפתחתם Event Viewer.

רוצים להגיע לרמה הזו בשטח? 🎯

כל מה שקראתם כאן הוא בדיוק סוג החומר שמפריד בין מי ש"מכיר את הכפתורים" לבין מי שבאמת מנהל תשתית ארגונית. בקורס System Administrator של מכללת נטמי אתם בונים מעבדה אמיתית משלכם: מתקינים Windows Server 2025 מאפס, מקימים Domain Controller נוסף, שוברים ומתקנים רפליקציה, קוראים רשומות SRV ב-DNS, מגדירים GPO, כותבים PowerShell לאוטומציה ומתרגלים תקלות אמיתיות מהשטח — אותן תקלות שיושבות בראיונות העבודה וביום הראשון בתפקיד.

• ▸🎥 קורס מלא בעברית, כולל הקלטות וגישה לכל החיים.
• ▸🧪 מעבדות מעשיות — לא מצגות: AD, DNS, DHCP, GPO, PKI, WSUS ו-PowerShell.
• ▸🧭 ליווי מקצועי ומענה לשאלות לאורך כל הדרך.
• ▸💼 הכנה לראיונות עבודה בעולם ה-IT והסיסטם בישראל.

אדמין טוב לא זוכר פקודות בעל פה — הוא מבין מה קורה מתחת למכסה המנוע, ולכן יודע לאן להסתכל כשמשהו נשבר.