A valósággal való minden hasonlóság pusztán a véletlen – és a figyelmetlenségem – műve. Habár az írásnak van valós alapja, de nem az a szándékom ezzel a történettel, hogy bárkit is lejárassak – ezért időnként szándékosan ködösítek egy kicsit. Nem anyázni akarok, hanem naplószerűen leírni, hogyan tud félremenni egy projekt, ha az ember nem tartja vasmarokkal. Vagy legalábbis nem szabályosan akarja megfogni.

A helyi erők a migrációt már elvégezték. Amikor odakerültem, már minden kongott az ürességtől.
Az összeszorított fogak közül kiszüremlő kifejezések ennek ellenére már az első körülnézéskor előbukkantak. Ha azt mondom, hogy a megszűntetendő tartomány ebek harmincadján volt, akkor finom voltam. Tartományvezérlő, melyet egyszerűen csak kikapcsoltak és újratelepítettek máshol. Ugyanez Exchange szerverrel is. Az egyetlen fizikailag létező Exchange szerver külön Routing Groupban volt. Némileg cifrázta a helyzetet, hogy a Routing Group Connector-t viszont másfél éve lebontották. A postafiókokat pst-kkel lapátolták át. Kismillió public folder. Szükség van rájuk? Persze! – jött a válasz.

Visszaépítettük az RGC-t. Kismillió replikációs konfliktust jelző levél söpört végig napokon keresztül a levelező szervereken. (Ugye tudjuk, a public folderek a két replikáció közötti párhuzamos módosítások esetén nem az időbélyeg alapján döntik el, melyik módosítás a frissebb, hanem levelet küldenek mindkét módosítónak, hogy csókolom, tessék leharcolni egymás között, kié legyen az érvényes. És itt volt másfél év, replikáció nélkül.)

Végül mindegyik folderről született replika másik szerveren is, így levehettük a példányokat a megszűntetendő szerverről. Ez már csak napok kérdése volt. Az IT vezető itt kezdte el rágni a kefét, hiszen az egész tartománytörlésre egy nap volt ütemezve.
De végre eltűntek a public folderek, lehetett eltakarítani az Exchange szervereket. Rögtön az elsőnél földön koppant az állam: az Add/Remove panel szerint a Windows szerveren két példányban is futott az Exchange szerver. Ráadásul az egyiknek olyan verziószáma volt, mely a hivatalos táblázatok szerint nem is létezett. Fejvakarás. Megpróbáltam mindkettőt eltávolítani. Az egyiknél már a telepítő sem indult el. A másiknál elindult, de amikor azt mondtam neki, hogy mars ki, azt válaszolta, hogy “There is no such object on the server”. Azaz a kettőből elméletileg egy sem létezett. Ismerjük el, azért van abban némi kihívás, hogyan távolítsunk el egy gépről két darab nemlétező Exchange szervert. Feltettem a hegesztőszemüveget, előkészítettem a registry editort, az adsieditet és a szokásos mmc konzolomat. Csak nagy vonalakban:

  • Exchange szolgáltatások leállít
  • Exchange registry beállítások kigyomlál:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DAVEX
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExIPC
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXOLEDB
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeActiveSynchNotify
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeADDXA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAL
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeES
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeFBPublish
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMGMT
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMU
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOMA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSRS
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc
  • IIS eltávolít a gépről
  • Másik gép Exchange System Manager programjából az Exchange szerver töröl
  • AD-ból a gép kiléptet.

