Month: November 2011

Hotfix

Néhány hete, hogy tanuljak összeraktam egy Exchange 2010 DAG-ot több telephely között kábelnet vonalakon VPN-eken keresztül. Ez ugye hálózatilag nem a stabilitás magasiskolája.

Egyszer lett egy rövid kiesésem (egy-két perc). Erre fogta magát a DAG és szétesett. Nem ált helyre magátol, gyakorlatilag a Windows Cluster eszközeivel kellett szétszednem mert semmire sem reagált. Végülis újra össszeraktam és napirendre tértem a dolog felett.

Tegnapelőtt ráakadtam erre a cikkre. Végiggondolva az előző eset kísértetiesen hasonlított a cikkben leírtakra. Nosza rajta, szerezzük be a hotfixet, elvégre a fenti teszt DAG-om még létezik (azóta szerencsére nem volt vele újabb gond) valamint vár rám vagy három újabb DAG, csak azok már élesben.

Emlékeztem, hogy a Microsoftnak van egy webes formja ahol lehet hotfixet kérni. Meg is találtam itt.

Elküldtem az igénylést, erre ez a válasz jött tegnap:

Hello,

Thank you for contacting Microsoft Customer Service.

From the information you have provided in your message, I understand that you are located in Hungary. The Customer Service team you have reached is for North America. There are significant differences between North American versions of Microsoft products and those localized for your country.

You will be best assisted by the Microsoft subsidiary that specializes in your version of Microsoft products. You can reach them at +36 1 437 2800 or by visiting: http://www.microsoft.com/worldwide/phone/contact.aspx?country=Hungary

I hope the above information is useful. In case you require further assistance with regards to this issue, please feel free to contact us.

Thank you,

John

Microsoft Customer Service Representative

Na gratulálok. Hotfix nincs, ráadásul bődületes baromság, hogy különbség lenne a verziók között, ugyanis én a US English verzióhoz kértem fixet és nem a magyarhoz.

Azt találtam ki, hogy csinálok egy új e-mailt és bejelentkezem amerikaiként a formra. Meg is tettem. Amikor újra rákerestem a form címére (tegnap nem tettem el), megakadt a szemem az egyik találaton.

Egy próbát megér alapon össze is raktam az urlt: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=2550886&kbln=en-us

Láss csodát, kaptam egy magyar nyelvű oldalt és 5 perc múlva a kezemben volt a hotfix, ahelyett hogy egy fél napot vártam volna az elutasításra.

Kosztüm

Adott a feladat, publikáljunk egy Exchange 2010 OWA szolgáltatást TMG-n keresztül. Ez ma már egyáltalán nem pilótavizsgás munka, nosza.

Úgy döntöttünk, saját SAN tanúsítványt használunk, így első lépésben azt gyártjuk le. Certification snap-in, advanced, create a request. Itt kapjuk a következő ablakot.

From Segédlet

Először is pár szívélyes szóval megemlékeznék az UI tervezőjének felmenőági rokonairól. Hogy a szöszbe lehet olyan felületet tervezni, ahol nem látszik, mi kattintható választás és mi egyszerűen csak szöveg? Aki először jár erre, kénytelen az egérrel végigszkennelni az ablakot, figyelve, hol változik meg a kurzor.
Jó, nézzük a lehetőségeket. Aszongya, hogy… az Igazi Rendszergazda mindig a custom opciót választja, így akkor mehetünk is tovább.

From Segédlet

Mondjuk, nem fogunk dúskálni a lehetőségekben, az Igaz Rendszergazda egy kicsit meg is szeppen, mert egy kukkot sem ért a beállításokból, de aztán vállat von, biztosan jó lesz az alapértelmezés, és nyomja tovább bátran a varázslót. Elkészül a tanúsítvány, lecseréli az Exchange alatt, minden rendben, a napocska mosolyog, a madarak trilláznak. A belső hálóról működik az OWA, működik a MAPI, sehol nem jön fel tanúsítványhibára figyelmeztető ablak.

Kiexportáljuk a tanúsítványt, figyelve, hogy benne legyen a privát kulcs, felmásoljuk a TMG szerverre. Elkezdjük összerakni a web listenert. Elérkezünk oda, hogy kiválasszuk hozzá a tanúsítványt… de nincs. Azt mondja, hogy az a tanúsítvány, melybe az összes bizalmunkat helyeztük, az bizony inkorrekt. Hogy a manóba? Hiszen az Excange elfogadta, a kliensek elfogadták, az Active Directory elfogadta, a TMG tartományi tag, tehát a root CA tanúsítványa rajta van, a dátumok jók… akkor miért inkorrekt? Ezért.

