Paul Cunningham mutatott be egy másik lehetőséget, melyhez szintén a jó öreg MTL-t használjuk: addig gyötörjük, amíg nem összesíti nekünk a napi levélforgalmainkat. Hasznos információ? Igen. Hozzá lehet férni valami egyszerű módon? Tudomásom szerint nem.
A megoldást nem teszteltem, nem tudok beszámolni gyakorlati tapasztalatokról – de mindenképpen használható ötletnek tűnik.

Elkövettem egy Windows Update reset-et (SoftwareDistribution, catroot2 mappa töröl). A Windows Update friss meleg ropogósnak tűnik. Mint amit még sosem futtattak. Lefuttatom. Még mindíg közli, hogy kéne neki egy IE9.

Gugli a mi barátunk:

http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/2c252dbe-c833-424d-9b75-4948bb8fb816

Jó hosszú. Összefoglalva:

1. Szedd le az IE9-et (a Programs and Features alatt, ha megjeleníted az update-eket akkor látod és le is tudod szedni)

2. Rebbot

3. Töltsd le a standalone telepítőt innen: http://windows.microsoft.com/en-US/internet-explorer/downloads/ie-9/worldwide-languages

4. Telepítsd fel /update-no kapcsolóval

5. A Windows Update-ből rakd fel a felkínált cumulative fix-et.

Van a DMZ-ben egy levelezőszervered – mondjuk egy Exchange Edge – és az SMTP portját egy TMG szerveren keresztül szeretnéd kipublikálni. Ez nem lehet komoly feladat, a varázsló 2004 óta szinte semmit sem változott. Illetve…

From Segédlet

Ez bizony egy zavarbaejtő kérdés. Azt mondja, van másik, van jobb… miért használod ezt a régi szutykot?

Ne dőljünk be neki.

Ha ugyanis az általa felajánlott E-mail Policy varázslóval publikálunk, akkor a szerverünk SMTP portja nem lesz elérhető kintről. Még ha véres verítékkel szétkonfiguráljuk a TMG-t, akkor sem. Egy apróságot ugyanis elfelejt a kuruzsló közölni: E-mail Policy-t csak és kizárólag akkor tudunk használni a TMG-n, ha telepítünk rá egy Exchange Edge szervert is.

Az már egy teljesen más téma, hogy a fenti felállásban igencsak elgondolkodtató, hogy az Edge szervert ne a DMZ-be tegyük, hanem a TMG-re. Az integráltság ugyan növekszik – és ezzel vétünk a KISS-elv ellen – de megspórolunk egy Windows Server 2008 R2 licenszt. Amennyiben viszont más gyártó smarthostját használjuk, akkor nyomjunk pánikszerűen egy No-t és haladjunk tovább.

A lelkesedésem egészen addig tartott, amíg észre nem vettem az írás végén a tag-eket.

ps.
Persze, folyamatosan nyüzsgött agyam hátterében a kisördög: mi is van azzal a kritikus round-trip latency-vel, az adatbázisok rpcclientaccessserver paramétereivel, na meg a CAS proxyzásokkal? De olyan jó lett volna hinni benne, hogy ezt mind-mind megoldották.

Viszont vannak olyan emberek – és az összes kalapomat megemelem előttük, pedig van pár – akik nem elégszenek meg azzal, hogy felraknak egy Windows 8 szervert, hanem úgy istenigazából nekiszaladnak és megnézik, hol vannak a határai. És mennyire kemény betonból vannak.

Paul Cunningham úgy döntött, hogy Exchange 2010-et telepít a béta Windows 8 szerverre. És nem riasztotta el, hogy ez abszolút nem támogatott. És akkor sem dőlt a kardjába, amikor a telepítő is közölte vele ezt a hírt. Hiszen a registry-t lehet editálni is, és miért ne hazudhatnánk be a Windows 2008-at (6.1) a Windows 8 (6.2) helyett? Ja, hogy a telepítés után nem indul el az Exchange? Kérem, ha már elkezdtünk hekkelni, miért állnánk meg pont itt?

