Month: May 2005

Korábban már sokat írtam egy Exchange migrációról. Röviden összefoglalva: van egy Active Directory, ebben pedig egy több szerverből álló Exchange 5.5 organizáció, melyhez kapcsolódnak az AIX alapú rendszerek is. Az internet felé Symantec SMTP Gateway biztosítja a kijáratot.

Vázlatosan: Internet – SMTPGW – Exchange5.5 (+Outlook kliensek) – AIX.

A migráció célja a középső rész Exchange2003-ra történő cseréje volt.
Ez valamikor tavaly augusztusban kezdődött, decemberben volt a nagy ugrás és a folyamat idén februárban ért véget. Gondoltam én.
Május első hetében kaptunk egy bejelentést az ügyfél fejlesztőitől, hogy az adatbáziskezelő rendszerükből automatikusan generált levelek januári dátummal mennek ki. Megnéztem, a levél belsejében (data mező) lévő dátum tényleg rossz volt. A borítékra viszont már minden szerver a jó dátumot pecsételte rá. Visszadobtam a bejelentést, hogy tessék már egy kicsit a saját ház előtt sertepertélni, mert a levél összerakásakor történik valami a dátummal.
Megnézték a szervereik dátumait, közölték, hogy az bizony jó. Erre megírtam a kedvenc nagymamás hasonlatomat:

A nagyi remegő kezekkel odabiggyeszti levele végére a keltezést, becsúsztatja a lapot a borítékba, leragasztja, bélyeget nyal rá és feladja a postán. Szállítás közben az összes postahivatal rápecsételi bélyegzőjét a levélre. A címzett kibontja és megdöbbenve látja, hogy rossz dátum van a levél végén. Bemegy reklamálni a postahivatalba és csodálkozik, hogy a postások kórusban kiröhögik.

Azt a választ kaptam, hogy náluk fejlesztés van, nem kupleráj. Minden változtatás változásmenedzsmenten keresztül történik és az utóbbi hetekben nem változtattak semmit. Ergo az Exchange hülyült meg. Oldjam meg a feladatot. (Ilyenkor szívja a fogát egy MS adminisztrátor – ugyanis fogalma sincs arról, hogy mije változott a rendszerében azáltal, hogy szorgalmasan pecselgeti – ergo nem mondhatja azt, hogy nálam sem változott semmi, beee.)
Nos, itt már egy kicsit izzottak a vonalak, a probléma felszivárgott a középvezetők szintjére. Én váltig állítottam a saját középvezetőim felé, hogy tkp. a fejlesztők azt szeretnék, hogy mi végezzük el az ő munkájukat; a fejlesztők pedig meggyőzték a saját főnökeiket, hogy eszkaláltassák velünk a problémát a Microsoft felé, ha már mi ilyen bénák vagyunk.
Épp itt volt az ideje mélyebben elgondolkodni, hogy mi is történhet itt tulajdonképpen. A fő gubanc az, hogy a probléma két rendszer találkozási pontján keletkezik és egyik rendszer szakértője sincs képben, hogy mi van a másik oldalon. Megtettem az első lépést, megírtam a fejlesztőknek, hogy _szerintem_ hogyan működik a rendszerük. Egész jól tippeltem, alig kellett korrigálniuk: eszerint az adatok Oracle adatbázisokban vannak, ezeket AIX-en hajtja egy Oracle motor. A leveleket egy gyári Oracle modul készíti el és tolja bele szabványos SMTP-n keresztül a levelezőszerverbe – mely MX rekord alapján az Exchange2003 virtuális SMTP szervere.
Nem tehetek róla, de ha meghallom, hogy ‘szabványos SMTP’, akkor nekem mindig telnetelhetnékem van. Saját gépről kipróbáltam, nem írtam a data blokkba dátumot és ennek ellenére a levélben benne volt a jó dátum. Innentől akár fel is dughattam magamnak a nagymama-hasonlatot, mert nem igaz: ha az első SMTP host (ahol a levél készül) nem talál dátumot a data-ban, akkor beleteszi a saját átvételi dátumát – azaz a postás bizony beleír a levélbe. Közben a fejlesztők is letesztelték, hogy mi történik, ha nem raknak az adatbázisuk dátum mezőjébe semmit – a levelek gyönyörűen megérkeztek, jó dátummal.
Vov: a workaround előállt. Valahol megnyugodtam – velem együtt a főnökeim is -, mert innentől kezdve a napnál is világosabb volt, hogy a fejlesztők adnak át rossz dátumot. De a fiúk nem nyugodtak. Főnökük kifejezetten ingerült levelet küldött, hogy _ök_nem_változtattak_semmit és már napok óta levelezünk, de senki nem vette a fáradtságot, hogy letolja a képét hozzájuk. Az én agyam itt dobta le a szíjat – simogassam meg a szerverüket?! -, és mivel volt egy lezárásközeli projektem, mely akkor már a harmadik határidőmódosítást szenvedte el, megkértem a főnökömet, hogy legyen kedves, priorizálja a feladataimat. Ő is úgy gondolta, hogy inkább az egyre cikisebb projektet zárjam le, a fejlesztőkhöz meg majd lemegy egy helyi emberünk és megcirógatja őket. Helyi emberünk nem sokat tökölt: megkérdezte, kipróbálták-e, hogy mondjuk júniusi dátumot írnak az adatbázisba. Beírták, jó lett. Hoppá.
Persze az eredményt értelmezni is kellett. Íme a megoldás:
Kiderült, hogy az alkalmazásuk, melynek része a levélküldő modul is, magyar nyelvű – tehát az adatbázisban lévő dátum is magyar formában jön ki az Oracle modulból. Rakjuk csak egymás mellé az angol és a magyar formát.