Ott, amikor a custom sablont választottuk a tanúsítvány igénylésénél, ott csak V3-as (CNG) tanúsítványt igényelhettünk. Igenám, de ebből a tipusú tanúsítványból a TMG nem tudja kiolvasni a privát kulcsot, azaz úgy érzékeli, hogy nincs benne, azaz a tanúsítvány inkorrekt. Kuka.

Visszamegyünk ahhoz a bizonyos ablakhoz és most azt választjuk, hogy Active Directory Enrollment Policy.

From Segédlet

Itt már a jól ismert legördülő menü fogad, kiválasztjuk a V2-es Web Server sablont, és máris minden kiegyenesedik.

Tömörítsek?

Amióta létezik olyan termék, hogy Exchange, állandóan visszatérő kérdés az adminok körében: kell-e tömöríteni az adatbázis, és ha igen, akkor mikor?

Rövid kitérő, ha valaki esetleg nemrég bújt volna még csak ki a tojáshéjból. Az Exchange-ben – eltekintve a régebbi verziók stm fájljaitól – egy adatbázis egy darab edb fájl. Ezen a fájlon belül vannak adattáblák, ahol az összetartozó adatok között pointerek teremtik meg a kapcsolatot. Amikor törlök egy levelet, akkor az egyik adattáblából törlődik a levél tartalma, és emellett törlődnek a rámutató pointerek is. Értelemszerűen hiába csökkennek az egyes adattáblák méretei, az edb fájl mérete nem csökken. A fájlon belül üres hely (whitespace) szabadul fel, de a sok, apró üres hellyel az Exchange nem tud mit kezdeni. Ekkor jön be a képbe az Online Maintenance folyamaton belül az Online Defragmentation, azaz online tömörítés: ez az edb fájlon belül az üres helyeket kimozgatja a fájl végére, így újra hasznosíthatók lesznek. Az online tömörítés, mint a neve is mutatja, online, azaz működés közben is végezhető. Csak éppen erőforrásigényes, emellett Exchange 2010 előtt szégyenlős is, ha túl nagy aktivitást észlel az adatbázison, akkor megáll. Márpedig az online tömörítés hiányában vészesen dagadni kezd az adatbázis. Sőt, ha valaki végiggondolja a folyamatot, akkor láthatja, hogy az online tömörítés mellett is dagadhat az adatbázis. Például kapunk egy tüskeszerű nagy terhelést. Egy nap alatt felhízik az adatbázis (betör egy spam), a felhasználók ugyan törlik a leveleket, de az online tömörítés csak az üres helyekkel tud játszani, az edb fájl méretével már nem. Ahhoz, hogy az utóbbi is csökkenjen, már más módszerekhez kell nyúlni.

Így jutottunk el az offline tömörítéshez. Ekkor lecsatoljuk az adatbázist és az edb fájlt átadjuk egy erre a célra kifejlesztett adatbázismatyizó programnak (eseutil). Ez nyit egy új, ideiglenes adatbázist, elkezdi átmásolni az értelmes tartalmat (nem, a levelekben már nem kutat értelmet), majd ha végzett, akkor az eredeti adatbázist törli, az ideiglenest pedig átnevezi. Visszacsatoljuk és jó esetben mindenki boldog.

Most jön egy újabb kitérő. Olvasdd el Paul Cunningham írását. Nagyon szépen körbejárja a témát, a végeredménnyel pedig csak egyetérteni lehet: az offline defrag nem az az elem, melyet a rendszeres, szabályozott karbantartási folyamatok során végzel. Mivel az offline defrag offline, és emellett kockázatos is, csak akkor van értelme, ha az adatbázis mérete már problémákat okoz. Pontosan miket is? Egyrészt kezd elfogyni a tárterület a diszken. Ekkor el lehet gondolkozni az offline tömörítésen, de ha nem szeretjük a kockázatot, akkor lehet bővíteni is a tárterületet. Másrészt – saját tapasztalataim szerint – az Online Maintenance időigénye az edb fájl fizikai méretével arányos. A nagy edb fájl hosszú Online Maintenance időt jelent és így már lehet, hogy a folyamat nem fér bele a kijelölt időablakba. Nyilván az időablakot ki lehet húzni, de ekkor összecsúsznak az adatbázisműveletek, neadjisten belecsúsznak a produktív időbe, ez persze újabb terhelés – és egész egyszerűen mire végetér egy online tömörítés, már megint töredezett az adatbázis. Értelemszerűen itt is eljárhatunk úgy, hogy bővítünk – több RAM/proci – de ennyire ne legyünk már nyulak. Ezzel ugyanis csak elodázzuk a probléma megoldását.

