MonthNovember 2006

Kleine szívás, gute szívás

Tulajdonképpen ez az írás valamennyire kapcsolódik Al hozzászólásához. Az ember ugyanis nem úgy utál meg egy terméket vagy egy gyártót, hogy egyszer belefut egy kellemetlen hibába – az általánosabb utálathoz sokkal inkább tömérdek apró bosszúságon keresztül vezet az út.
Olyanon, mint amilyenbe pl. ma este is belefutottunk.
Egy ügyfelünk meglehetősen cifra címtárának forest root tartományát állítottuk át Windows2000-ről Windows2003-ra. (Már céloztam erre a melóra.) A tartományvezérlők HP blade szerverek.
Nyilván a munka oroszlánrésze (büdös vagy és ordítasz) az előkészítő munka volt. Összeszedtünk mindent, kezdve a megfelelő Support Pack-tól a legapróbb információig. Többek között tudtuk, hogy amennyiben a hálókártyák teamingben vannak, akkor inplace upgrade előtt szét kell őket szedni. És még számtalan apró trükköt tudtunk – de tényleg nem akarok túl sokáig ezzel macsózni.
Kezdtük a jó öreg forestprep-pel.

Megjegyzés:
Isten áldja, aki kitalálta a ‘repadmin /options +DISABLE_OUTBOUND_REPL’ parancsot. Eszméletlen mennyiségű munkától kímélt meg bennünket. Ha lesz időm, akkor majd a Technet blogba meg is írom, mi a hálálkodás lényege.

Mint a mesében, minden simán lement. Replikáció – mint kés a vajban. Alig telt el másfél óra és az ország legeldugottabb sarkában is ott vigyorgott az új séma. Jöhetett az upgrade. Távoli gépre rámásolva az i386 könyvtár, ILO porton keresztül belépve a winnt32 elindítva. Elméletileg ennek a kezdeti érdeklődés után minden interakció nélkül le kellett volna futnia. Elméletileg.
Éppen amikor kezdett gyanús lenni, hogy minden túl szépen megy, beütött a ménkű.
Feljött egy ablak, hogy a program hiányol egy francseemlékszikanevére.sys állományt egy Compaq Network Teaming Disc nevű médiáról. Alul egy browse jellegű menü, felette a lehetőségek: OK vagy Cancel.
Zavartan néztünk egymásra a kollégámmal.
– Istenbizony nem voltak teamingben a kártyák – mentegetőztem.
– De a teaming fel van telepítve… – szögezte le.
– Igen. De ki volt kapcsolva.
Vakaróztunk rendesen. A kérdéses DC nagyjából a legfontosabb DC volt az erdőben. (Azzal illik kezdeni.) Schema Master, Domain Naming Master… meg fontos replikációs csomópont.
Értelemszerűen ilyen telepítő médiánk nem volt. Lévén este kilenc után, az se volt valószínű, hogy be tudunk szerezni egyet. Azaz az OK gomb kiesik – marad a Cancel gomb. Belegondoltál? Egy marha bonyolult erdő legfontosabb tartományvezérlője behal inplace upgrade közben.
Nyilván megvoltak a rollback stratégiáink. Innen tudtuk, hogy ha ezt a DC-t – pontosabban a funkcióit – elő akarjuk varázsolni a semmiből, akkor kényelmesen megtekinthetjük majd az ablakból azokat a hajnali kukafosztogató egyetemistákat, akik még éppen megelőzik a hajléktalanokat.
Főnökünk volt olyan balszerencsés, hogy pont ekkor telefonált ránk, hogyan állunk. Nem adhattunk mást, csak mi a lényegünk. Még a telefonon keresztül is érzékelni lehetett, hogyan nyúlt meg az orra.
Természetesen nekiálltunk felszántani az Internetet. Én megpróbáltam a HP oldaláról közelíteni, kollégám pedig guglizott. Mondanom sem kell, hogy én egy abszolút érdektelen oldalra jutottam, ő viszont talált egy érdekes doksit.
Idézek belőle:

If you have Compaq Network Teaming installed, see the informations below:

  • During the Installing Network phase, the installation stops (approximately with 32 minutes left of the install to complete) and a dialog pops up specifying Insert Disk (see actual message below.)
    Please insert the compact Disk labeled ‘Compaq Network Teaming Disk’ into your CD-ROM and then click ‘OK’.
  • When dialog pops up, click Cancel for the installation to proceed. After this point, the installation proceeds uninterrupted until it is complete.

Gondolj bele azoknak az embereknek a lelkivilágába, akik szerint ez így korrekt megoldás. Nem, nem teszünk ki az ablakba egy ’skip’ gombot. Nehogymár. Szarjon csak be az a rendszergazda, hogy ha nyom egy Cancel-t, akkor lesz egy installálás közben ábrándosan félbehagyott, használhatatlan szervere. Hogy esetleg ki is írhatnánk valami információt az ablakba? Ugyan már… nyomd meg öcsém a gombot, ha bátornak érzed magad!
Természetesen ez volt a megoldás. Megnyomtuk a Cancel gombot, a telepítés pedig – a félbeszakítási szándékunkon jót derülve – simán lefutott.

Ez messze nem volt hetedhét határra szóló szívás. Olyan aprókára sikerült. De mögötte ott van egy olyan mentalitás, melyet nem tudok elfogadni. Hiába jók általában a HP vasak, hiába dicsekedhetsz szép nagy uptime értékekkel – az ilyen pofonok jobban megmaradnak az emberben. Különösen, ha nem csak egy termékcsaládnál találkozik ezzel a felelőtlen trehánysággal.

Lurdy már megint

