Categoryexchange

Exchange patch és egyebek

Nemrég megkérdezték tőlem, miért paráznak az Exchange adminok a hotfixek telepítésétől. Megemlítettem, hogy két olyan esetről is tudok, amikor egy-egy rollup pack hazavágta a rendszert, és a kardjukba dőlt adminokat nem igazán vigasztalta, hogy az MS később visszavonta a csomagokat.

Nos, itt egy újabb csapda. Azt írják az Exchange blogon, hogy habár a Windows Update / WSUS / SCCM mind lelkendezve ajánlja ki az opcionális frissítések között a Windows Management Framework 3.0-t – igen, benne a csábos Powershell 3.0-val – az Exchange 2007/2010-et futtató gépekre inkább ne telepítsük. Ha mégis feltennénk, számíthatunk arra, hogy a rollup packok nem települnek fel, illetve az EMS begolyózik. Szóval óvatosan.

targetAddress avagy spóroljunk a licenszeken

Most következik az az eset, amikor bebizonyítom, hogy nem értek az Exchange-hez.

Mit csinálunk olyankor, amikor van egy email címünk, amiért a saját Exchange szervezetünk a felelős, de az ide érkező leveleket tovább kell küldenünk egy külső címre, és saját rendszerünkön soha egy darab levelet sem kell tárolnunk, ami a megadott címre érkezik?

Én (és az a gyanúm, hogy ezzel nem vagyok egyedül) a következőt tettem a fenti esetben. Létrehoztam a saját címünkhöz egy postaládát, a külső címhez egy kontaktot és a postaládát ráirányítottam a kontaktra. Megbékéltem azzal, hogy ez ronda, sőt minden egyes ilyen akció visz magával egy nem is túl olcsó CAL-t.

Mostanában a több ügyfélnél az Exchange 2003 – Exchange 2010 Cross-Forest migrációval birkózom (ez egyszer még megér egy másik cikket). Ennek kapcsán meglepetten tapasztaltam, hogy a migráció végén a rendszer egy olyan Mail Enabled User-t (ez ugye Exchange szempontból egy kontakt, és mint ilyen nincs postaládája) hagy maga után. Ami viszont képes leveleket továbbítani pontosan úgy, ahogy a fenti kérdésben szerepel.

Némi nyomozás után kiderült, hogy a tettes a targetAddress nevű AD property. Tehát minden levél, ami a kontakt egyik proxyaddress-ére érkezik azt a rendszer tovább küldi a targetAddress property-ben szereplő címre. Ráadásul a rendszer azt a kedvességet is megteszi (mind Exchange 2003 mind 2010 esetén), hogy a targetAddress property-t eleve kitölti a kontakt email címére.

Ebből adódóan az eredeti kérdésre adott válasz így változik:

Felveszünk egy kontaktot a külső címmel, majd a kontakt proxyAddresses listájába felvesszük az átirányítani kívánt saját címet.

Kész vagyunk. Mínusz egy CAL.

AntiSpam Update

Van egy dolog, ami már jó ideje bosszant.

Az Exchange 2007/2010 lehetőséget biztosít arra, hogy a Hub Transport szerveren feltelepísük a Microsoft AntiSpam agent-jeit. Ezzel kapunk egy jól működő, nagy tudású spam szűrő infrastruktúrát.

Ez ugyan nem annyira hatékony, mint a ForeFront for Exchange, továbbá nincs benne vírusirtó, viszont ingyen van.

Amikor ez a lehetőség először megjelent az Exchange 2007-ben, akkor lehetőségünk volt arra, hogy a hozzá tartozó definíciós fájlokat automatikusan frissítsük (Ez a ForeFront nélkül 3 hetente történt). Ez a lehetőség egy adott ponton megszűnt. Pontosabban, ha nincs ForeFrontunk akkor az Exchange maga nem frissít, hanem ezt a Windows Update teszi meg helyette.

Ezzel viszont gond van. Én magam részéről szerveren sosem kapcsolom be a frissítések automatikus telepítését (csak az automatikus letöltést), mert a folyamatos üzem miatt az nem elfogadható, hogy a szerver újrainduljon, amikor az update-nek ehhez van kedve, ráadásul bizonyos környezetekben a biztonsági frissítések csak tesztelés után kerülhetnek az éles rendszerbe. Ebből adódóan nem csak a biztonsági frissítések, hanem az AntiSpam definició sem települ automatikusan, aminek pedig kellene.