Ekkor úgy halványan felmerül az offline tömörítés utáni igény az IT csapatban. De biztos, hogy erre van szükségünk? Mi van, ha az adatbázis tényleg ekkora lett? (Jelzem, ha az adatbázis mérete meg lett tervezve, az összes postafiók mérete korlátos, akkor ez a kérdés érdektelen.) Ilyenkor lenne jó tudni, mennyi is a whitespace. Biztosan vannak szofisztikáltabb módszerek is, én egy közepesen bonyolult powershell parancsot szoktam használni:

get-mailboxdatabase | get-mailboxstatistics | measure-object -property itemcount,totalitemsize -sum

Ez a szerveren lévő összes adatbázisra kiírja, hogy mennyi item-et (levelet, kontaktot, naptárbejegyzést) tartalmaznak, illetve ezeknek mekkora az összesített méretük. Ugyanez létezik konkrét adatbázisra is:

get-mailboxstatistics -database name | measure-object -property itemcount,totalitemsize -sum
get-publicfolderstatistics | measure-object -property itemcount,totalitemsize -sum

Az adatbázisok fizikai méretét megtaláljuk a Windows Explorerben, ebből pedig tudni fogjuk, hogy az adatbázisban mennyi az adat jellegű tartalom adattartalma. Igen, nem véletlenül fogalmaztam ennyire körülményesen. A cikk elején is írtam, hogy az edb fájlban vannak olyan adattáblák is, melyek az adatok strukturálását, gyors elérését segítik. Ez az adatbázis overhead. Tervezéskor én 20%-kal szoktam dolgozni – mégem hidat méretezünk, ekkora pontosság bőven elég – azaz ha ennél jóval nagyobb a különbség, akkor tényleg itt van az ideje az offline tömörítésnek.

Vagy mégsem?

Jó hír azoknak, akik Exchange 2010-et üzemeltetnek, hogy ők már használhatják az offline tömörítést online is. Nem, nem golyóztam be, legalábbis még nem nagyon. Olvassuk vissza, mit csinál az eseutil: nem tudnánk ezt mi is elvégezni, az adatbázis lecsatolása nélkül? Létrehozunk egy új adatbázist, felcsatoljuk, a postafiókokat átmozgatjuk (csak az adattartalom megy át, a whitespace nem), a régi adatbázist lecsatoljuk, letöröljük. Kész. A kliensek nem a Mailbox szerverhez kapcsolódnak, hanem a CAS szerverhez, az meg mindig tudja, melyik adatbázisban van a felhasználó. Ezzel ki is húztuk az offline defrag mindkét méregfogát:
– Nem offline. Régebben könnyű volt az élet, ötkor megszólalt a gyárban a sziréna, a portás hatkor lehúzta a redőnyt, a rendszergazda ekkor kezdett ébredezni, majd éjjel lecsatolta az adatbázisokat és reszelgette. Manapság már nincs holtidő. A legtöbb alkalmazottnak van minimum egy emailképes kütyüje, és valami fura perverzióból éjjel is meg akarják nézni a leveleiket. Offline folyamat? Hogy gondolod.
– Bármennyire okos is az eseutil, egyszerűen nem tudjuk olyan alaposan paraméterezni, mit csináljon az értelmetlen adatokkal, mint ahogy egy postafiókmásolás esetében. Már nem kell rettegni attól, hogy az eseutil után kapunk egy annyira tömör adatbázist, hogy gyakorlatilag üres.

Pecs

Kora reggel jött egy kérdés. Valami nem működik egy Exchange 2010 szerveren. Oké, mindjárt megnézem a tesztrendszeren.
Hát, a mindjárt kicsit elhúzódott, ugyanis szégyen ide vagy oda, de marha régen jártam már erre, tizensok patch várta toporzékolva, hogy feltelepüljön. – Jól van, aranyoskáim, azonnal – nyugtattam meg a virtuális gépeket és rányomtam az install gombra.
Közben elmentem reggelizni. Visszajöttem, restart.