Kicsit rossz szájízzel indult. Kilenckor elkezdődött a regisztráció, ellenben a terem ajtaját csak negyed tíz körül nyitották ki. Nem volt túl kellemes közel negyedórát ácsorogni a levegőtlen, fülledt folyosón a tömegben, tudva, hogy túl sok ok nem lehet a terem zárvatartása mögött.

Aztán jött az első előadás. Vista deploying. Ha egy szóval kellene jellemeznem, azt mondanám, hogy nyögvenyelős. Volt egy demó, mely végigvonult az előadáson – egy demó, melyet baromira nem értettem. Nem a tartalmát, hanem az időzítését. Az előadó rögtön a demóval kezdett szöszmötölni, bebootolt egy gépet, nézhettük a csíkot, aztán elindított egy telepítést. Az egész lassú, álmosító volt – és a lényeg, hogy rosszul időzített. Demózni akkor kell, ha az előadó már megszerezte a hallgatóság figyelmét… akkor, amikor már bírja a szimpátiájukat. Akkor, amikor már lefárasztotta a jónépet új információkkal és aktív pihenésként máshogy szeretné terhelni a hallgatóságot. Ehelyett rögtön ez a szöszmötölés, amikor még semmi nem volt, se figyelem, se szimpátia, se lefáradás – lúzerszagú volt. Ráadásul, mint később kiderült, az egész demó lényege az volt, hogy _nem_ történt semmi – azaz az előadó annyira kipreparált egy Vista telepítést, hogy az nem kért semmit, csak felhasított. A gyakorlatban ez úgy nézett ki, hogy az előadás vége felé ránéztünk a konzolra, majd az előadó bejelentette, hogy ta-dam, itt a Vista, a demónak vége. (”Hű, de szép!” – lelkesedett Feri bácsi blazírtan az első sorban.)
Nem kicsit néztem furán. Engem speciel sokkal jobban érdekelt volna, ha azt demózta volna le az előadó, hogy _hogyan_ jutott el a telepítés kezdetéig. Istenbizony a zavartalan telepítést elhittem volna neki becsszóra.
Akkor nézzük, mi maradt meg az előadásból.

  • WIM: Windows Image Format
    AZ egész image alapú klónozás alapformátuma. Habár nem egészen image alapú, hiszen fájlokról van szó, megörökölve a ’single instance’ elvet a RIS-ből – de mégis egy fájlként mountolható.
  • WAIK: Windows Automated Installation Kit
    Letölthető programcsomag, melyben egy csomó segédprogramot találhatunk. Ezekkel lehet összeszögelni a tulajdonképpeni automatikus telepítést.
  • ImageX: Segédprogram, a WAIK része. Ezzel lehet mountolgatni az image-eket, azaz tkp. kezelni a telepítőkészleteket.
  • WinPE – Régi ismerős. Egy lebutított oprencer, mellyel bootolva kapunk egy promptot, melyen belül egyszerűbb feladatokat tudunk elvégezni. Ideális segédprogram telepítések indítására. Szintén benne van a WAIK-ban.
  • Unattend.xml: A korábbi rendszerekkel szemben a Vistá-nál már csak egy szöveges fájl létezik – és ez sem igazán szöveges, hanem xml. Gondolom, nem kell bővebben elmagyaráznom.
  • WSIM: Windows System Image Manager: az előbbi xml fájlt szerkeszthetjük notepad-del is (de csak ha 12 éle van a fejünknek) – és használhatjuk ezt a segédprogramot is. (Szintén a WAIK része.) Tulajdonképpen grafikus felületen állíthatjuk össze, mi mindent szeretnénk az unattend fájlban viszontlátni.
  • Windows Deployment Server – az a szerveroldali alkalmazás, mely ezt az egész automatikus telepítést levezényli, a konfigurációk alapján.
  • BDD (Business Desktop Deployment) – nagyvállalati telepítési módszertan, kliens oldali operációs rendszerekre.

És akkor megint morgok, mert már régen tettem ilyet. (Érted morgok, nem ellened.;)

1. Nem látom a szignifikáns különbséget a RIS és eközött… Pedig lennie kell, mert az előadó úgy kezdte, hogy RIS fúj, WIM/WAIK rulez.

2. Nekem a Microsoft automatikus telepítési módszereivel mindig is az volt a bajom, hogy nem találtam a fonalat. Illetve mire megtaláltam, rendszerint gyökeresen megváltoztatták az egészet. Innentől nekem az az alapelvárásom egy akármilyen automatikus telepítésről szóló előadással szemben, hogy először magyarázza el a vezérlő elvet. Utána elindulhatunk a cifrázások felé, belemehetünk a részletekbe… de amíg nem tudom mihez kötni az új fogalmakat, addig akár urdu nyelven is szólhat az előadás, ugyanannyit fogok érteni belőle.

Szünetben beszélgettünk. Elhangzott, hogy túl mély volt az előadás. A magam részéről nem tudom értelmezni ezt a véleményt: a Lurdyban nagyobbrészt jó úszók vannak – de legalábbis, akik akkor ott beszélgettek, mind nagyon profi úszók voltak. Nem létezik számukra az a kategória, hogy “túl mély”. Olyan viszont létezik, hogy ismeretlen víz, tele sziklákkal.
Nekem az egész előadásról az maradt meg, hogy nincs vezérfonal. Nincs semmi, amire felaggathatnám a tudásmorzsákat. Márpedig kötődés – asszociáció – nélkül az információk egyszerűen leperegnek az agyamról.
Különösen úgy, hogy nem kaptuk meg kinyomtatva a ppt-t – így nem tudtam a slide mellé jegyzetelni.

Hogy mondjak jót is az oktatóról: tisztán, határozottan adott elő, félszegségnek nyoma sem volt.
De fényt – legalábbis az én fejemben – nem tudott gyújtani ebben a témában.