Dec – Dec – oké
Jan – Jan – oké
Feb – Feb – oké
Mar – Már – bejött egy ékezethiba
Apr – Ápr – bejött egy ékezethiba
May – Máj – hoppá, ékezethiba és karakterhiba
Jun – Jún – sima ékezethiba.

Mint látható, a Microsoft SMTP szerver, amikor összerakja a leveleket, az ékezethibákat még le tudja kezelni – de az ‘y’ helyett a ‘j’-t már nem. És május elsején megzakkant a belső dátum generáló algoritmusa és a hónapot januárra javította. A fejlesztők angolra állították a kritikus dátum formátumát és egyből megjavult a májusi levelezés is.
Most akkor mégis az Exchange szerver a hülye? A látszat – és a fejlesztők is – ezen a véleményen vannak. Én – már csak a mundér becsületének megóvása érdekében is -, visszaírtam, hogy ugye tudják, hogy a levél ‘forráskódjának’ formai szabályai vannak… és ezen szabályok szerint a data SMTP parancson belül a dátum szabvány szerint angol formátumú; és nem érdekel, hogy ők, vagy az Oracle modul, de legyenek kedvesek igazodni a szabványhoz.

Viszont van itt valami, ami miatt igazából tartani kellene a pofámat: a korábbi Exchange 5.5 szerver IMS megvalósítása valahogy megbírkózott a feladattal. Gondolom, megnézte, hogy milyen nyelvi támogatások vannak a rendszerben és azok alapján próbálta meg értelmezni az ismeretlen hónapneveket.
A 2003 már bekeményített. Nyilván lehet mögé ideológiát gyártani, de tény, hogy már a sokadik sunyi változtatást szívjuk meg azzal, hogy az öreg SMTP motort a fejlett újra cseréltük.

Tegnapelőtt volt a konferencia a Lurdy-házban és éles küzdelem után én nyertem meg a cégünknél a jogot, hogy beszámolhassak róla. (Megírod, oszt pofabe!)
Ezekről a konferenciákról tudni kell, hogy nem egy előadó beszél egy nagyobb témáról, hanem több, főleg üzemeltető szakember beszél apróbb témákról.

1.előadás
Schaffer András: A szerver virtualizáció szerepe az üzemeltetésben
Gyakorlatilag a Virtual Server 2005 terméket mutatta be az előadó, a maga sajátos, utánozhatatlan stílusában. Nem gondolom, hogy túl sokat kellene beszélnem a virtuálgépes installációk előnyeiről.
Egy nagyon fontos információ hangzott el számomra: a VS2005 már támogatja a két node-os virtuális clustereket, tehát van lehetőség tapasztalatszerzési célra Exchange clustert telepíteni. (Persze kell egy erős gép is.) Jelenleg úgy adunk supportot ügyfeleknél, hogy igen gyenge az xch cluster kompetenciánk…

2.előadás
Molnár Attila: XP Service pack2 / Windows 2003 Server Service pack1
Nem igazán értettem, mit keresett _még_ mindig egy ilyen előadás a porondon, különösen úgy, hogy főleg az XP-ről beszélt az előadó, a szerverről alig esett szó.
Pár gondolatok emelnék ki:

– Netsh, SharedAccess – szkript csatlakozási felületek. Emlékezni rá.

