Újabb Exchange esettanulmány

Ügyfél szeretné, ha meglévő Exchange 2003 Sp1 szervereire Sp2-t telepítenénk. Nem egy nagy dolog, mondhatnád. Csakhogy. A hálózatuk meglehetősen cifra, benne az Exchange organizáció szintúgy.
– Mekkora a valószínűsége, hogy félremegy a telepítés? – kérdezték.
– Minimális – válaszoltuk.
– És ha mégis félremegy, mekkora a kár?
– Nem vészes. Uninstall, oszt jól van.
– Akkor csináljátok.
Mindez volt tavaly ősszel. Ugyanis mielőtt nekiugrottunk volna, megnéztük, hogy tényleg van-e uninstall. Nem volt. Sőt. Azt mondta a silabusz, hogy ha egyszer felraktad, akkor az már odanőtt; nem szedheted le. Azaz ha félremegy a telepítés és azt hiszi az Exchange, hogy már fent van az Sp2, pedig igazából nem – nos, akkor elég hülyén járunk.
– Kedves Ügyfél, ezt benéztük. Nincs uninstall – kezdtük beadagolni a keserű pirulát.
– Akkor most mi lesz?
– Majd kitalálunk valamit.
– Az jó lesz, mert rollback elképzelés nélkül coki.

Azaz előállt a feladat: csináljuk meg azt, amit a Microsoft szerint nem lehet.

A legjobb módszer ilyenkor gondolkodni egy cseppet. Mit csinálhat egy service pack? Egész biztosan lecserél egy csomó binárist. Hol lehetnek ezek? A ‘program files/exchsrvr’ könyvtárban tuti, és tudjuk, hogy a mapi32.dll meg a system32-ben van, tehát ez a könyvtár is érintett. Mi lehet még? Hát, van még ugye a szerver konfiguráció – csakhogy ez nem az Exchange szerveren tárolódik, hanem a címtár konfigurációs névterében. Igen, abban amelyből egy darab van az egész erdőben. Séma? Nem, nem kell semmilyen séma preparáció, tehát ahhoz biztosan nem nyúl. Adatbázis? Nos, igen. Ez sarkalatos kérdés.

Azaz, ha vissza akarjuk állítani az esetlegesen félrement sp2 telepítés előtti állapotot, egész biztosan mentenünk kell a binárisokat és a konfigurációs névteret. A sémát biztosan nem kell, az adatbázisról – és hozzá kapcsolódóan a domain névtérről viszont nem tudunk semmit.

Teszt.

Virtuális tartományban virtuális Exchange szerver. Sp2 telepítés előtt összes Exchange szolgáltatás lestoppol, telepítés közben a másolandó fájlok útvonala meredten figyel. Az eredmény mindenképpen kellemes: a telepítőt nem zavarta, hogy nem éri el az adatbázisokat, ergo nem is bántja őket. A binárisoknál pedig csak a fenti két könyvtár érintett.

Körvonalazódik a megoldás. Hogy elkerüljük a felesleges replikációhullámokat, a félisten repadminnal leállítjuk az Exchange szerver logon szervereként szolgáló tartományvezérlőn a kifelé menő replikációt, csinálunk egy system state mentést a DC-n, csinálunk egy fájl szintű mentést az Exchange szerveren, majd jöhet a service pack. Hiba esetén visszatesszük a binárisokat, egy non-authoritative restore a lezárt DC-n – és kezdhetjük előlről.

Újabb teszt.

Ilyenkor jön jól a virtuális környezet, ugyanis az előző virtuális tartomány gépeit előrelátóan elmentettem, még a kísérlet előtt.

Replikáció leáll, sp2 felmegy. Nézzük, mit látunk? Nézni nézzük, de nem hisszük – telepítés után az ESM azt mondja, hogy továbbra is csak az SP1 van fent. ADSIEdit-tel megnéztem a tartományvezérlőket – és ledöbbentem. A telepítő nem a logon szerveren tárolt címtáradatbázis konfigurációs névterébe írt, hanem egy éppen arra járó kósza tartományvezérlő adatbázisába. Visszakeresni viszont a logon szerveren keresett. A replikáció meg ugye fejbe volt csapva.
Azannya. Akkor az izolációnak lőttek. Szerencsére létezik fa/objektum szintre korlátozható autoritatív visszaállítás is, amelynek tulajdonképpen mindegy, mit történt a többi tartományvezérlőn – csak éppen így majd lesz két erős replikációhullám az erdőben.

Végső teszt.

1. Az összes Exchange szolgáltatás leállít.
2. Az összes virnyákölő szolgáltatás leállít.
3. Mentés az Exchange szerveren a fenti két könyvtárból.
4. System state mentés egy közeli tartományvezérlőn
5. Servicepack2 hopsza, felugrik.
6. Megvárjuk, amíg a replikáció szétterjed.
7. ADSIEdit-tel ellenőrzés az összes DC-n. (Exchange server objektum, version tulajdonság. Hogy melyik szám mit jelent, itt találod.)
8. Jöhet a visszaállítás. Binárisok visszatöltése az Exchange szerveren. Fontos, hogy a szolgáltatások még mindig állnak, tehát az adatbázis könyvtár még érintetlen.
9. Tartományvezérlő újraindít, Directory Service Restore üzemmódban.
10. Ideges kapkodás, hogy hová is írtuk fel évekkel ezelőtt a DC lokáladmin jelszavát.
11. System state mentés visszatöltése.
12. A konfigurációs névtér autoritatívvá jelölése:
    – ntdsutil elindít, megkapjuk a promptot,
    – beírjuk, hogy ‘authoritative restore’,
    – majd azt, hogy ‘restore subtree „CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=cegnev,DC=hu”‘
    – felírjuk, hogy hová gyártott az ntdsutil az ldf segédfájlokat,
    – quit.
    Ide elkél némi magyarázat, legalábbis a segédfájlokkal kapcsolatban. Egyszer már írtam az ún. Linked Value tulajdonságtípusról – itt is erről van szó. Egész egyszerűen van néhány olyan tulajdonság(backlink) a konfigurációs névtérben, melyek értékei más – esetlegesen más névtérben lévő – objektumtulajdonságok értékeiből állnak össze. Ezeket az értékeket az ntdsutil roppant intelligensen kiteszi egy ldif fájlba.
13. Újraindítjuk a tartományvezérlőt, normál üzemmódban.
14. Elindítunk egy replikációs hullámot: repadmin /syncall dc.cegnev.hu /e /d /A /P /q. (Ez ugyan lereplikál mindent, de csak a konfigurációs névtér lett autoritatív, a séma ugye intakt, a domain névtér meg normálisan replikálódik.)
15. Végül visszatöltjük a backlink értékeket: ldifde -i -k -f fájlnév.ldf
16. Szépen megvárjuk, amíg a replikáció elvégzi a dolgát. Leellenőrizzük mindegyik tartományvezérlőn, hogy a verziószám visszaállt Sp1-re.
17. Biztonság kedvéért Exchange server újraindul, teszt levelezés, pihentetés.
18. Végül Sp2 telepítés, megeszi-e. Megette.

Nos, ennyi. Ez már megnyugtatónak tűnt, nekikezdhettünk.

Természetesen végül nem volt semmilyen probléma.

ps: A fenti recept Windows Server 2003 Sp1 operációs rendszerű tartományvezérlők esetén működik! AD2000 esetén jócskán más a metódus.