Aztán szünet. Melyet jól elcsesztem. Elbeszélgettem az időt és már nem tudtam kávét inni. Live hard: ülj be az első sorba, közvetlenül GT elé és próbálj meg ne elaludni, alig pár óra éjszakai alvással magad mögött, kávé nélkül.
– Jó reggelt mindenkinek! – köszönt be az előadó. Fél tizenkettőkor. Istenem, valamikor én is így mértem az időt…

Szakmai morzsák:

  • Önálló Group policy service – annak minden előnyével: pl érzékeli, mikor kerülök tartományba és akkor érvényesít. Nincs többé sunnyogás VPN-nel, hibernált laptoppal.
    Innentől nem feltétel a ping sem.
  • Az LGPO immár rendelhető felhasználókhoz is.
  • Gpo-k központi helyen, mindenki onnan szedi. Vista már tud róla, létre kell hozni a megfelelő nevű share-t, keresni fogja arrafelé.
  • BITS – peer-to-peer alapon is megy (csak Vista) – bittorent, öcsém, bittorent!
  • Qos GPO alapon.
  • Eventlog
    • Xml alapú logok
    • Kategóriánkénti logok – pilótavizsga, b+
    • Elmenthető filterek
    • Beépített log management: szűrt eventlog import megadott gépekről
    • Debug.log: az eseménynaplóban részletes logolás, csak hibakeresés idejére bekapcsolva
  • Ütemezett feladatok: custom program/email/message. Jónak tűnnek. Remélhetőleg Tamásunk ezzel egyből értesülni fog, amint megáll a levelező szervere.
  • Perfmon: Data collector set – újdonságként lett felvezetve, de tudta a régi is, csak nem ennyire kényelmesen.

Szünetben a rendezőség bevadult. Első szünetből lent próbáltunk visszamenni, az íróasztaloknál – nem engedték, mert az csak kijárat. Bementünk a túloldali művészbejárón. Kifelé Varánusz szintén arra próbálkozott, de visszapattant – így maradt le a szendvicsekről. Kénytelen volt tejszínhabos csokikrémet tömni a fejébe. Nem csodálnám, ha teltkarcsúvá válása miatt peren gondolkozna.
A következő szünet végén megadóan mentem a művészbejáró felé – erre most már beengedték a népet a korábbi kijáraton is.
Több következetességet, ha kérhetném, Uraim.

Az újabb előadás a Vista biztonsággal kapcsolatos újdonságairól szólt. Bátor dolog volt Szabó Gábor részéről közvetlenül ebéd után ilyen témával kiállni az ezerfejű elé.
Itt hangzott el az alábbi mondat:

Nagyítás

“Reméljük, a másik szobában nem alszik mindenki…”
… avagy ahogy az előadó láthatja a termet.

És akkor itt is a szakmai morzsák:

  • Percekig kerülgetve, de nem kimondva a script kiddie fogalom. Sikerült.
  • Gina.dll a levesbe, szabad a pálya az alternatív autentikációk felé.
  • Néhány slide-ra ráismertem GT webcastjáról – ez később el is lett ismerve.
  • A szolgáltatásoknak SID-je van (S-1-80-logikai név hash), innentől ACL-hez rendelhetők. Nem mindenhatóak.
  • User Account Control (UAC). Végre. Mindenki user. Ha ez kevés, akkor interakció jön.
    Konkrétan. Amikor belép egy admin, két tokent kap: egy usert és egy admint. A felhasználói tokennel vitézkedik, de amikor adminkodni akar, akkor a rendszer visszakérdez. Ilyenkor kell váltania az admin tokenre.
    Mi van akkor, ha egy öreg program nem bír meglenni a teljes körűen elérhető registry, Program Files nélkül? Hát kap. Virtuálisat. Ami csak az övé.
    Demo. Jé, ezzel már találkoztam Moszkvában. Csak ott érthetően lett bemutatva. Itt viszont átrohantunk rajta.
    Install detektálás. (Oké, de a malicsuz is installal kerül fel… akkor mi van?)

Gyors kávészünet. Vérvételnél hemoglobinszint helyett lazán lehetne mérni nálam koffeinszintet is.

GT Longhorn bemutatója elrémisztésképpen NT4 Server Manager képernyővel indult. Gondolom Varánusz – 1200 NT4 szerver – élvezte volna a célzást, ha nem szorult volna be szünet végén a klotyiba.

Szokásos szakmai blokk:

  • Dns client peer-to-peer névfeloldás.
  • Vista-Longhorn: beállítható, ki legyen az állandó DC.
  • DC kipucolásának lehetősége a címtárból. Háromszoros hurrá.
  • Az AD szervízként fut. Indítható, leállítható. (Leállás alatt AD DS Stopped Mode van, a gép member szerverként működik.)

Itt fogyott ki a nafta a palmtopból. Pedig érdekes téma következett: a Longhorn Core DC. Komolyan beindította a vezérhangyát a fejemben. Tavasszal költözünk új házba és itt zöld mezős beruházásként alakíthatom ki a családi informatikát. (SOHO) Korábban már kaptam egy impulzust Lepitől – ne használj SBS-t, inkább legyen több virtuális géped egy host gépen -, most megkaptam ehhez a Longhorn Core DC ismertetését… és kezd összeállni a kép.

Persze várjuk meg, amíg alszom rá egyet. Előbb-utóbb lesz olyan is.

[Update]
Éjszaka már elfelejtettem összefoglalni. Szóval összességében jó előadások voltak, az elsőn is volt mit tanulni, annak ellenére, hogy az építőkockák nem álltak össze. GT szokás szerint pontosan elmondta, amit akart és már poénkodni is mert. Jó lesz ez. Szabó Gábor előadása is rendben volt, egyedül az zavart, hogy ha valaki időnként el akar térni az előadástól, akkor legyen bátrabb és fejezze is be azokat a kitérőket – annak semmi értelme, hogy eltérünk, félúton megijedünk, aztán gyorsan visszatérünk az előadáshoz.