Nosza, nézzük azt a problémát. Elindítottam az outlook-ot a kliensen – erre közölte, hogy nincs Exchange szerver. Hoppá. Megpingettem, látta. Névre is, IP-re is. Mind a kettőt. Biztos az outlook2003 hülyéskedik – gondoltam – és beléptem egy másik tesztgépbe, ahol outlook2010 dolgozott. Ugyanaz. Ő sem látta az Exchange szervereket.
Mi a fenét csinálhattak a patch-ek?

Korán reggel volt, az agyam még nem bootolt be rendesen, pusztán ezzel tudom magyarázni, hogy már első körben ész nélkül nekiálltam guglizni. Lett is egy csomó találat, egyik vadabb dolgot mondott, mint a másik. Mindegyik szálnak utánajártam, de minden rendben volt, ezek nem okozhatták a hibát.
Kimentem a konyhába, főztem egy kávét. Innentől mondhatom azt, hogy nekiálltam módszeresen felgöngyölíteni a problémát. Exchange szerver, eventlog. Minden rendben, viszont másfél órával ezelőtt tömérdek piros felkiáltójel. Hmm, hmm. Nagyon sok. Ezt most mind olvassam át? Eh, ez másfél órával ezelőtt volt, nekem meg most van bajom. Majd visszanézek, ha nincs jobb ötletem.
Nézzük az Exchange szolgáltatásokat. Na, itt köptem vissza kis híján a kávét. Az automatikusan induló Exchange szolgáltatások durván fele csak úgy lógott a levegőben, köztük persze az Exchange RPC is. Mind a két szerveren! Ez azért már tényleg izgalmas. Indítsuk újra. Sorra végignyomkodtam a start gombot és a szervízek elindultak. Ráküldtem még vagy 5 refresh-t, de a szolgáltatások makacsul működtek. Ez egyre rejtélyesebb. Valahogy nyugodtabb lettem volna, ha a szolgáltatások egyszer csak maguktól megálltak volna.

Na, mindegy. Nézzük az outlook mit lát. Mindent. Mind a kettő. Mind a két Exchange szerveren. Fejvakarás.
Gyorsan megnéztem, amit a kora reggeli kérdéssel kapcsolatban akartam, aztán amíg válaszoltam, be is ugrott a megoldás. A kora reggel. A patch.
Idősporolás miatt egyszerre nyomtam rá mindegyik szerveren a Windows Update gombra, aztán reggeli után egyszerre a Reboot gombra. Az öt szerver (két DC, két Exchange, egy TMG) egyszerre állt le és egyszerre indult újra. Csakhogy. Amikor az Exchange szerverek szolgáltatásai keresték volna az AD-t, az még sehol sem volt. Emiatt vésték tele piros felkiáltójellel az eseménynaplót. Később persze meglett az AD, de a szolgáltatások nem indultak el maguktól.

Tanulság? A reggeli kávé előtt soha ne pecseljünk.

Aláírva

Haladni kell a korral, mese nincs. Nem lehetünk annyira kiberszerencsétlenek, hogy nincs saját tanúsítványunk. Hiszen jó dolog a nick, meg az avatar, de mennyivel vagányabb már, ha tanúsítvánnyal tudjuk igazolni, hogy mi vagyunk mi.

Oké, értem én, a tanúsítványos játék soha nem volt igazán egyszerű. Illetve, ha megpróbáltuk egyszerűvé tenni, mindjárt drága lett. Csináljunk saját CA szervert? Hát, az elég macera, ráadásul ki fog csak úgy megbízni a szerverünkben? Kérjük meg az embereket, hogy léccilécci tegyék a szerverünk tanúsítványát a Trusted CA Servers tárolójukba? Aha. Akkor már inkább vegyünk egyet valamelyik nagy CA szervezettől. Persze, ez pénzbe kerül.
A jó hír az, hogy nem mindig. Ha például magánszemély vagy, akkor a Comodo-tól(1) ingyen kapsz levelezésre használható tanúsítványt.