– Memóriavédelem:
/DEP – Data Execution Prevention – megelőzni, hogy adatterületre programot lehessen tölteni. (BOF: Buffer Overflow; klasszikus cracker technika.)
/PAE – Physical Address Extension – egyfajta szoftveres bűvészkedés ahhoz, hogy 4GB-nál nagyobb memóriaterületet is tudjon kezelni a rendszer. Kicsit furcsállom, de úgy vettem ki az előadó szavaiból, hogy a /DEP-hez szükséges a /PAE beállítása is.
Saját kiegészítés:
Ezzel a két kapcsolóval több baj van, mint haszon. Korábban már foglalkoztam vele, de itt is megemlítem ezt a remek kis írást Jim McBee-től.

– A Group Policy 608 új opcióval bővült. Ha ezeket munkára fogjuk, számíthatunk rá, hogy megnőnek a GPT-ink, ezzel együtt a hálózati forgalom.

– Horror: XP SP2 telepítéséhez 2 GB szabad hely szükséges. No comment.

– Az ismert hibajelenségekről rengeteg KB cikk elérhetőségét tették be a prezibe. Ezeket nem fogom bemásolni, majd leírom, hogy honnan lesz elérhető az anyag.
Saját kiegészítés:
Az egyik cikk láttán jót vigyorogtam; ismerős volt. Az otthoni gépemről szedtem le egy, még SP2 előtt felrakott programot. A leszedés során letörlődött a Bluetooth driver is. Innentől idézet magamtól:

Oké, gyári cédé elő, BT driver/programok le, majd fel. A helyzet csak rosszabb lett. Újból leszedtem a cuccot és amíg törtem a fejem, kínomban visszadugtam a dungle-t a gép popsijába. Erre csilingelt egyet, majd rövid idő után nekiállt kéken villogni. Minden driver és program nélkül… Ekkor ugrott be, hogy az XP SP2-ben van beépített BT driver. De az is beugrott, hogy nem kicsi szívásokat olvastam már erről.
Mindkét emlék igaznak bizonyult. A legkisebb cucli még az volt, hogy az Activesync beállításakor a PDA közölte, hogy nem tud kapcsolódni, ezért nem is hoz létre ikont a kapcsolatnak. Közben persze létrehozta és jó is volt – csak nem jelent meg a listában. Amikor belefáradtam és kikapcsoltam… majd később visszakapcsoltam, 15 tök egyforma kapcsolat ikon vigyorgott a BT Managerben. És amikor kapcsolódni próbáltam, mind a 15 egyszerre próbálkozott… és mind a 15-nek egyszerre sikerült.

– A legnagyobb horror: májusban jött ki az a bizonyos MS05-019 biztonsági folt, melynek van egy olyan kellemetlen mellékhatása, hogy eltérő MTU-k esetében nemes egyszerűséggel megszünteti a hálózati kommunikációt. És ez a remek patch bele lett építve a Windows 2003 Server SP1-be.
A Microsoft adott ki hozzá javítást, de ez csak reaktív: tehát csak akkor kaphatod meg (MPS, vagy Hotline), ha tényleg behalt a szervered. Az ügyfelek véleményét nem kérdezték meg. (Bár az előadó megjegyezte, hogy most, ebben az esetben, esetleg, kivételesen, lehet, hogy engedményt tesznek és meg lehet proaktívan is igényelni a javítás javítását. Bravó. 5 perces tapsvihar.)

3. előadás
Harmath Zoltán: Active Directory Schema
Ez igazából egy bevezető előadás volt. Zoli egy szigorúan elméleti előadásban tisztázta, hogy mi is az a séma, mik az alapfogalmak és hogyan épül fel. Sok újdonság nem volt benne, de jól összefoglalta.

4. előadás
Kurucz György: Hogyan készüljünk a Windows Server 2003 schema-ra?
Határozottan tetszett, ugyanis nem állt le annyinál, hogy AD, oszt bővítsünk, hanem kifejezetten kitért arra is, hogy mi van akkor, ha Exchangek is bóklásznak a rendszerben.
Számunkra már nem volt benne nagy újdonság, ugyanis mi tavaly nyáron kidolgoztuk – a Microsoft segítségével – a biztonságos sémabővítés menetét. Most ugyanez hangzott el nagyközönség előtt. (Gyakori hibák, tervezési szempontok, rollback, a sématerjedés bekerítése.)
Megemlített egy hasznos utility-t: Setpwd.exe; akkor kell, ha már mindenki lelépett a cégtől, aki emlékezhetne a szökőévenként használt Active Directory Restore mode jelszóra.
Saját megjegyzés:
Volt egy kis hiba is az előadásban. Gyuri felhívta a figyelmet, hogy sémabővítés előtt feltétlenül csináljunk egy system state mentést. A helyzet az, hogy pont tavaly kellett az utolsó pillanatban lefújnunk egy sémabővítést, mert a start előtt egy nappal találtam egy cikket, miszerint a system state mentés NEM tartalmazza a sémát.
http://support.microsoft.com/default.aspx?scid=kb;en-us;241594