Egy szerverrel végeztünk. Jöhetett az utolsó Exchange szerver a Routing Groupban. Add/Remove, eltávolít… ugyanaz a hibaüzenet: “There is no such object on the server”. Eszelős guglizás. Ugyan eltávolíthatnám ugyanúgy, ahogy a másikat, de ez akkor is az utolsó szerver, legalább ezt tisztességesen kellene kirúgni. Aztán szerencsés találat, egy newsgroupban azt írják, hogy látszani ugyan nem látszik a postafiókok között, de minden szervernek van egy postmaster accountja is. A következő objektumon – CN=Configuration,DC=SUBDOMAIN,DC=DOMAIN,DC=COM\CN=Services\CN=Microsoft
Exchange\CN=EXCHANGE\CN=Global Settings\CN=Message Delivery – meg kell keresni az msExchAdminMailbox tulajdonságot. Ennek értéke mondja meg, melyik felhasználóhoz van hozzárendelve a postmaster mailbox. Ha ez megvan, akkor adsieditből megnyitjuk a felhasználó objektumát és meglessük a HomeMDB tulajdonságát. Ha ez a letörlendő szerverre mutat, akkor töröljük. Ha nincs már meg a felhasználó, akkor az msExchAdminMailbox tulajdonságnál adunk meg egy másik felhasználót.
És bejött. Egy már ezer éve nem létező service account userre mutatott az érték. Átírtam… és rögtön más hibaüzenettel állt le az eltávolítás. De ez már ismerős volt korábbról. Anélkül, hogy mélyebben belemennék, a HomeMDB értékekhez kapcsolódik egy backlink, a HomeMDBBL, abból lehet kimazsolázni a sunnyogó postafiókokat, lásd KB279202.
Most már semmi akadálya nincs az eltávolításnak. El is indult a folyamat… majd az Information Store leállítása befagyott. Hosszú várakozás után közölte, hogy oké… pedig ádehogy. Újabb fejvakarás. (Csodálod, hogy kopaszodok?) Átnéztem a szolgáltatásokat… hát ilyen nincs. El volt indítva a Site Replication Service. Natív Exchange 2000 organizációban. Az eszem megáll. Leállítottam előre minden szolgáltatást, beleértve az IIS és Winmgmt szolgáltatásokat is – és innentől már tényleg leesett a gépről az Exchange.

A többi már rutinmunka volt. Egy kicsit megpörgettem az ntdsutil-t (metadata cleanup), hogy eltávolítsam a szabálytalanul leállított DC-t, aztán dcpromo az utolsó DC-re végül egy óriási nagy takarítás az AD konzolokból, DNS-ből, WINS-ből, Exchange konzolokból.
Hajnali egy óra és már végeztünk is.

Második felvonásként rendezkedni kellett a gyökértartományban is. Az erdő szintű FSMO szerepeket birtokló tartományvezérlő… minden volt, csak nem acélos. Amennyit fagyott, attól akár Gorenje gyártmányú is lehetett volna. Olyan trükköt tudott, amilyet én még számítógéptől nem láttam: a szoftveres tükör mindkét lemeze külön-külön is látszott: az egyik C: néven, a másik meg talán V: néven. Nyilván ez így nem maradhatott. A FSMO szerepek szerencsére simán átmentek egy másik DC-re, jött volna a dcpromo. Jött is, aztán udvarias köhintéssel megkérdezte, hogy mit is csináljon a rajta lévő enterprise root CA szerverrel.
– Ez mi? – néztem meglepve a rendszergazdára.
– Nem tudom – vonta meg a vállát.
– CA szervernek tűnik – tippeltem.
– Lehet. Tudtam, hogy valahol van egy.
– Kik használják?
– ? – vonta meg a vállát.
Itt a magam részéről befejeztem a munkát. Mondtam, hogy amíg nem tudják, kik és mire használják ezt a CA szervert, addig én nem bolygatom meg. Meg utána sem szívesen, mert CA téren nem mozgok olyan biztos lábakkal. A takarításnak ezt a részét az insource vállalta be. Lementették a CA adatbázist, dcpromo le, operációs rendszer újratelepítése – a CA miatt szigorúan ugyanolyan néven – dcpromo fel, CA telepítés, adatbázis visszatöltés. Itt futottak bele egy pofonba, mert a régi CA hol a C: meghajtóra hivatkozott, hol a V: meghajtóra – amely ugyebár megszűnt. De a srác becsületére legyen mondva, ügyesen összekötözgette valahogy a szálakat. Végül visszamásztak a FSMO-k is.

Aztán jöttek a tartományvezérlő frissítések. Rendben meg is történtek. A rendszergazda éppen a drivereket telepítette fel a vacakabb, immár w2k3 tartományvezérlőre, amikor az úgy döntött, hogy elég volt neki ebből a világból. Olyan szinten szakadt össze, hogy esély sem volt feltámasztani. A fiúk vettek egy új vasat, és arra már közvetlenül w2k3 oprendszert telepítettek. És ekkor derült csak ki, hogy a CA adatbázis ugyan átkonvertálódott w2k3-ra, de az a géppel együtt elszállt. A mentésben lévő w2k formátumú CA adatbázistból meg nem lehet visszaállítani w2k3 CA alá semmit. Mivel közben a tartomány is natív lett, így elég bonyolult forgatókönyvek adódtak a visszaállításra. Olyannyira bonyolultak, hogy az IT vezető úgy döntött, inkább telepítsünk egy új CA szervert. Némileg kellemetlen, hogy még mindig nem lehet tudni, kik és mire használták a régit..
Na, mindegy, a tartomány legalább szépen működött.

  1. Bevezetés