Az a bizonyos postafiókméret

Megéri néha visszanézni régi írásokhoz, mert időnként a komment rovatban érdekesebb dolgokról olvashatni, mint magában az írásban.
Különösen, ha a téma az Exchange IGCs(1), az adminisztrátorok örök vesszőparipája, a méretkorlátozás.

Nézzük először a cikket.
Röviden összefoglalva, arról szól, hogy kvótázatlan mailbox rossz, maibox kvóta jó.

Ha korlátlan postafiókot használsz, a következőkre számíthatsz:

  • Egy DOS támadás lebéníthatja a levelezőrendszeredet.
  • Nem tudsz rendszerkapacitást méretezni.
  • A hálózati forgalmad várhatóan növekedni fog.
  • Mindez persze pénzbe kerül.
  • Na meg teljesítménybe.

Persze figyelned kell arra, hogy a kvóta nem megoldás, hanem csak a megoldás része, Mellette szükséged lesz még a következőkre:

  • Felhasználói oktatás – a postaláda nem fájlszerver.
  • Alternatív megoldás biztosítása: pl. Sharepoint.
  • Megfelelően méretezett mentési megoldások. (Stub otthagyása levél helyett.)

Ha ki akarsz mászni ebből a lehetetlen helyzetből, akkor a következő teendőid lesznek:

  • Csoportosítsd a felhasználóidat levelezési szokásaik, igényeik, erőszakosságuk (VIP) szerint.
  • Határozzál meg számukra postafiók limitet.
  • Határozzál meg melléjük különböző erősségű figyelmeztetési limiteket (irgumburgum, dupla irgumburgum).
  • Az IT és a többiek között legyen szerződés. (SLA, ha külső IT van, OLA, ha belső.)
  • Csoportosítsd át a felhasználókat a megfelelő mailbox store-okba.
  • Biztosíts időt a levelek archiválására, törlésére.
  • Állítsd be a korlátokat.

És ha már ennyire belejöttünk a korlátozásba, gondolkodjunk el a maximális levélméret szabályozásán is.

Mi történik velünk, ha nem szabályozzuk a maximális levélméretet?

  • Már megint kaphatunk egy DOS-t.
  • Nem fogunk tudni kapacitást tervezni.
  • Nem fogunk beleférni a mentési időablakba.
  • Lehal a vírusellenőrzésünk.
  • Na meg a spam ellenőrzésünk is.
  • Végül a hálózat is megy velük.

Kimászási metódus:

  • Monitorozzuk a levélforgalmat, hogy egyáltalán lássuk, mi folyik a szervezetben.
  • Határozzuk meg a maximális levélméretet.
  • Keressünk alternatív megoldásokat attachment továbbításra: Sharepoint, file szerver.
  • Állítsuk be a korlátozást – de soha ne a virtuális SMTP szerveren, mindig csak konnektoron. (Hacsak nem akarjuk agyonvágni a Public Folder replikációt.)
  • És persze egyáltalán nem utolsó sorban, erre is terjedjen ki az SLA/OLA, melynek teljesülését monitorozzuk.

Végül Russ mentegetődzik, hogy ezek szép elvek, de az Exchange2003 még nem ad meg minden segítséget. De bezzeg az Exchange2007 / Outlook2007 páros maga lesz a tejjel-mézzel folyó kánaán.

Durván ennyi a cikk. És utána jönnek a hozzászólások, a pici apró csörtékkel. Nyilván semmi értelme nem lenne nekiállni lefordítgatni ezeket, inkább csak kiemelnék néhány szálat, hozzáfűzve a saját gondolataimat.

Először is vizsgáljuk meg, mitől is ilyen komoly ez a probléma. Hiszen felnőtt emberek vagyunk, ha találkozunk egy problémával, először szénné elemezzük majd közösen megoldjuk. Miért nem működik ez a módszer a jelen esetben?
Nos, azért mert a mélyben egy nem könnyen feloldható dilemma húzódik meg, nevezetesen: a felhasználó parancsol és az IT kiszolgál, vagy az IT a sarkára áll és diktálja, hogy mit, hogyan lehet?
Nem, ne vágja rá senki a választ. Hibázik az, aki ITIL-lel mélyen impregnálva rávágja, hogy „csak a felhasználó létezik és az IT-nek kutya kötelessége mindenben támogatnia” – és hibázik az a racionális lelkű rendszergazda is, aki helyből elküld mindenkit a sunyiba, azzal, hogy „értsétek már meg, a fizika törvényei alól nincs felmentés”.
Ugyanis a kettő együtt kell, hogy érvényes legyen – de ehhez mindkét félnek engedményeket kell tennie. A felhasználó nem lehet szűk látókörűen akaratos, a rendszergazda pedig nem lehet beképzelt technokrata.
Amennyiben ez a kölcsönös közeledés nincs meg, akkor jönnek a csempetépkedős esetek. Volt olyan ügyfelünk, ahol nagyon sokáig kitartottak amellett, hogy márpedig náluk nem lesz postafiók méretkorlátozás, mert ezzel a felhasználók jogait sértenénk. A csúcs közelében durván 280 GB volt az adatbázisuk mérete, nem volt ritka a 10-20 GB közötti postafiók, a 40-60e levél folderenként. Az Exchange becsületére legyen mondva, elketyegett, de egyfelől nem győztük tolni alá a merevlemezeket illetve később a SAN területeket. Az online maintenance lefutásának körülbelül annyi esélye volt, mint hintalónak Epsonban. Végül az egyre sűrűbb rendellenességek, belassulások, illetve a Microsoft kihívása és a felmérés eredménye meggyőzte őket, hogy ez így tényleg nem mehet tovább.
Ez a történet heppienddel zárult. De le merném fogadni, az olvasók közül sokan tudnának mesélni hasonló történeteket, ahol pénzhiány, rossz priorizálás miatt a mai napig vagy hagyják a dolgokat, hagy menjenek csak úgy maguktól vagy beavatkoznak ugyan, de a józan ész legcsekélyebb szikrája nélkül. Mire gondolok? Például amikor túl alacsony postafiók korlátozásokat vezetnek be, a fájlszerverek szintén szigorúan kvótázva vannak, pst-t meg tilos használni – hogy csak egy eszetlen konfigurációt vázoljak. Emlékezzünk, fentebb már meg lett említve, hogy menekülési útvonalat márpedig biztosítani kell. (A legszebb persze, hogy ilyenkor a felhasználók az IT-t szidják, nem pedig azt a farkot, aki az ilyen szabályozást kitalálja.)