There are certain parts of Active Directory that cannot or should not be restored in an authoritative manner:
– You cannot authoritatively restore the schema.

5. előadás
Mészáros Kornél: Exchange 2003 Database Recovery
Jó előadás volt, a téma is, az előadó is kiemelkedő volt. Kornél először összefoglalta, hogy hogyan történt 5.5, 2000 alatt egy levél(!) visszaállítása és ez jó alap volt ahhoz, hogy bevezethesse a 2003-ban debütált Recovery Storage Group (RSG) működésének ismertetését.
Gyakorlatilag azon a folyamaton ment végig, amit mi a rendszeres éves visszaállítási bajnokságon el szoktunk játszani.
Újdonság volt számomra a Messaging Dial Tone Recovery módszer. Ennek az a lényege, hogy minél hamarabb állítsunk vissza egy már használható rendszert és utána időzítsük a visszaállítás időigényesebb lépéseit. Exchange esetében ez azt jelenti, hogy első körben visszaállítunk egy szervert, üres postafiókokkal. Ezen már tudnak levelezni a felhasználók. Második lépésben visszaállítjuk a postafiókok előzetes tartalmát (ekkor látszólag elvesznek az időközben keletkezett levelek), majd harmadik lépésben beledolgozzuk a tranzakciós logokból az időközbeni leveleket – és kész. Ügyes módszer, de türelmes, megértő és értelmes felhasználókat feltételez – azaz gyakorlatilag használhatatlan. (Először mindenkinek el kellene magyarázni, hogy igen, meglesznek majd a leveleik, csak ideiglenesen üres a postafiók; később ugyanúgy el kellene mindenkinek magyarázni, hogy igen, meglesznek majd az időközben írt leveleik, csak ideiglenesen nem látják.)
Saját megjegyzések:
– Az előadó külön kiemelte, hogy visszaállítás után fontos a RSG minél hamarabbi eltávolítása. Ehhez csak csatlakozni tudok: egy ügyfélnél otthagytuk pár hónapig a VIP adatbázis visszatöltött példányát és az a csúfság esett meg, hogy az időközben letörölt VIP felhasználók (mailbox törlés, felhasználó disabled-be téve) valahogy rátaláltak az RSG-ben lévő adatbázisra, ahol nem volt törölve a postafiókjuk – és nagy boldogan összerendelték magukat velük. Ebből kifolyólag később már nem lehetett törölni az RSG-t, mert azt írta, hogy az adatbázis használatban van. Végül egy ADSI script segítségével szedtem össze, hogy kik kapcsolódnak az RSG-beli adatbázishoz és így sikerült leverni a zombik lázadását.
– Kornél szépen elmagyarázta, hogy abban a pillanatban, amikor új RSG-t hozunk létre, a backup API erről értesül és a visszatöltés az adatbázis eredeti helye helyett az RSG lesz. Ezt egészíteném ki azzal, hogy ez a viselkedés registry-ből állítható. Visszaállítás teszt idején ugyanis szükségünk volt arra, hogy bizonyos adatbázis a helyére, bizonyos adatbázis meg az RSG-be kerüljön. Ekkor izzadtuk össze az Internetről a következő beállítást:

HKLM\System\CCS\Services\MsexchangeIS\ParametersSystem
Recovery SG Override [Dword]
1 – Nem a Recovery Storage Groupba teszi
egyéb – Recovery Storage Groupba teszi.