A fenti állapotot kezelendő írtam egy kis javascriptet ami feltelepíti az AntiSpam definíciós fájlt. És csak azt. Ha ezt a kis scriptet (cscript.exe SpamUpdate.js) berakjuk a Task Scheduler-be akkor a fenti problémát megoldottuk.

A script innen tölthető le.

Exchange 2013 – mégegyszer

A múlt heti hír folytatásaként, akit ez érint, annak leírom. A vártnál kb. három héttel korábban Október 24-től az MSDN és a Technet előfizetőknek letölthető az Exchange 2013 (továbbá a Lync 2013, az Office 2013 és a SharePoint 2013) .

Forrás: http://www.howexchangeworks.com/2012/10/exchange-lync-2013-rtm-bits-in-technet-msdn.html

Exchange 2013

Biztos már mindenki tud róla, de kiteszem ide is. Elkészült a végleges Exchange 2013.

További infó itt: http://blogs.technet.com/b/exchange/archive/2012/10/11/the-new-exchange-reaches-rtm.aspx

P.S. Már nagyon unom ezt. Harmadszor írom le a fenti szöveget. Először a gépem szállt el kékhalállat, másodszor pedig az IE-t nem szerette a WordPress.

Vissza a múltba

Kérdés jött az ügyféltől: hát mi most mit csináljunk? A helyzet röviden: lejárt a korábbi tanúsítványuk, meg szerették volna hosszabbítani, de a szolgáltató már nem volt hajlandó olyan SAN tanúsítványt kiadni, amelyikben belső név (cegnev.local) is szerepel. Ekkor viszont összedől az Exchange publikálásuk.

