Korábban már pedzegettem, most ki is fejtem, mire gondoltam.

Gondolom, vagyunk többen is, akik már módosították valamilyen Active Directory sémáját. Nem egy nagy ügy, a megfelelő jogosultsággal be kell lépni a megfelelő gépen és a parancssorból le kell futtatni egy programot, melynek valamilyen *prep-re végződik a neve. (Na jó, van amikor egy kapcsoló végződik prep-re.) Tudom, mindenki tudja, de legyen kerek az írás: a megfelelő jogosultság enterprise admin/lokális admin/schema admin jogosultságból áll, a megfelelő gép pedig az erdő Schema Master FSMO szerepkörével bíró tartományvezérlője. A többi DC-n a séma csak olvasható.

Szóval ennyi. Természetesen van egyszerűbb címtár és van bonyolultabb. Habár elég kicsi az esélye, hogy egy Microsoft termék okozta címtárbővítés gondot okozna, de még ebben az esetben is jobb óvatosnak lenni, különösen az összetettebb címtárak esetén. Saját sémabővítésnél meg aztán végképp.
Tehát a szokott rutinnal csinálunk egy System State mentést a DC-ről, ellenőrizzük, hogy megvan-e valahol az Active Directory Restore módhoz szükséges jelszó - és mehet is a preparálás.
Többféle végeredmény is elképzelhető. A legtöbbször nincs semmi probléma, a módosítás lefut, elterjed. De ha baj van, akkor nagy a baj: ugyanis ekkor derül ki, hogy a System State mentés a sémát _nem_ tartalmazza. Adtunk egy pofont a fekáliának.

Valami más stratégiát kell kiötölnünk, ha biztonságosan szeretnénk sémát módosítani.
Mielőtt persze stratégián gondolkodnánk, analizálni is illene a helyzetet. Hol merülhetnek fel problémák?
Alapvetően két helyen.

• Rosszul módosul a séma a Schema Master gépen.
• A replikáció során sérül meg valamelyik DC lokálisan tárolt példánya.

Akármelyik eset ellen is szeretnénk védekezni, mindenképpen látszik, hogy csak a replikációba történő beavatkozással érhetünk célt. Az első esetben például úgy, hogy lehetőség szerint elszigeteljük a Schema Master-t - és csak akkor oldjuk fel a blokádot, ha a módosítás rendben megtörtént. A második esetben pedig úgy járunk el, hogy a sémát apró lépésekben eresszük rá a címtárra.
Hol lehet belenyúlni a replikációba? Például a site határokon: a site-site konnektoron beállítjuk, hogy a Schema Master gépet tartalmazó site elszigetelődjön. Mielőtt ez megtörténne, még beteszünk egy harmadik DC-t a site-ba (remélem, kettő azért van site-onként), beléptetjük, megvárjuk, míg erdő szinten lemegy a replikáció - majd lekapcsoljuk a gépet. Jön az elszigetelés, séma update. Ha jó, akkor jó. Ha rossz, akkor lekapcsoljuk mindkét DC-t, a tartalék gépet visszakapcsoljuk, majd seize az összes FSMO-ra, amely a korábbi két DC-n volt. Ezeket pedig visszaállítjuk valahogy: vagy újratelepítjük és úgy tesszük vissza a System State mentésből a lényeget, vagy mentésből rakjuk vissza az egész gépet - ez eszköz és rákészülés függvénye. Arra kell csak nagyon vigyáznunk, hogy amíg rossz állapotban van a két DC, nehogy összetalálkozzanak az ideiglenesen berakottal. Nem egészséges, ha több gép is azt hiszi magáról, hogy ő a FSMO.
A séma terjedését ugyanezzel a trükkel lehetett terelgetni. Mindig csak egy elszigetelt site-ra engedjük rá, aztán ha rendben lement, akkor mehetünk tovább.
Figyelem: a fentebb írott szöveg nem konkrét recept, inkább csak elv. A valóságban ritka az olyan tiszta helyzet, mint amelyet példának választottam: lehet több DC is a site-on, tartományok is átnyúlhatnak más site-ra, az sem mindegy, milyen FSMO szerepek vannak a konkrét site-on. Minden konkrét esetben az adott címtárra vonatkozó stratégiát kell kidolgozni.

No, tehát nagyjából ez volt régebben a helyzet. A régebben kifejezés alatt azt értem, hogy azelőtt, mielőtt megismertem volna a repadmin segédprogram +DISABLE_OUTBOUND_REPL kapcsolóját. Ez ugyanis azt tudja, hogy a konkrét gépen, melyen begépelem, leállítja a kifelé menő replikációt. (A - jellel meg újraengedélyezi.)
Gondoljuk végig. Eddig site szinten izoláltunk - mostantól tudunk DC szinten is. Első lépésben bőven elég elkülöníteni a Schema Master gépet. Ha nem sikerül a művelet, akkor lekapcsoljuk a gépet, valamelyik lábon álló DC magához ragadja a kidőlt masina FSMO szerepeit, majd visszaállítjuk az eredeti Schema Mastert és lehet újra próbálkozni. Telephelyenként is megtehetjük, hogy először a bridgehead szervereket frissítjük, majd utána a többit - azaz mindig lesz élő DC, aki képviseli a tartományt.
Remek.

Nem. Kávét főzni sajnos nem tud.
Meg egyébként is, az a netsh dolga.