Elemezzük még egy kicsit, hogyan is juthattunk ilyen helyzetbe? Igaza lehet-e annak, aki azt mondja, hogy az Exchange olyan problémakörbe keveredett, melyet éppen nagy sikere indukált? (És most egy kicsit gondolkodhatunk bővebben is, hiszen nyugodtan gondolhatunk az email sikerére is. Az már más lapra tartozik, hogy munkahelyen milyen levelezőrendszer testesíti meg az email szolgáltatást.)
Miért használunk mindenre emailt? Egyrészt, mert kéznél van – másrészt, mert nincs más. Ha üzenni kell, evidens. Ha küldeni kell egy word alapú jelentést? Sajnos, akkor is. Ez a mai IT infrastruktúrák egyik gyenge pontja, hogy nincs megoldva bennük tisztességesen, _ügyfélcentrikusan_ a fájltranszfer.
Mi lenne az optimális? Küldenék egy linket a kollégának, benne egy linkkel a gépemen lévő dokumentumra. Ő rákattint a jobb gombbal, kiválasztja a ’save as’ lehetőséget és már húzza is az állományt. A fájl csak egyszer ment át a dróton, a tranzakció végén két helyen létezik, a készítőnél és a felhasználónál.
Ezt egy felhasználó nem tudja megcsinálni. Fennáll a lehetősége, hogy fájlszerverre pakol, de akkor már fel kell másolnia, visszajelzést kell kapnia, hogy leszedték, majd törölnie kell. Arról nem beszélve, hogy ez csak intraneten működik. Interneten keresztül külső tárolóhely kell, feltöltés, letöltés, tűzfalak… nem barátságos.
A probléma érdekessége, hogy erre az egészre létezik ugyan megoldás, de valahogy a céges informatikába csak nem akar betörni az elv: peer-to-peer hálózatok. Most gondold el, küldeni akarsz az üzleti partnereiteknek egy ajánlatot: kiteszed a gépeden egy megosztott könyvtárba, majd szólsz a partnernek, hogy megtalál a DC++-on, darthfather658 néven, ha érdekli az ajánlat.
Mi marad még? Sharepoint? Jelentkezzen, aki már látott működő megoldást fájlcsatolásra, beleértve a megoldásba a külső partnereinkkel történő kapcsolattartást is.
Valahogy nem az igazi egyik sem. Ezzel szemben becsatolni bármit egy levélbe, elküldeni – két mozdulat. Rátenni CC-ben a fél kollektívát, maximum egy mozdulattal több.
Térjünk vissza az Exchange-hez. Vegyünk két ideális felhasználót. Az egyszerűség kedvéért a postafiókjuk legyen különböző adatbázisban. Géza el akar küldeni egy nagyon fontos doksit Bélának. Becsatolja egy emailbe, elküldi – majd a sent mail könyvtárból törli a levelet. Géza megkapja, lementi a csatolást, majd ő is törli a levelet. Látszólag minden rendben, a fájlok csak a lokális vinyókon foglalnak helyet.
Igenám, de marad utánuk két lyuk az Exchange adatbázisban. Két akkora lyuk, mint a csatolás volt.
Az Exchange ESE(JET) adatbázisokat használ, melyeknél a tárolás lényege az, hogy van egy nagy adatbázis (kenyér), amelybe beleömlesztjük ész nélkül az adatokat. Az adatbázishoz tartozik egy indexfájl, mely tele van pointerekkel – ezek mutatnak az egyes adatok kezdőpontjaira. Ha bekerül egy levél, akkor a kenyérfájl mérete megnövekszik. Ha kitöröljük a levelet, a fájl mérete nem csökken – csak egy lyuk keletkezik benne. Mondhatod, hogy azért még a későbbi adatok kitölthetnék ezt a lyukat… és van is valami ilyesmi, de ehhez le kell futnia az online maintenance műveletnek.
Költői kérdés: ki szokta reggelenként megnézni az eventlogot, hogy leellenőrizze, lement-e rendesen az online maintenance az éjjel? Egyáltalán, ki foglalkozott azzal, hogy megnézze, belefér-e az online maintenance az általunk biztosított – magyarul default értéken hagyott – időkeretbe? Elgondolkodott-e már valaki azon, hogy ne egyidőben biztosítsa az összes adatbázisnak az online maintenance időablakot? Hogy beillesszük a backup időablakai mellé az online maintenance időablakait? Márpedig ha nem fejeződik be rendesen a folyamat, akkor gyakorlatilag nem csináltunk semmit. Az adatbázisunk monoton nő, a lyukak szaporodnak ugyan benne – mi meg őrizzük rendületlenül a semmit. Nyilván az offline tömörítés majd segít, de annak meg szolgáltatáskiesés az ára.
A legszebb az egészben az, hogy mikor nem fut le az online maintenance? Ha túl nagy az adatbázisunk. Mikor nagy? Ha nem korlátozunk. Mi lesz a vége? Még nagyobb lesz az adatbázisunk.
Szép sport Exchange adminnak lenni.

