Exchange Schema bővítés okosan

Tettünk azért elég sokat a 2000-es évek elején, hogy a Schema bővítést egy kisebb kultusz vegye körül. Nincs ez így jól. Egyik munkám okán ma egy tesztkörnyezetet kellett építenem. Lusta voltam és egy meglevő tartományomba szerettem volna telepíteni az Exchange rendszert. Ahol aztán egy érdekes problémába botlottam, ami felelevenítette a régi szép Schema bővítős időket. Szerintem másnak is hasznos lehet.

A Schema bővítés nem ördögtől való dolog. Technikailag két fő részre bontható:

• általános rész – standard ldifde segítségével LDF fájlokat importálunk és létrejön néhányúj AD tulajdonság
• speciális rész – azok a termékek amik nem azt mondják, hogy tessék itt van az LDF fájlok halmaza és importáld be magad, azok általában valami speciális setup folyamatot használnak, aminek nem mellesleg a vége az, hogy importálják az LDF fájlokat. De nem szorítkozik erre és csak erre a folyamat. Azért speciális rész ez, mert minden termék gyártója, setup írója eldöntheti, hogy itt mit szeretne csinálni.

Az emberfia megtanulta, hogy a Schema bővítés nem visszafordítható folyamat. Ez igaz, de ez így túl általános és valóban az emberek riogatására alkalmas információ. Valóban ha létrehoztál új Schema attribútumot, attól szabadulni később nehéz. De általában erre nem kerül sor. A Schema bővítésnek akkor lehet valami komolyabb hatása, ha ütköző attribútum név van. Vagyis ha a szoftver amit telepíteni szeretnél, olyan Schema attribútumot használ, amivel azonos nevű már van a címtárban. De ez sem akkora baj, nem fog tőle megállni a címtárunk, csak az új terméket nem tudod telepíteni, a Schema bővítés nem fut le.

Az Active Directory mögött ESE motor van, csak úgy mint az Exchange mögött. Itt minden tranzakció ATOMIC. Vagy megtörténik, vagy nem. Nincs félig megtörtént tranzakció. Pont.

Elég sokszor láttam a következő gyakorlatot Schema bővítés előtt:

• Schema master izolációja – lehúzzák a hálózatról, átteszik egy másik hálózatra
• általában egyéb FSMO szerepkörű gépekkel együtt, vagy ha all-in-one FSMO szerepkör van, akkor csak azt az egy gépet húzzák le
• Az izolált Schema master FSMO szerepkörön elvégzik a Schema bővítést

Ezzel pontosan az a baj mint ami a saját teszt környezetemben történt:

• Az Exchange Schema bővítés megállt a következő hibaüzenettel: “There was an error while running ‘ldifde.exe’ to import schema file….” Lebukott a drága, ez egy általános rész, nem tudta importálni az LDIF fájlt. Vajon ez Exchange hiba?
• Ha az ldifde.exe LDAP művelete nem sikerül akkor arról csinál egy ERR fájlt. Ez nem Exchange okosság, ez 14 éve így van az ldifde-vel. Írja is az Exchange szetup, hogy érdemes lenne megnézni ezt a fájlt. Hát nézzük:
• Szépen látszik benne a hiba: “The FSMO role ownership could not be verified because its directory partition has not replicated successfully with at least one replication partner.”
• Ebben semmi Exchange specifikus nincs. Az Active Directory okos. Tudja, hogy egy elosztott környezetben a replikáció mindennek a kulcsa. Ha a replikáció nem működik, akkor amit látunk az nem biztos, hogy aktuális. Márpedig ha a Schema Master izolálódott és nem tud senkivel sem replikálni, akkor mi a garancia arra, hogy időközben nem adtuk át másnak a Schema Master szerepkört? Persze, mi tudjuk, hogy ez nem történt meg, de technikailag a Schema Master aki éppen izolálódott az ezt nem tudja és elutasítja a Schema bővítést.
• Ezen a ponton a történetünk különbözik az átlagostól. Ugyanis nálam a hibát az izolálódást nem a félelem által vezérelt tudatos leválasztás okozta. Egyszerűen megfeledkeztem arról, hogy ebben a környezetben több DC-m is volt…valaha…azonban azokat már rég lekapcsoltam, kidobtam, de nem takarítottam ki őket az AD-ból. Egy repadmin /showrepl pillanatok alatt megmutatta, hogy bizony a többi DC-vel nem tud replikálni, mert: “The DSA operation is unable to proceed because of a DNS lookup failure”.

A megoldás az én környezetemben az, hogy kitakarítom az Active Directory címtárat. A megoldás a Ti környezetetekben az, hogy nem izoláljátok mesterségesen a Schema Master FSMO szerepkörű kiszolgálót a többi szervertől. Legyen mentés, legyen tartalék DC, amit lekapcsoltok, hogy egy esetleg Forest Recovery abból elindítható legyen. De ne izoláljátok a Schema Master kiszolgálót.