6.előadás
Fischer Péter: Hasznos holmik
Ebéd után szokás szerint Fisó következett: az ő dinamikus, harsány előadásait félálomban is lehet követni. Olyan eszközökről beszélt, melyeket minden rendszergazdának állandóan magánál kellene tartania. Két ilyen eszközt emelnék ki:
– MPS riportok
Ez már rég célkeresztben volt a cégünknél. Szó volt róla, hogy lessük el, milyen eszközökkel végzi nálunk a monitorozásokat az MS. Össze is szedtem az AD illetve Exchange készletet, de itt az előadáson tudtam meg, hogy ezek a cuccok a Microsofttól is letölthetőek – naprakészen -; és a korábban említett eszközökön kívül a következő csomagok is léteznek: Alliance, Cluster, Network, Setup, SUS, MDAC. (Zárójelben jegyzem meg, hogy aki idáig elolvasta ezt az írást, az egy krumpli.)(1)
– Admodify.net
Ez egy olyan utility, melyet az Exchange team fejlesztett ki magának, de később mások is ráéreztek, hogy nagyon jól használhatják. Gyakorlatilag AD objektumok nagy tömegű változtatására alkalmas. Ez önmagában nem nagy dolog, hiszen erre jó az LDIFDE is – viszont ez a progi grafikus felületű és a változtatások visszagörgethetők. Szintén letölthető.
Saját megjegyzés:
Két lehetséges felhasználás jutott az eszembe:
– Rátóton nagyon leegyszerűsíthető vele az adminisztráció: a template-be beírjuk, hogy a keresztnév ‘Béla’ és ezt ráengedjük a teljes adatbázisra.
– Exchange-ben recipient policy visszavonása. Eddig ugyanis ha rátettünk az adatbázisra egy olyan policy-t, hogy a felhasználók egy körének ossza ki a %username%@csihu.hu címet, akkor ezt már nem tudtuk azzal visszacsinálni, hogy töröltük a házirendet. Viszont az admodify.net segítségével meg lehet szabadulni ezektől a címektől.

7.előadás
Sárosi György: Mi történik a házirendemmel?
Innentől indult a mélyrepülés. Ez egy nagyon rövid előadás lett volna egy hosszabb demóval, de a gépre nem volt telepítve gpmc, így a demó nem indult el. Ehelyett lehetett pár percet bóbiskolni.

8.előadás
Peti Sándor: Hasznos segédprogramok Systems Management Server 2003-ban
Különböző segédprogramokról beszélt, melyekkel nyomonkövethető, hogy mi is történik éppen az SMS rendszerben. Ezeket csak felsorolnám:
– SMS Trace
– SMS MPTroubleshooter
– SMS Advanced Client Troubleshooting Tool
Innen tölthetők le.
Megemlített egy szkriptet is, melyet arra izgattak fel, hogy a 90 napnál régebben kikapcsolt gépeket legyűjtse. Ezek a diák kimaradtak a preziből, majd valamikor felteszik az Üzemeltetői Konferencia oldalára.

A következő ismertetés előtt jelzem TankoP-nek, hogy kérem, kapcsojja ki. Köszönöm.

9.előadás
Durucskó Zoltán: MSI készítése mindennapi használatra
Igazából itt kellett volna a fejeken keresztül előre másznom és az első sorban csápolni a TAM-unknak, de mivel késve érkeztem meg, így csak az utolsó sorban jutott hely – innen azért feltűnő mutatvány lett volna.
Pedig Zolira ráfért volna a biztatás, mert bár a témája jó volt (legalábbis kellően egzotikus), de az előadás igen félrement: izgult, dadogott, elharapta a mondatok végét, nem bontotta ki rendesen a szálakat.
Az előadás arról szólt volna, hogy hogyan lehet meglévő msi fájlt széttúrni (orca.exe, a letölthető Platform SDK része), illetve hogyan lehet egy msi-t újracsomagolni, a nekünk megfelelő formára (Admin Studio SMS edition). Itt külön tetszett, hogy ez statisztikát is adott a telepítés közbeni változásokról. Példaként Zoli az Acrobat Reader5.0 msi-jét csomagolta be egy másik msi-be és a végén láttuk, hogy az Acrobat többek között hétszázvalahány bejegyzést karcolt bele a registrybe.
Szó volt még a telepítőcsomagok készítésének kétféle módjáról:
– Pillanatfelvétel: előtte/utána rendszerfényképezés, a különbözet az msi.
– Monitorozás: telepítés közben minden változás feljegyzése, a lista az msi.

A nyomtatott füzet mellé nem adtak CD-t. Azt mondta az előadó, hogy egy-két héten belül mind a prezentációk, mind a videók felkerülnek a http://www.microsoft.com/hun/events/default.mspx oldalra.

Megjegyzések:
1. Természetesen a céges ismertetőben nem voltak hivatkozások a blogomra. Nem akarom összekeverni a dolgokat.
2. (1) – Ezt a sort tényleg beleraktam az ismertetőbe. Úgy gondolom, ha arra köteleztek, hogy írjak egy részletes beszámolót, akkor én is kíváncsi lehetek arra, hogy tényleg végigolvassa-e valaki.
Eddig egy visszajelzés történt: főnököm főnöke megköszönte a rendkívül alapos és mintaszerűnek tekinthető írást. Körlevélben.