Oké. Korlátozzunk. Mennyi legyen a maximális méret? Nyilván ahány cég, annyiféle limit jöhet létre. (Emlékezzünk, csoportosítani kell a felhasználóinkat.) A gyakorlatban a 250/500/1024 MB határok fordulnak elő a leggyakrabban. (Értelemszerűen a felső határ csak nagyon indokolt esetben jöhet szóba.)
Csakhogy… valahol jogos lehet a felvetés a felhasználó részéről, hogy „feleim, kedves IT-s barátaim, hogy a szöszbe létezik az, hogy ti, akikkel egy kenyeret rágunk, akikkel egy hajóban evezünk, ti csak 250 MB méretű postafiókot adtok nekünk, ezzel szemben a Google, aki se kutyánk, se macskánk, szó nélkül ad 2 gigát?”
A kérdés jó. Többféleképpen is neki lehet futni a válasznak:

  • A gmail ‘best effort’ alapú. Neked, mint felhasználónak nincs velük se SLA-d, se OLA-d. Ha egyszer azt mondják, mostantól az informatikánál jobban érdekli őket a szilikonalapú életformák vizsgálata, ezért beolvasztják az összes processzorukat – egy szavad sem lehet. Nekem viszont konkrét számok írják elő, milyen levelezőrendszert kell üzemeltetnem, mennyi pénzből – ez pedig csak ekkora limittel mehet. A Google alapozhat arra, hogy hiába a 2 GB limit, az átlagos postafiókméret 25 MB – mi nem. Ha mi így gondolkodnánk és időközben a megugró igények miatt bővíteni kellene, legalább tíz embernek kellene aláírnia az állóeszköz beszerzési papírt, nem beszélve arról, hogy mennyire kínos lenne ez az ISO9001-es költségbecslési eljárás szempontjából. (Most azt hiszed, gúnyolódok. A francokat. Egyszerűen ez a ‘bővítünk, ha szükség lesz rá’ nem illeszthető bele egy nagy cég IT részlegének viselkedésébe.)
  • A másik – határozottan szimpatikusabb – válasz az a Microsoft ajánlás, hogy akkor legyen a felhasználói postafiókok felső határa 2 GB. Persze csak Exchange2007 / Outlook 2007 páros alatt.

Nyilván ez nem csak annyiból fog állni, hogy katt, 2 GB, OK. (Gondolhatod, a Google-nél sem ennyi.) Mi is kell mindehhez?

  • Először is tudnunk kell, hogy egy adatbázis elfogadható felső határa 100 GB. Tehát ha 2 GB maximális postafiók méretet szeretnénk biztosítani, akkor szét kell szedni a felhasználókat, maximum ötvenet rakva egy adatbázisba. Hogy egy Exchange szerveren tokkal-vonóval maximum 20 adatbázis férhet el? Ja, az Exchange2003-ban. A 2007-es termékben ez a szám 50-re ugrott. Ez 2500 felhasználót jelent, 2 GB postafiókkal, egy szerveren belül. Úgy vélem, nem rossz. (Az más kérdés, hogy ehhez tényleg kell a 64 bit, meg több lapát memória, processzor, a merevlemezekről nem is beszélve. De a garantált végtelent soha nem adják ingyen.)
  • Mi lesz itt az online maintenance folyamattal? Hiszen a rendszeres backup maga ki fogja tömni a nem üzleti időintervallumot.
    Kitömné. Ha hagynánk. De inkább kidobjuk a backup-ot.
    Meredek volt? Ne feledd el, ez egy új termék.
    Gondoljuk végig, mire is való a backup? Hogy legyen egy viszonylag naprakész példányunk az adatbázisból, ha az éppen aktív feldobná a talpát. De miért ne lehetne egy teljesen naprakész példányunk a viszonylag naprakész helyett? Mi lenne, ha minden tranzakciót nem csak az éles adatbázis logjaiba rögzítenénk, hanem ezzel párhuzamosan egy árnyék adatbázis logjaiba is? Ha bedőlt az éles adatbázis, akkor van helyette egy teljesen naprakész másik. Ezt a technikát úgy hívják, hogy Cluster Continous Replication, illetve Local Continous Replication – attól függően, hogy lokális gépen keletkezik a tükör adatbázis vagy távolin. Tulajdonképpen egyfajta átmenet a szóló és a clusterezett Exchange szolgáltatás között. Például oprendszer szinten kell neki a cluster szolgáltatás. (Miért más ez mégis, mint a cluster? Azért, mert nem kell közösen használt adattároló -> el lehet tenni a másik gépet Böhönyére.)
    (Megjegyzem, ez szép és jó, de azért van olyan aspektusa a backupnak, melyet a CCR/LCR nem old meg. Jön Vezérigazgató Béla, töröl egy levelet, majd egy hónap után mégis csak kellene neki. Ennyi ideig a dumpster sem tart ki – csak az egy hónappal korábbi mentésből tudjuk neki elővarázsolni a levelet.)
    De akárhogy is nézzük, le tudjuk csökkenteni a backup időablakát, így a szabad időablakok nagy részét az online maintenance folyamathoz tudjuk rendelni.
  • A bűvös 64 bit. A sokkal nagyobb címezhető memória. Mellyel lekerül a béklyó az Exchange-ről, bátran habzsolhatja a szabad memóriablokkokat.
  • Records Management: menedzselt foldereket vezethetünk be, melyekben házirendekkel szabályozhatjuk a levéltömeg kezelését.
  • Keresés a nagyméretű postafiókokban: az Outlook2007 – cached módban – a jóval hatékonyabb Windows Desktop Search szolgáltatást fogja keresésre használni.

