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 fogni.

Tesztelgettek egy kis Calendar-t, OWÁ-t, Blackberry-t, végül a helyi rendszergazda úgy döntött, hogy átmigrálja az összes postafiókot az új Exchange szerverre. Távolról – egyenesen Barcelonából – szurkoltam neki.
Amikor visszajöttem, alapvetően elégedett embereket találtam. Még működött a rendszer. Az utóbbi időben kicsit visszavettek az igényeikből.

De persze kisebb-nagyobb problémáik voltak.

Az Insource panaszkodott, hogy nem látják senkinek sem a foglaltsági információját. Meg hiába foglalnak le tárgyalókat, nem jelenik meg a foglalásuk. Ellentesztek. Mindenkinek működik. Kérdeztem a rendszergazdát, mi különleges lehet az Insource gépeken. Hosszas fejvakarás. Végül kinyögi, hogy ők külön címtárban vannak, mely össze van trustolva a cég címtárával. B+. Egy preparálatlan címtár. Pár óra vakaródzás nálam is, aztán szép lassan megszületett a megoldás: abban a tartományban nincs SCP objektum a címtárban, így nem érik el az Autodiscovery szolgáltatást. Outlook teszt, kibogarásztam, milyen DNS néven keresi a kliens a szolgáltatást. Rövid nyomozás, milyen DNS szervert is használnak a fiúk, aliasként felvettem benne a CAS-ra az autodiscovery nevet, egyből megjavult minden.

A gyerektartományba nemrég felvett úriember neve viszont nem jelenik meg a globális címlistában. Az istennek sem. Várunk vele, rugdosok mindent, nem és nem. Hazafelé már a fákat és a köveket is rugdosom, hátha az segít. (A mélypont és a lenyugvás.)
Elsőre persze a GAL-ra gyanakodtam. Végigböngésztem, mit is csinál és úgy véltem, túl bonyolult a szűrőfeltétel. Ki kellene cserélni. Szűrőcsere… mint a gépkocsikban. Végülis… elég lenne annyi kritérium, hogy legyen alias értéke az objektumnak. Nosza. Nem lehet. Ha már egyszer sikeresen módosítottad a GAL-t, akkor azt többször nem lehet. Miaf? Ez mekkora kreténség már…?
Beleástam magam a szakirodalomba. Utólag már azt mondom, megérte az a másfél nap kinlódás. Most már sokkal jobban átlátom, mi is zajlik a mélyben. (Olyannyira, hogy lett is belőle egy Technet cikk.) Végigmentem egyenként a láncon, begyorsítottam mindent, amit csak lehetett, végül megtaláltam azt is, hogy a leánytartományi RUS egy olyan GC-hez volt rendelve, melyet menetközben a rendszergazda – velem egyeztetve – megszűntetett, emiatt állt le az aszinkron frissítgetés. Ez is ki lett pipálva.

Aztán belefutottunk egy olyan szopásba, hogy van egy SQL rendszer, mely ékezetes karaktereket tartalmazó ASCII kódolású leveleket küld a leánytartomány Exchange2000 szerverére. Ott még ékezethelyesek a levelek. Aztán amint átjutnak az Exchange 2007 Mailbox szerverre, akkor teljes katyvasz lesz a levelekből. Az első gyanú a locale beállítás. Az Exchange2000 szervereken magyar és angol. Az Exchange2007-ben… default. A get-mailboxserver szerint ugyanis üres az érték. És nem is lehet módosítani, hiába próbáltam akár szöveges formában, akár decimális, akár hexadecimális formátumban beadni a magyar locale-t.
Tudomány elfogy. Bejelentettük az esetet a PSS-nek. Még mindig náluk van… de egyre inkább úgy tűnik, azt fogják mondani, hogy ez by default és RFC kompatibilis és alakítsam át úgy az SQL rendszert, hogy más karakterkészlettel menjen a levél. Az ügyfél baromira fog neki örülni. Eddig egyedül az Exchange2007 OWA jött be nekik, minden másra azt mondta, hogy sok kényelmetlenség semmiért.