(1) Vagy akinek jobban tetszik, InstantSSL. Mindenesetre, ahogy maguk állítják, ők a második legnagyobbak a piacon, azaz ahhoz mindenképpen elég nagyok, hogy az általuk kiadott tanúsítványt valószínűleg mindenhol elfogadják a világon.

Meggyőztelek? Remek. Akkor nyomjál is rá bátran a megrendelő gombra.
Illetve, ne, várj egy kicsit. Milyen böngészőt használsz?

Elmesélem, hogyan jártam. Miután megrendeltem a tanúsítványt, közölték, hogy nagyon örülnek és küldenek a subject-ként megadott emailcímre egy levelet, melyben leírják a további teendőket. Ez nem volt bonyolult, rá kellett kattintani egy linkre. (Vagy elmenni egy weboldalra és beírni a levélben megadott emailcím/jelszó párost.) Oké, katt. Nagy büdös error.

“The server returned an invalid client certificate. Error 207 (net::ERR_CERT_INVALID).”

Mi van? A Comodo-t már megint meghekkelték? Márpedig bármelyik módszerrel próbálkoztam, mindig ezt az üzenetet kaptam. Benéztem a böngésző (Chrome) beállításai közé, hátha valahol túl szigorúra van állítva a tanúsítványok kezelése, de nem találtam semmit.
Jó, nézzük a többi böngészőt. Kimásoltam a linket. Firefox. Egy abszolút értelmezhetetlen hibaüzenetet kaptam. Opera. Lefagyott. IE9. Na, ez végre meglepően őszinte volt, azt írta, hogy szerinte nem a megfelelő böngészőt használom.

Ilyenkor marad a gugli. Nos, mondanom sem kell, az üzenetnek semmi köze a valósághoz. Szokás szerint.
John Robbins írta le a frankót, igaz, ő egy fizetős Comodo (kódaláíró) tanúsítvánnyal szívott.

A quick round with Comodo support and I find out Chrome and IE 9 are definitely not supported. They sent me a link with their instructions for downloading the certificate. The first line had me shaking my head:
1) Open http://www.instantssl.com/code-signing/ in Internet Explorer (IE) 6 or 7 with ActiveX enabled. (Windows XP preferred)

Hát, izé. Most akkor szedjem le az IE9-et, tegyem fel az IE8-at, kapjam le a tanúsítványt, majd upgradeljek vissza IE9-re? Elég rondán hangzik. Próbáltam kreatívan értelmezni az IE9 korábbi üzenetét. Mi van, ha a tanúsítványigénylő folyamat során a Comodo belerakott egy sütit a böngészőbe, mely később kellett a tanúsítvány letöltéséhez? Hiszen ez is belefér az üzenetbe.
Újabb próbálkozás. Chrome-ból visszavonattam a kért tanúsítványt, simán megtette. Majd átléptem az IE9 alá, bízva abban, hogy a John írásától eltelt egy évben csak észrevették a Comodo-nál, hogy van IE9 is. Újabb igénylés, most IE alól léptem be a gmail fiókomba – és tadam. Megkaptam a tanúsítványt, be is tette a Personal fiókba. (Nyilván kimentettem, és eltettem biztos helyre is.)

Tulajdonképpen ennyi. A többi már egyéni szociális probléma: a gmail-t ugyanis eddig senki nem értesítette, hogy egy levelet alá is lehet írni, sőt, akár titkosíthatnám is. Az hagyján, hogy a webes felületen erre semmi lehetőségem sincs, de ha aláírt levelet kapok, azzal sem tud mit kezdeni a kliens.

From Segédlet

A képen is látható, hogy a feladó publikus kulcsát tartalmazó tanúsítványt és az email lenyomatát is magában foglaló bináris cuccot a gmail egyszerűen csak egy p7s csatolásnak mutatja, anélkül, hogy értelmezné. Körbedolgozni persze lehet, a gépemen van Outlook is, abba felvettem a gmail fiókomat, aztán legfeljebb az aláírt leveleket innen küldöm. Csak éppen borzasztóan nem elegáns a dolog, mivel ekkor az elküldött levél nem ugyanabba a Sent Item folderbe kerül, márpedig én az esetek 99,99%-ában a webes felületről levelezek.

Ha esetleg kedved van még a témával kapcsolatos anyázást olvasni, tudom ajánlani Jason Perlow írását a zdnet-en. A cím önmagában is telitalálat és remekül illeszkedik hozzá az illusztráció is.