Ha már a cached módnál járunk, volt egy érdekes pengevillantás. Russ megjegyezte, hogy a a cached módba kapcsolt Outlook bizonyos esetekben nagyobb forgalmat generálhat, mint az online módban használt. Erre azért nem kevesen kapták fel a fejüket.
Imhol a magyarázat:

  • Az Offline Address Book letöltögetése. Ez verziótól függően meglehetősen frekventált is lehet.
  • Azért azt az OST-t is szinkronizálgatni kell.
  • Ha n felhasználónak küldünk egy levelet, az egy idő után mindegyikhez leszinkronizálódik, akár kíváncsi rá, akár nem. Ugyanez online módban nem feltétlenül történik meg – a levelet törölhetem olvasás nélkül is.
  • A hétfő reggeli csúcs. Amikor mindenki belép és egyszerre szinkronizál a szerverrel.

Magunk között legyen mondva, engem nem győzött meg. Ezek tényleg bizonyos esetek – de azért az online mód masszívan hozza magával a nagyobb adatforgalmat.

Nézzünk még egy hozzászólást: itt a másik klasszikus IGCs séma: miért nem teszitek már át ezt az egészet SQL alá?
Erre mondta Russ azt, hogy a jelen szituációban tökmindegy, hogyan tároljuk az adatokat, ESE v. SQL v. Sharepoint adatbázisban vagy akár kopasz fejekre tetoválva. Az email, mint forma generálja a nagy adatbázisokat.

Végül még egy utolsó érdekesség a kommentekből.
Egy hozzászóló reklamálta, hogy ő akár a feje tetejére is állhat, a MAPI jellegéből adódóan a felhasználói bármikor ledosolhatják a levelezőszerverét: ugyanis a nagy üzenet, függetlenül attól, hogy postafiók méretkorlátozás miatt megérkezik-e vagy sem, a tranzakciós logba mindenképpen bekerül. Russ válaszként belinkelt egy korábbi írást.
A cikk rögtön aranyos történettel indít: egy felhasználó kapott egy 6 gigás levelet. Egy olyan rendszerben, ahol korlátozva volt a levélméret. Az történt ugyanis, hogy Béla elküldte a szerény hatgigás levelét, melyre természetesen egy NDR-t kapott vissza a szervertől. Benne csatolásként az eredeti levelével.
Nem áll szándékomban lefordítani az egész cikket, röviden arról van benne szó, hogy kielemezték, hogyan működhet ilyen nonszensz módon egy Exchange szerver, miért nem lehet már a levél elküldése előtt leellenőrizni, hogy méret – mind levélméret, mint postafiókméret – tekintetében minden rendben van-e? Organizáción belül egy MAPI kliens elvileg képes lenne erre.
Nos, a nagy elemzésnek az lett a vége, hogy ma már képes erre mind az Exchange, mind az Outlook. Egész pontosan Exchange-ből a 2003Sp2, Outlookból szintén a 2003Sp2.

No, szép hosszú írás lett – és IGCs-hez méltóan, nem oldottam meg vele semmit. A probléma továbbra is itt lebeg körülöttünk, az alternatív megoldásokról látszik, hogy még nem igazán jók, az Exchange2007 pedig még a – nem túl távoli – jövő zenéje. Egyelőre túl sok mindent azon kívül nem tehetünk, hogy jól kipanaszkodjuk magunkat. Hátha azzal, hogy hangosan gondolkodunk, csak tudunk segíteni azokon, akik még csak most szembesültek a problémakörrel.

Megjegyzés:
(1) IGCs: A rövidítést én találtam ki. Internetes fórumok olyan toposzaira használom, ahol mindenkinek van egy kis igaza, így a téma rendszeresen előkerül és a vitában résztvevők az unalomig ismert érveket Irgalmatlan GumiCsontként rágják újra meg újra. (Kerékpáros, abortusz, kutyaszar, sebességkorlátozás… meg hasonlók.)

21

Annyi otthoni teendőm torlódott fel, hogy szószerint megbénultam az íróasztalom előtt. Ezt is kellene, azt is kellene, ez rohadt sürgős, na az meg aztán végképp… csak néztem a monitoromat, néztem… végül úgy döntöttem, hogy hagyom eluralkodni magamon az ösztöneimet és játszok egy kicsit.
Persze geek módra.
Barnának ma este mutattam egy ízelítőt a logikai folyamatok grafikus ábrázolási módjairól, megemlítve, hogy ilyesmi ábrák jelentik a számítógép programozásának az alapjait is. Aztán – már egyedül, magamban – elgondolkodtam, le tudnám-e skiccelni a huszonegyes kártyajáték modelljét. Persze, vágtam rá. Igazából le se kellett rajzolnom, pár perc alatt fejben összeraktam.
Utána jött az izgalom: félóra alatt le tudnám-e programozni ezt – demonstrációs céllal – akármelyik itthoni számítógépen? Emlékszem-e még ennyire a régi dolgaimból, bennem van-e még készség szinten valami programolás – és van-e még eszközöm ahhoz, hogy csak úgy összedobjak egy programot? (Ugye a C64 esetében nem volt gond. Korai – első 10 év – IT-s időmben mindig volt vagy Pascal, vagy Clipper a gépemen beélesítve, bármikor gyorsan kellett valamit csinálnom, egyből ment.)

Az utóbbi feltétel nem okozott komoly problémát: az eszköz természetesen egy átlagos gépen is adott, Excel ma már mindenhol van – és ahol Office van, ott VBScript is van, nem is rossz GUI-val. A programolással már elvoltam egy kicsit, már csak hiúságból is igyekeztem minél tisztábban, egyszerűbben megoldani a feladatot. Jól elvoltam, na.
A sürgős teendőim meg ennyit igazán várhatnak.