A teljes cikk: Installing Exchange Server 2010 on Windows Server 8 Beta.

Szerdán ügyfélnél voltam. A tervezett munka aznapra két hyper-v host beüzemelése volt, négy-négy virtuális hálózattal, mindegyiken két virtuális gép, ezekből egy-egy tartományvezérlő egy új AD-ban. Semmi izgalmas, mondhatni rutinmunka.
Lett volna. Ha kedden nem küldött volna ki az MS 9-12 hotfixet. Mely hotfixek nem telepítés közben találják el a rendszeremet. De igazából még ez sem lett volna baj, windows update jelez, telepítés megtörténik, gépek újraindulnak és mindenki megy a dolgára. Csakhogy… homokszem került a fogaskerekek közé. Az egyik host gépen lement a telepítés, csak utána valahogyan elfelejtett szólni, hogy újra kellene indítani a gépet a telepítés befejezéséhez. Én meg nem vettem észre, mert menetközben – igen, a szokásos időhiány – már telepítettem a virtuális gépeket is, és a sok gép, sok windowsupdate közben nem jelzett be a vészcsengőm, miszerint elmaradt egy újraindítás. És az is hiba volt, hogy először nem faragtam be az összes virtuális hálózatot, csak azt, amelyiken keresztül a virtuális gépek elérték a belső hálózatot, meg a netet. Úgy voltam vele, hogy telepítés közben mindig van egy csomó holtidő, majd aközben jól elkonfigurálgatok.
És ekkor lépett be Alice csodaországba. A virtuális hálózatok megadásánál változatosabbnál változatosabb hibaüzeneteket kaptam. Hogy nem tudja létrehozni, mert még az előzőn dolgozik. Abszolút nem zavarta, hogy nem volt előző. De persze a hibaüzenet után mégis létrehozta. Ránézésre jól, de használni mégsem lehetett. Ráadásul volt, amelyiket létrehozta, volt, amelyiket nem. Én meg bőszen undóztam, töröltem… végül valami óriási káosz alakult ki a virtuális hálózatokkal. Már most szólok, ha azt mondja, hogy egy hálókártyára nem tud virtuális switchet rárakni, mert már van rajta, ne kezdjél káromkodni, hogy de nincs is – szinte biztos, hogy a nagy kavarásban bekattintva maradt a kártyán az MS virtuális switch szolgáltatás.
Nem akarom a végtelenségig szaporítani a szót, végül belavíroztam magam egy olyan helyzetbe, hogy a hyper-v szerint egy, azaz 1 virtuális hálózat sem volt, a network panelen belül meg látszott nyolc hálókártya: négy virtuális switch és négy virtuális kártya. Miközben a társgépen – mely az utolsó csavarig megegyezett ezzel – minden simán ment, ha nem is elsőre, de harmadikra. Fejvakargatás. Ilyenkor tiszta haszon, hogy kopaszodom, mert van hol vakarni. A nyolc kártyából egy sem hagyta magát törölni, a konzol, ahonnan törölhettem volna, meg egyiket sem látta. Jobb híján maradt a visszaút a kályhához: hyper-v eltávolítása, majd újra felrakása. Árnyalta a helyzetet a már létrehozott két virtuális gép. VHD félrementve, hyper-v le, gép újraindul – és csak itt, ekkor ugrott ki, hogy be volt ragadva 11 patch. Köztük egy csomó szutyok dotnetes.
Az újraindítás után már ment minden simán. A virtuális gépek könyvtárait inkább töröltem, aztán hyper-v vissza. Mielőtt bármit is csináltam volna, befaragtam a virtuális switcheket. Elsőre. (Ez maradt meg tanulságnak: addig nincs virtuális gép, amíg pöpecül nincs kész a virtuális hálózat.) A hálózat után jöttek a gépek, a vhd-t felismerték, evoé. Pusztán csak fél nap helyett egy egészet csesztem el a feladatra, ami nem lett volna baj, ha időmilliomos vagyok – csak most éppen nem.