Első körben az volt a reakcióm, hogy szolgáltatót gyorsan kirúgni és keresni helyette egy másikat, amelyik nem ennyire vaskalapos. De mielőtt válaszoltam volna, a biztonság kedvéért futottam egy kört a guglin, és… eltátottam a számat.

  • http://help.securepaynet.net/article/6935?ci=72665&prog_id=wittyweb&isc=ssl-01
  • Ha jól értelmezem, akkor a tanúsítványszolgáltatók összedugták a buksijukat és arra jutottak, hogy az internet biztonságosabbá tétele érdekében legkésőbb 2016 októberéig mindegyikőjük visszavonja az összes olyan, általa kiadott tanúsítványt, amelynek akár a Primary Domain, akár a Subject Alternate Name mezőjében belső név, vagy privát IP cím szerepel.
    Ezzel gyakorlatilag ki is nyírták az összes olyan Exchange publikálást, ahol a belső tartományt nem split DNS alapon hozták létre, azaz a belső tartomány neve nem egyezik meg a cég külső nevével. Azaz hiába örvendeztünk pár évvel ezelőtt, hogy vége a tengernyi szopásnak, használhatunk SAN tanúsítványt az Exchange publikálásokhoz… ennek vége. Elvették a játékunkat.

    Informatikai közhely, hogy a biztonság és a kényelem egymást kizáró fogalmak: ha szigorítom a biztonságot, csökken a kényelem. Mindenki ismeri a sztorit, hogy az egyre hosszabb, egyre bonyolultabb jelszavak elméletileg növelik a biztonságot, de csak egy ideig, mert ha a felhasználó már képtelen lesz megjegyezni, akkor leírja egy papírra és kiragasztja a monitorra. Nesze neked, biztonság.
    Úgy néz ki, most is elértünk erre a szintre. Mit fog csinálni az egyszeri rendszergazda? Az, amelyiket komoly felvilágosító munkával éppen nemrég sikerült meggyőzni, hogy felejtse el a saját tanúsítványt és használjon szolgáltató által kiadottat? Szó nélkül visszatér a saját tanúsítványra. Itt olyan SAN tanúsítványt állít ki, amilyet akar, a terjesztését meg megoldja valahogyan. Mert akkorát szigorítottak a biztonságon, melyet már nem tud lekezelni.

    Illetve… van egy másik út, a mazochizmus útja. Nem, nem arra gondolok, hogy átnevezzük a tartományainkat, vagy létrehozunk egy új Active Directoryt és átmigrálunk bele mindent. Ez már nem mazochizmus, hanem öngyilkosság. Ellenben visszautazunk a múltba. Oda, amikor az Exchange 2003 publikálásoknál még nem volt SAN tanúsítvány. Persze azóta a világ sokkal bonyolultabb lett, de az elv maradt a régi:

    Végeztünk? Hát, ha szigorúan az Exchange könyvtáraira gondolunk, akkor igen. De mi is van az Outlook Anywhere mögött? Az RPC over HTTPS, mely gyakorlatilag két könyvtár az IIS default site alatt. Igen, default. Tehát ezeket is duplázni kell az új site alá. Létezik new-rpcvirtualdirectory parancs? Nem igazán. Mi a megoldás?
    Hekk.
    Meg kell keresni a default web site alatt az ApplicationHost.config fájlt, átmásolni az új site alá, majd átmásolni az rpc, rpcwithcert virtuális könyvtárakra vonatkozó részeket, értelemszerűen módosítva a sitenév bejegyzéseket. (Részletesen itt olvasható a módszer. Senkit ne tévesszen meg, hogy ez az RD Gateway szolgáltatásra vonatkozik, a gyakorlatban ugyanazokat a virtuális könyvtárakat használja, mint az Outlook Anywhere. Egy korábbi, az RD Gateway-t is érintő írásomban az egyik módszer konkrétan úgy is kezdődik, hogy a TMG-n használjuk az Exchange varázslót a publikáló szabályhoz.)

    Haladjunk tovább:

    • Az új site-hoz kötözzük hozzá a tanúsítványszolgáltató által kiadott tanúsítványt (melyben már nincs benne a cegnev.local név).
    • A reverse proxy-n (ISA, TMG, etc) gondoskodjunk róla, hogy az új site szolgáltatásai legyenek kipublikálva. (A nevekre figyeljünk oda, amennyiben szükséges, forgassuk a könyvtárneveket is.)

    Nagyjából ennyi. Az Exchange már működik. De olyan nagyon azért ne sóhajtsunk fel:

    • Mi lesz a Sharepoint szolgáltatásokkal?
    • Mi lesz az RD Web oldalunkkal?
    • Végül mi lesz az OCS\Lync szolgáltatásokkal?

    Agyhalál. Biztonságos internet. Ja.

    A mentés ronda lelkivilága

    Ritkán szoktam az Exchange blogról linkelni, valahogy úgy érzem, hogy aki érdeklődik a téma iránt, az úgyis rajta lóg az rss csatornájukon. Most viszont kitettek egy nagyon-nagyon-nagyon hiánypótló írást, melyet mindenkinek el kell olvasnia, azoknak is, akik csak ezt a blogot követik. (“Ha én valamit szeretek magamban, az a szerénység.”)

    Export-mailbox, szomorodj meg

    Hajnalban megállt az export. Azt mondta, hogy

    Export-Mailbox : Error was found for XY (xy@cegnev.hu) because: Error occurred in the step: Approving object. An unknown error has occurred., error code: -2147221219 At line:1 char:2312
    + CategoryInfo: InvalidOperation: (179:Int32) [Export-Mailbox], RecipientTaskException
    + FullyQualifiedErrorId : 7D782610,Microsoft.Exchange.Management.RecipientTasks.ExportMailbox

    Próbáltam utánajárni, mi is lehet ez. Volt a neten minden, zárjam be az Outlookot (ki sem volt nyitva), állítsak be valós default gateway-t (be volt), vagy futtassak le egy fixmapi nevű programot. Pusztán kíváncsiságból ráküldtem ismét, minden módosítás nélkül ugyanazt a parancsot, amelyen elhasalt. (Természetesen az exportálandó postafiókok közül kivettem a már készeket.) Simán vette az akadályt, most is az fut.

    Megvan, mi lehetett a probléma: alvás közben nem imádkoztam elég intenzíven. Aztán eddig tartott a deikus töltet.

    Ideges? Á, egyáltalán nem vagyok az. De reggel simán bevettem a savcsökkentő (kék) gyógyszerem helyett az éjszakai (fehér) koleszterincsökkentőt.

    Halott ember visszalő

    Ezt írtam korábban:

    Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni.

    Naív dolog volt azt hinni, hogy a windowsupdate ennyiben fogja hagyni. A nagy kapkodásban a kolléga ugyanis automatikus beállításon hagyta, én meg elfelejtettem leellenőrizni – őszintén szólva, egyikünknek sem jutott eszébe, hogy egyáltalán létezik – az a dög pedig, mármint a windowsupdate, hajnalban restartolta a gépet, teljeskörűen ignorálva azt, hogy milyen fontos processz fut rajta.
    Kora reggel, még félig kinyílt szemmel néztem rá a monitorra és elhűlve láttam, hogy nem látok semmit. Megszakadt a session. Meg a jókedvem. A kiadott utasítás ugyanis úgy nézett ki, hogy a get-mailbox parancs kimenetele volt belecsövezve az export-mailbox parancsba. Csakhogy a get-mailbox a jó ég tudja, milyen alapon rendezi sorrendbe a postafiókokat, de hogy nem ABC sorrendben, az biztos. Kénytelen voltam lehúzni egy listát, kimazsolázni, hogy kinek készült már el a pst-je, a többiek nevét pedig úgy összerakni egy szövegszerkesztőben, hogy be lehessen tolni az export-mailbox parancsba. Mindezt kora reggel, még kávé előtt.
    Oké, elkészült, parancs átmásol a PSH ablakba, enter – váratlan PS hiba. Ó, hogy szomorodj meg! De most legalább már tudtam a megoldást. Szerver, kliens újraindít. (Közben gyors kávé.) Beléptem a kliensre, parancs átmásol a PSH ablakba, enter – és ismét váratlan PS hiba. De most tényleg váratlan, mert még én sem számítottam rá. Egyből le is konyult az orrom. Ez most már minőségileg más helyzet, innen hogyan tovább? Aztán eszembe jutott egy fontos momentum: újraindítás közben elfelejtettem imádkozni. Tehát újraindítottam a klienst és a szervert _még egyszer_, közben barbár imákat mormoltam és a biztonság kedvéért elővettem a legcsúnyább nézésemet is. És most már elindult a szkript. Hogy az informatika egzakt tudomány? Persze, királyfi.

    Egyébként tényleg hihetetlen ez az egész és nevezhetném groteszk balszerencse-sorozatnak is, de vegyük észre, hogy van azért mögötte nem átgondolt, kapkodós gányolás is. Ha még emlékszünk, az Exchange 2007 trágya, félkész állapotban jött ki a piacra, és a nagyon várt, de időhiány miatt kimaradt funkciókat utólag hegesztgették bele, service és rollup pack-ek segítségével. Ilyen utólag beleműtött dolog volt az export-mailbox kibővítése a pst fájlok kezelésével. Ezen különösen látszik az utólagos toldozgatás, hiszen egy alapvetően szerveroldalon optimális folyamatot raktak ki a kilens oldalra, azért, mert ott már volt pst-t kezelni tudó MAPI motor, az Outlook. Igaz, emiatt a teljes adatbázismennyiséget át kell tolni kétszer a hálózaton, a feldolgozást egy erőforrásait tekintve sokkal-sokkal gyengébb gépen kell futtatni (Exchange 2007 esetén 32 bites kliensen), és akkor még nem is beszéltünk a kliensgépek speciális nyűgeiről, mint például a tipikusan automatikusra állított windowsupdate szolgáltatás, vagy éppen a rafinált csoportházirendek.

    Na, mindegy, újabb fél nap csúszás, azaz most már egy teljes nap.

    Powerhell

    Nevezhetjük szerencsének, de eddig még sikerült megúsznom a postafiókok nagy tömegben történő exportálását pst fájlokba. Eddig. Háát…

    A környezet ránézésre nem túl veszélyes. 230 postafiók, 160 GB adatmennyiség. A szerver jól méretezett. A kliens, amelyikről a másolást végezni kell – a lehetőségekhez képest – szintén.
    Ezen azért rugózzunk egy kicsit, mert később fontos lesz. Exchange 2007, az export-mailbox követelménye 32 bites(!) Outlook 2007, szigorúan 32 bites(!) Windows 7-en. Erre kell még egy 32 bites Exchange 2007 admin csomag.
    Még a tesztfázisban összeraktam egy virtuális kliensgépet, hogy ismerkedjek a folyamat dinamikájával. Másra nem is volt jó, mert diszk, az nem volt mögötte, de sikerült bejátszani a parancsot, eljátszottam a nyelvi beállításokkal, szóval felkészültem.
    A migrációra a helyi emberünkkel közösen összeraktunk egy kliensgépet. Az éles indulás előtt ezen is teszteltem egy kicsit, minden működött, mint egy svájci óra.
    Eldördült a startpisztoly, levélforgalom leállít, a kliensen parancs kiad, elégedetten hátradől. Kábé 10 percig. Ekkor kezdett el sikítozni a Windows, hogy eldobta az agyát. Konkrétan elfogyott a memóriája. Ezzel párhuzamosan a másolás is beállt, mint a gerely. Kilőttem a taszkot. Fejvakarás. Nem túl sokáig, mert a helyzet hamarosan világossá vált. A Windows ugye 32 bites, ebben a maximum RAM 4 GB lehet. Volt még a pagefile, a kettő együtt 10 GB. Az export-mailbox egyszerre 4 szálat indít és balszerencsémre rögtön az első csoportban benne volt a titkárság postafiókja, nem is mondom, mekkora mérettel. Lúzer hiba volt. Felnyomtam a virtuális memóriát 40 GB-re, restart, aztán elkezdtem újra.
    Nem indult el. A powershell fél perc szutykolódás után váratlan hibát dobott, a legsemmitmondóbb 1000-es hibaüzenettel. Újraindítás már volt, tehát ebben sem reménykedhettem. Mi romolhatott el? Persze, játszottam még a parancs maxthreads paraméterével, de el se jutott odáig a folyamat, a powershell sorra dobta a váratlan hibákat. Pedig addigra már megszokhatta volna.
    A leginkább logikus gondolat az volt, hogy amikor erőszakosan kilőttem a powershell processzt, akkor megsérülhetett valami alkotóeleme és azóta a PS nem tér magához. Telepítsük újra! Ahogy azt Móricka elképzeli. Mivel Windows 7 esetében már beépítve jön a PS 2.0, így nem lehet külön letölteni. Feature-ként sem lehet eltávolítani, majd visszarakni. Ekkor szóltam a kollégának, hogy B terv, kezdjen el telepíteni egy másik munkaállomást. Itt már lejjebb adjuk az igényeket, eszébe se jusson windowsupdate-tel foglalkozni. Én pedig előre menekültem. Rakjunk fel WMF3 CTP2 csomagot, abban van Powershell 3. Aztán majd meglátjuk, mit csinál. Semmit. Fel sem települt. Azt mondta, hogy neki szigorúan angol nyelv kell, ez meg nem az. De meg lehet engesztelni egy angol language pack-kel. Töltsük le! Hát, nem. Nyelvi csomag eleve a Windows Update-ről szedhető le, ultimate és enterprise Windows 7 esetén. Csakhogy mi itt professional verzióval szopunk. Elvileg leszedhető az MSDN-ről a teljes csomag, de mire a 2 GB lejön, addigra a kolléga újrahúzza a gépet. És még ekkor sem garantálja senki, hogy nyelvet tudok váltani, hiszen a professional eleve nem lehet többnyelvű.
    Csapásváltás. Menjünk vissza a legutóbbi rendszermentéshez, töltsük vissza, aztán telepítsünk mindent újra attól a ponttól. Röpke félóra alatt meg is csináltam, restart, újabb próba, újabb váratlan PS elszállás.
    Hát, ezzel nem jutottam sokat előre.
    Közben kolléga felhúzta az új gépet, gyorsan kipreparáltam, maxthreads a biztonság kedvéért kettőre állítva, aztán hajrá. Nem hiszed el: ezen is váratlan Powershell hiba történt. Meg lehetett volna mintázni rólam a bambaság szobrát.

    Vicc.

    – Doktor úr, nagy baj van!
    – Mi a panasza?
    – Ha megnyomom a lábam, fáj! Ha megnyomom a derekam, fáj! Ha megnyomom a tarkóm, fáj! Milyen betegség az ilyen?
    – Valószínűleg eltörött az ujja.

    Azaz ha több kliensen is ugyanazzal a hibával száll el egy folyamat, akkor lehet, hogy a szerver a hibás. Mágikus restart. A biztonság kedvéért a kliensen is. Másolás elindít, összes végtaggal imádkozik. És igen, ez volt a probléma, a Powershell váratlanul jól működik.

    Vegyük észre az eset szépségét. A 32 bites kliensen elindított, 32 bites Exchange modullal feljavított Powershell (aka EMS) menetközben meghívogatja a 32 bites Outlook MAPI motorját, ezen keresztül próbálja meg leszívni a szerverről a levelezési tartalmakat és kirakni pst fájlokba. Aztán elfogy a RAM, ki kell lőni a taszkot, és mi hal meg tőle? A szerver. Finom.

    Mindegy, elméletileg örülhetnénk is… csakhogy itt a háromnapos ünnepre terveztünk egy háromnapos átállást. Ebből elveszett a péntek délután, az export legjobb esetben is csak szombat délre fejeződik be és igencsak csipkedhetjük magunkat, hogy ezt a fél napot behozzuk valahogy.

    Én mindenesetre halk sóhajjal betoltam az Alvin albumot az mp3 lejátszóba.

    Ott szorít, ahol szűkebb

    Egy nagyon jó nyomozás leírása Paul-tól. Érdemes végigolvasni, megnézni, hogyan gondolkodott, milyen eszközöket használt és hogyan göngyölítette fel az esetet. Majd hasonlítsuk össze, hogyan oldottam meg anno én egy ránézésre teljesen különböző, de valójában ugyanarra a konfigurációs hibára visszavezethető problémát, pusztán a józan eszem és a Salvador Dali-féle paranoiac-critical módszer segítségével.

    A message tracking log használata – másképpen

    Minden Exchange admin nagy barátja a message tracking log, rendszerint ennek segítségével tudjuk átrugdosni a dögöt az utca másik oldalára, azaz így bizonyítjuk, hogy a levél rendben kiment az Exchange organizációból, a továbbiakban pedig legyenek kedvesek a fogadó oldali rendszergazdát zaklatni.

    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.

    Internet Database Availability Group

    Amikor elkezdtem olvasni Scott cikkét, egyből elcsöppent a nyálam. Épp mostanában van egy olyan munkám, hogy bár az ügyfélnek nincs túl sok pénze, de szeretne egy olyan HA megoldást két telephelyen, melyek még akkor is működnek, ha a Föld megsemmisül. Üzletpolitikailag meg nem mondhatjuk azt, hogy nem.
    Szóval olvastam, olvastam, és bár a működését elsőre még nem láttam át teljes mélységében, de nagyon tetszett a dolog. Végülis nem akárki írta a cikket, aki Scott Schnollnál többet tud az Exchange HA területről, az már festi magát. És pont most jöttek ki vele, pont amikor égető szükségünk lenne rá. Remek.

    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.

    Imádom a lehetetlen küldetéseket

    Napok óta a Windows 8 bétával foglalkozik a szakmai blogoszférának a Windowsra érzékeny része. Olyannyira benne van a levegőben, hogy már én is elgondolkoztam, hogy feldobok egy szervert és egy klienst a tesztrendszeremre. Ha időm lesz. Ha.

    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.

    Riport szkript

    Pár bejegyzéssel ezelőtt írtam néhány EMS parancsot, hogyan lehet lekérdezni egy-két fontos adatot egy Exchange adatbázisról. Nos, ahhoz képest itt van egy nagyágyú. Steve Goodman még a nyáron összefarigcsált egy igen komoly riportáló szkriptet, mely nem csak hasznos adatokat szed össze egy Exchange organizációról, de a kimenete is egy látványosan formázott html, melyet egyből le lehet tenni bármelyik CIO/ügyfél asztalára. Sőt, a szerző határozottan bátorítja az érdeklődőket, hogy nyugodtan bővítgessék a szkriptet olyan lekérdezésekkel, melyekre a meglévők mellett még szükségük van.

    Exchange 2010 SP2

    Ma az egyik kollégámmal egy rendszer átállásáról beszélgettünk. Felmerült lehetőségként, hogy mi lenne, ha építenénk egy Exchange 2010 hosting környezetet amibe nem csak az ügyfél adatai kerülnének, hanem a sajátjaink is. Természetesen felmerült az alap kérdés: GAL separation. Innen jött a kérdés: Mikor lesz SP2 ami ezt már tudja.

    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

    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.

    Exchange javítások

    Két új hotfix jelent meg.

    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.

    Exchange 2010 OWA – Kép az aláírásban 3.

    Milyen nehéz is elérni valamit amit a Microsoft nem tervezett bele eredetileg a termékbe. Már két körben írtam a témáról, hogyan helyezzünk el képet az OWA aláírásban. Ez a történet harmadik, de már most biztosan nem utolsó része.

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

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

    http://www.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.