Aztán egyszer csak váratlanul vége szakadt az őrületnek.
Menetközben beindult a többtelephelyes gyerektartomány tartományi migrációja, gyakorlatilag nélkülem. Ekkor már amit lehetett, azt helyi emberrel csináltatták meg – a rendszergazda meg már végigcsinált egy tartományi migrációt, látta, hogyan megy. Egyedül a DHCP okozhatott problémákat, erre megigértem, hogy majd utánanézek. Ehhez képest azért meglepődtem, hogy anélkül demotáltak egy DC-t, hogy nem szóltak, azt sem várták meg, utánanéztem-e a DHCP-nek. Aztán az üzemeltetési szempontból kritikus telephelyen egyszer csak megállt a DHCP szolgáltatás. Rövid időn belül mindenki szaladgált össze-vissza, mint pók a falon. Routermágusok vetették be magukat, eredmény nélkül. Már olyan embereket is felhívtak, akik anno a rendszert építették, csak azóta máshová mentek dolgozni. Gondoltam, én is megnézem, mit tehetnék. Rövid keresgélés után belebotlottam, hogy a telephelyi DC-re DHCP Relay lett telepítve, mely a demotált DC-re mutatott. Átállítottam az újra, beindult minden. Aztán kiderült, hogy a DNS áthelyezése sem igazán sikerült – és ekkor még igen finom voltam. Azt is rendbetettem. De már késő volt, ezt a bakit a cég már nem nyelte le. Csúnya veszekedések jöttek, indulatos ordibálások. Aztán az IT vezető írt egy körlevelet, miszerint az egész projekt műszaki tartalmáért én egyszemélyben vagyok a felelős, tehát tessék engem anyázni. Erre bepöccentem, én is írtam egy levelet, hogy a projektnek ebben a formában vége. Le fogok ülni, összeszedem, hogyan állunk, és aprólékosan meg fogom tervezni, hogyan lehet a rendszert egyenesbe tenni. Csak ez a tervezés tartott 3 hétig. Érdekes módon most már nem volt tiltakozás – pedig ekkor már negyedik hónapja(!) ment ez a projekt ilyen eszetlen tempóban.

Tanulság? Már itt is látszik. Az olcsójános technika megbosszulja magát. A durrbele-észnélkül-ügyesekvagytokfiúk_megtudjátokcsinálni mentalitás ekkora átalakításoknál nem működik. Ami több hónapos projekt, azt nem lehet hetekbe sűríteni, különösen úgy nem, hogy a tervezést hagyjuk el belőle. Ráadásul szakmailag ismeretlen terepen… Itt is látszott, még akkor is belefutottunk volna egy-egy nagyobb szopásba, ha mindent alaposan megtervezünk a rendelkezésre álló szakirodalom alapján. Ezért kell ismeretlen terepen külön időt hagyni laborkisérletre is – és az alapján kell írni a tervet. Persze nehéz akkor, ha stratégiai okból a munkát el kell vállalni, az ügyfél IT vezetője viszont nem érzékeli a munka nagyságát, nem tartja fontosnak a tervezést – aztán a végén persze mindent a külső cég nyakába varr. (Amiben persze meglehetősen groteszk módon _formálisan_ igaza van: a helyi rendszergazda és a tűzfalas ember valamikor az Ügyfél alkalmazásában álltak, aztán átkerültek hozzánk, a projekt idején teljes mellszélességgel éppen hozzánk tartoztak, de most, amikor ezt írom, már megint az Ügyfél alkalmazottai.)
Még valami. Nem tudom, ki mennyire figyelmesen olvasta el az írásokat… de talán akad egy-két ember, akiben felhorgadt valamiféle hiányérzet. Igen, sehol sem említettem meg egy nevet: azt, hogy projektmanager. Nem volt. Elfogyott. Gyakorlatilag mindkét cég úgy állt hozzá, hogy ez egy hipp-hopp upgrade, lekeverjük hamar. Én hiába küldözgettem mindkét irányba a jeleket, hogy ez így nem fasza, csak mosolygásokat kaptam: ügyes gyerek vagy, majd megoldod. Hát, nem. Kockafejűként nehéz ilyet beismernem, de egy bizonyos bonyolultság felett már szükség van dedikált PM-re. Ne a technikai embernek kelljen már a (fejben)tervezéssel meg az implemetálással küszködve még az Ügyféllel is harcolni.

Tulajdonképpen a történetnek itt vége is van. A projekt még megy, egész biztosan lesznek még benne izgalmas dolgok, de innentől már sínen vagyunk. Tervezés, döntés, implementálás – és ugyanez annyiszor, míg az átalakítás végére nem érünk. Ebből nem fogok engedni.
Ha már én lettem az egyszemélyi felelős.

  1. Bevezetés
  2. Tartományi konszolidáció
  3. Bénázás a parancssorban
  4. Az Exchange organizáció átállítása
  5. Faragások