Csütörtök reggel. Egy bonyolult tesztrendszert kell összehoznom, jövő hét közepén már vagy húsz demó fog futni rajta. Nyolc gép, DC-k, Exchange szerverek, internetszimuláció, mindenféle kliensek – nem egyszerű környezet. Csütörtök reggel kezdenék… és megint egyre hülyébb jelenségekbe futottam bele. Nem húzom az időt: néhány gépen elfelejtettem kikapcsolni a windows update-et, ezek magukra rántották a patch-eket. Nagyjából a tesztrendszer 70%-ánál jártam, eldönthettem, mi legyen: vagy rárakom mindegyik gépre a hotfixeket, bevállalva azt, hogy innentől a tesztrendszer nem lesz kompatibilis magával, vagy visszamegyek a legutóbbi snapshot-hoz (jó messze az időben) és újra végigcsinálom az azóta elkövetett lépéseket. A hotfixek mellett döntöttem. Nem nyert. Két gépre az istennek sem ment fel, csak jöttek azok a legendásan értelmezhetetlen windows update hibaüzenetek. Oké, hagytam a fenébe. Csak éppen eltelt a délelőtt. Ebéd után végigcsináltam az újabb feladatokat, majd visszaálltam – a patch-ek utáni snapshotra. Azaz visszaálltam volna, mert a környezet ezer darabra szakadt. A kliensek látták az Exchange szervereket, a szervereken lévő konzolok meg nem. A névfeloldás úgy ahogy volt, meghalt. Szenvedtem még vele pár órát, majd B terv – vissza ahhoz a pár nappal ezelőtti snapshothoz, amikor még minden jó volt. Itt gyorsan letiltottam minden gépen a windows update-et és eljátszottam az utóbbi napok laborgyakorlatait. Így jutottam el péntek hajnalban oda, ahol csütörtök reggel kellett volna lennem. Amivel nem lett volna semmi baj, ha nem lennék borzalmasan beszorulva a határidők közé és nem kísérte volna ezt a tevékenységemet eddig is felfoghatatlan mértékű balszerencse.

A legjobban jellemzi a helyzetet, amikor csütörtökön napközben éppen az égre néztem és arra gondoltam, vajon mi jöhet még – erre a szélvihar miatt elment az internetkapcsolatom. Elsőre meglepődtem, de aztán elismerően bólogattam: igen, ez egy pontos találat volt. Sok mindenre számítottam, ezek mind be is következtek – de a szélvihar… az igen. Abban van fantázia.

Rákerestem.

Van.

Tegnap óta:

http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx

Letölthető innen:

http://www.microsoft.com/download/en/details.aspx?id=28190

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.

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

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.

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.

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.

Az egyik az Exchange 2010 SP1 soron következő immár 6-os rollupja. Letölthető innen, további infók róla itt.

A másik egy igen bosszantó, ugyanakkor nem életbevágóan fontos hibát hivatott orvosolni. Ha az Exchange Management Console-t futtató gépen fenn van az IE9 és a Mailbox szerepkör tualjdonságait piszkáljuk akkor nem lehet becsukni a konzolt. Ezt az üzenetet kapjuk és csak a Task Managerből lehet kilőni az MMC-t: “You must close all dialog boxes before you can close Exchange Manaagement Console.”

Bővebben itt.

Az előző kettő itt található:

http://emaildetektiv.hu/2011/08/18/exchange-2010-owa-signature-image/

http://emaildetektiv.hu/2011/10/03/exchange-2010-owa-signature-image-2/

A cikk második részének megírása után, a szükséges elemeket felraktam az ügyfél rendszerébe, majd nyugodtan hátradőltem, hogy nincs több dolgom a témában, csak teríteni az aláírásokat, amint az ügyfél emberei kitöltik a megfelelő adatokat az AD-ban.