Végül itt van a program. Maga az Excel tábla is letölthető, a vbscript része meg alant olvasható.

Sub Macro1()

‘ Macro1 Macro
‘ Macro recorded 2006.11.06 by The Tiger of Wekerle

‘ Keyboard Shortcut: Ctrl+a

Dim i, lapom

Range(”B2:C24″).Select
Selection.ClearContents

i = 0
lapom = 0

Do While lapom < 16 And lapom < Cells(2, 1)
i = i + 1
lapom = lapom + (Int(10 * Rnd(1)) + 2)
Cells(1 + i, 2).Value = lapom
Loop

If Cells(2, 1) > 21 Then
Cells(1 + i, 3).Value = “Yeah, the smarter has won!”
Else
If Cells(1 + i, 2).Value < Cells(2, 1).Value Or Cells(1 + i, 2).Value > 21 Then
Cells(1 + i, 3).Value = “Your mother wears army boots”
Else
Cells(1 + i, 3).Value = “Yeah, the smarter has won!”
End If
End If

Range(”A2″).Select

End Sub

ps: A sorbehúzásokért elnézést, nem szoktam ilyen csúnyán forráskódot írni, de a WordPress kigyomlálja a space-ket.

ISA szerver nem menni 64

Egyik ügyfelünk most hétvégén tervszerű leállást hajt végre, így lehetőségünk van egy csomó régóta halasztott munkát elvégezni. Többek között jó ideje érik a tűzfaluk lecserélése.
A következőképpen terveztük: én offline összerakom az új vason a cuccot, aztán egyszerűen kidobjuk a régit, berakjuk az újat és mindenki örülni fog. Apró kihívás, hogy más a hardver (a régi 32bites procival ment, az új egy 64 bites Opteron), más az oprencer (a régi Windows2000/32, az új Windows2003R2/64) és persze más a szoftver is (ISA2004Sp1->Isa2004Sp2). De azért működjön ugyanúgy.
Mindazonáltal a feladat nem megoldhatatlan. Igaz, hogy magyar nyelvű 32 bites Windows telepítőcédét kaptam, de szerencsére telepítő médiánk nekünk voltak, megfelelő licenszkulcsai meg az ügyfélnek.
Három napig az általam eddig ismeretlen tűzfalat tanulmányoztam. Leszedtem mindent xml/txt fájlokba – és természetesen kijegyzeltem mindent spirálfüzetbe. Kisebb novella méretű anyag gyűlt össze. (Huszonvalahány subnet, VPN terminálás, szabályhegyek – nem igazán egyszerű a jószág.) A következő nap azzal telt, hogy felraktam az oprendszert és előkészítettem mindent az ISA szervernek. Végül ma jött el a nagy nap.
Ahhoz képest, hogy mennyire kényelmesen ágyaztam meg a tűzfal szoftvernek, őkényessége rövid, gyors, de határozott üzenettel közölte, hogy menjek a fenébe – erre a gépre, ha beledöglök sem fogom tudni feltelepíteni. A miértet viszont nem igazán részletezte.
Ránézésre lehetett egy csomó baja: a processzor 64 bites, az oprendszer R2/64, az ISA ellenben csak standard… A legegyszerűbb ilyenkor megnézni a hivatalos adatokat. Nos, egy szó sincs arról, hogy ne futna R2-vel, illetve 64 bites oprendszerrel. A biztonság kedvéért átnéztem a Shinder könyvet, ott se tér ki rá a hapi. Hívtam a TAM-unkat, de éppen olyan helyen volt, ahol nem vette fel a telefont. Bedobtam egy szösszenetet Shinder bácsi fórumába, majd rácsörögtem GT-re, hátha ő látott már ilyet – de nem. Mindketten nekiálltunk guglizni, végül kaptam tőle egy linket. Nem lehet azt mondani, hogy túlzottan bőbeszédű lenne az írás, de a lényeg benne van: semmilyen ISA nem fut 64 bites oprenceren. Aláírás: XY ISA MVP.
Érted, semmilyen. A frissen kijött ISA2006 sem.
Azért ez elég durva.
Felködlött előttem, milyen remek pofozkodás lesz ebből. Az ügyfél nyilván azt fogja reklamálni, miért nem szóltunk neki, hogy ne vegyen ilyen hardvert? Mi meg… mondjuk azt, hogy mi sem tudtuk? Baromira ciki. És nem csak az a durva, hogy így nem lesz a hétvégén csere – sokkal durvább, hogy mit csináljanak most a méregdrágán vett új hardverrel?
Mentsük a veszett fejsze nyelét. Fel lehet-e rakni 64 bites processzorral felvértezett gépre 32 bites Windows Server oprendszert? A franc se tudja. Talán a Gugli. Nem, ő se igazán. Még talán ez a bejegyzés nyújtotta a legvérmesebb reményeket – mintha az AMD procikra felmenne, csak az Intelekre nem…
Itt álltam, amikor visszahívott a TAM-unk. Rövid idő alatt sikerült mindent tisztáznunk.
Hogy te legközelebb ne járj ilyen hülyén, tömören leírom a lényeget:

  • Jelenleg semmilyen ISA (2000/2004/2006, ill standard/enterprise) nem képes futni 64 bites operációs rendszeren.
  • x64 architektúrára lehet telepíteni 32 bites Windows Server operációs rendszert – azaz AMD Opteronra igen, Intel Itaniumra nem.

Ez azért valahol megnyugtató. Nem az, hogy az ISA nem fut 64 biten, az valahol szégyen – a jó hír az, hogy az ügyfelünk csak a szervízhétvégét bukta be. Meg mi sem veszítettünk olyan nagyot az arcunkból.