Néhány nap múlva kaptam néhány teszt felhasználót, akiknél megvoltak az adatok, legeneráltam az aláírásokat képpel együtt, felhasználók tesztelnek, …

puff nagy pofon, nem működik.

Én tesztelek náluk az ő gépükön vnc-vel. Nekem megy.

Pár nap közdés után valaki rájött (ez nem én voltam), hogy ha új levelet küldök akkor jó, ha egy beérkező levélre válaszolok, akkor már az OWA-ban is egy nagy büdös piros x van a kép helyett. Tesztelés, ez bizony egy bug a rendszerben.

Két dolgot tehetünk:

1. Lejelentjük az MS-nek a hibát és reménykedünk, hogy megoldják.

2. Keresek valami megkerülő megoldást.

Hétfő (2011/10/17):

Mindkettőnek nekiugrottunk. A kollégák lejelentették az MS,nek én pedig elkezdtem Transport Agentet írni.

Estére el is készült az Agent váza, de még nem volt az igazi. Kollégám megfogalmazása erre a teszt levélre:

“az jó. csak mert abban igaz, hogy nem jön meg, de legalább a charcode is szar”

Hazamentem, este lett egy újabb öttletem, de az már nem fért bele a napba.

Kedd (2011/10/18):

Hajnalban nekiláttam, megcsináltam az Agentet, hibátlanul működött a teszt környezetben.

Lejelentettem, hogy jó, kértem a telepítéshez időpontot (Nem mennek a dolgok hű bele balázs módra, mert, ha minimális esélye van némi szolgáltatáskiesésnek, akkor arról mindenkinek tudnia kell. Itt volt ilyen, mert bizonyos struktúraválltás miatt az OWA tanúsítványát is cserélni kellet, ami az SSL Host header miatt okoz egy-két perc fennakadást)

Kaptam időt estére/másnap hajnalra.

Szerda (2011/10/19):

Hajnalban felraktam mindent.

Reggel ügyfél tesztel,…

Eredmény: szar.

Egész nap más dolgom volt, nem tudtam vele foglalkozni.

Este indolklás nélkül jön egy kérés, hogy kapcsoljam ki az OWA-ban a html link szűrést. Nem tudtam vele foglalkozni, majd holnap.

Csütörtök (2011/10/20):

Hajnalban elkezdtem tesztelni, hogy tegnap miért nem megy. Ki is derült, hogy a disclaimer a ludas (mert kérem itt aláírás is van, meg jogi nyilatkozat is). Ugyanis amikor beteszi a levél végére a szöveget akkor kiszedte az általam az aláírás html img tag-jébe becsempészett role=”contetntinfo:embed” attributumot (pedig szerintem ez szabványos, a W3C-től szedtem, modjuk a tag lezáró /> jelből is kiszedte a pert ami pedig az xhtml-ben már kötelező). Tehát a probléma orvosolható, ha az én Agent-em magasabb prioritást kap mint a Transport Rule Agent.

Valahol a tesztelgetés közepén beállítottam a tegnapi kérést. Engedélyeztem a HTML linkeket. Ettől meggyógult az eredeti probléma.

Mi van?????

Valaki akkora ész volt, hogy rájött, a piros x-es gondot az OWA “Web Beacon and HTML Filter” nevű szűrője okozza. Mekkora ász!

Reggel vissza is kérdeztem a kollágától:

- Erre ki jött rá?
- tesztelték.
SAP levélben linkek, nem tudták megbökni
- de arra, hogy ez megoldja az aláírásban kép balhét?
- arra senki.

Most őszintén. Ennek mekkora az esélye?

Agent kukába, a megoldás:

Get-OWAVirtualDirectory | Set-OWAVirtualDirectory -FilterWebBeaconsAndHtmlForms DisableFilter

Ugyan ez csökkenti a rendszer biztonságát, de valamit valamiért.

folyt. köv.