MonthMay 2008

Mail fájlok és a CDO 3. – Avagy Microsoft.Exchange.Data.Transport.Email

Miközben rakosgattam át a régebbi írásaimat erre a blogra ráakadtam két cikkre, ami arról szól, hogyan tudunk (milyen trükközések árán) egy CDO Message objektumba betölteni egy fájlként meglévő levelet:

http://www.emaildetektiv.hu/2005/09/12/mail-fajlok-es-a-cdo-1/

http://www.emaildetektiv.hu/2005/09/13/mail-fajlok-es-a-cdo-2/

Ez a feladat, valahogy mindig kísért a munkám során. Jelenleg Exchange 2007-hez írok egy Transport Agent-et, és a tesztelésnél ez megint előkerült. Közben természetesen megváltozott a környezet. CDO ugyan létezik még, de nem egy stratégiai fejlesztési irány. Nem COM-s dolgok készülnek, hanem .NET-esek. Megszűnt a régi jó kedvencem az SMTP Event Sink (amit scriptként is meg lehetett írni), Transport Agent lett helyette (ez már szigorúan .NET 2.0).

Ebből adódóan ennek a feladatnak a megoldása is megváltozott. Jóval egyszerűbb lett. Valami ilyesmi:

using System;
using System.Collections.Generic;
using System.Text;

using System.IO;
using Microsoft.Exchange.Data.Transport.Email;

namespace Messaging
{
    class Messaging
    {
        public static EmailMessage LoadMsgFile(string FileName)
        {
            Stream MsgStream = File.OpenRead(FileName);
            return EmailMessage.Create(MsgStream);
        }
    }
}

 

MVP Summit, Redmond, 2008

Iszonyú régóta hányódott ez a Onenote jegyzet a tenyérgépemben… jócskán itt volt az ideje, hogy megjelenjen.

Megtudta aztán a király, hogy honnan fúj a szél, hát a bíró lányát akarta megleckéztetni. Üzent is a szolgájáért:
– Édes szolgám, menj el ebbe és ebbe a faluba, mondd meg a bíró lányának, hogy látogasson meg engem, de se nem lóháton, se nem gyalog, se kocsin, se az úton, se az út mellett ne jöjjön. Ruhába is menjen, de meztelenül is legyen, hozzon is nekem ajándékot meg nem is, mert különben lefejeztetem.

Hát, valahogy így érzem magam. Hoztam is, meg nem is. Van egy csomó információm a következő Exchange verzióról, miközben szinte semmit nem lehet elmondanom az NDA miatt. De azért egy-két dolgot talán.

  • Az ún. Global Address List (GAL) bővebb lesz. Több információt fogunk látni a kollégáinkról az Outlook-on keresztül. Hja, közösségépítés…
  • Nem, továbbra sem lesz az Exchange alatt SQL adatmotor. Ahogy magyarázták, minden levélnek egy önálló SQL adattábla dukálna, így viszont komoly teljesítményproblémák lépnének fel. Marci folyosói kommentje szerint ez marhaság. Én ebbe nem tudok beleszólni, nem vagyok DBA.
  • Néhány komponens ki fog pusztulni. Meglepő módon olyanok is, melyek az Exchange 2007-ben debütáltak. Mondjuk ez utóbbiakra a kipusztulás nem igazán jó szó, a szerepkörük bele fog olvadni más funkciókba. (Köszönhető ez annak, hogy az SP1 egy-két újdonsága feleslegessé tett korábbi dolgokat. Szoftvertervezés? Ja.)
  • Adattárolás szinten komoly architekturális változások lesznek. Pontosabban nem is tárolás szinten, hanem reprezentáció szinten. Erről megint nem mondhatok sokkal többet, de erősen érződik, hogy az E14 lelkesen készül arra, hogy igazán komoly, robusztus nagyvállalati levelezőrendszer legyen belőle. Oké, még egy hint: a fiúk bátran továbbgondolták az Exchange 2007 database rehome lehetőségeit.
  • Daniel Petri szép nagy hasat növesztett tavaly óta.
  • Unified Messaging. Jelenleg ugye 16 nyelvi csomag létezik, de ebből csak egyben van beszédfelismerés is. (Vajon?) Az E14-ben 26 nyelvi csomag lesz – és mindegyikhez lesz beszédfelismerő modul is. (Nagy taps a teremben.) A magyar sajnos nem lesz köztük, a környékről a lengyelek és az oroszok kerültek be csak a döntőbe. (Viszont lesz indián nyelven is. Füstjelek?)
  • Ehhez kapcsolódik egy jópofa dolog: voice mail preview. Írásban.
  • Valami tragikus fog történni a Unified Messaging-en belül a fax szolgáltatással.
  • Hallgatva az idők szavára és figyelembe véve, hogy a felhasználók azért csak művelődnek az idők során, bizonyos adatkarbantartási lehetőségeket kipublikálhatunk a felhasználók felé. Ez egyfajta self-management lehetőség lesz. Mari néni a beszerzésről powershellezni fog. (Erősen valószínű, hogy tenni fognak rá valami grafikus felületet.)
  • A jogosultsági rendszer sokkal granulárisabb lesz.

Hát, ennyi. Kicsit fájt a szívem, miközben a részleteket töröltem a jegyzeteimből… de idővel mindent meg fogunk tudni. Meg, amennyire sejtem, a végső termékig ezercsillió dolog változhat.

Kliens trotyli, avagy hátrébb az agarakkal

Valljuk be, az embernek ritkán van lehetősége ipari környezetben pontos kisérleteket végezni. Meg lehet tervezni a kísérletet virtuális gépen… de köztudott, hogy a méretkülönbségek miatt nem számíthatunk arra, hogy az éles környezetben minden ugyanúgy fog menni, mint a laborban.
Amikor nemrég átállítottuk egyik ügyfelünk levelezési rendszerét Exchange2007-re, volt egy olyan időszak, amikor enyém volt a pálya. Rendes, ipari erősségű szerver dübörgött a gépteremben, 1 teszt user postafiókja volt csak rajta. Remek lehetőségem nyílt arra, hogy kimonitorozzam, 1 átlagos felhasználó mekkora terhelést okoz egy valós szervernek. Vannak rá ügyes perfmon counterek, ezek közül ez érdekelt engem konkrétan: ‘RPC operations per second per user’. (Természetesen nem a perfmon-ból vizsgálódtam, vannak az EMC-ben erre a célra felingerelt varázslók bőségesen a Tools menüpont alatt.) Nagyjából annyit illik erről az értékről tudni, hogy ha az értéke 0,25 fölé megy, az már gáz.
Ekkortájt hülyült meg a laptopom, időnként be-bevillantott egy-egy kékhalált. Mivel az Outlook-om cached módban ment, ilyenkor nyilván jönnie kellett egy ost adatbázis reparációnak is az újraindítás után. Nos, ezt is lemonitoroztam… és kikerekedett rendesen a szám: a mutató 0.41-re lendült ki.
Próbáljuk meg értelmezni:

  • Nyilván ahhoz, hogy a szerveren tárolt adatokat össze tudja vetni az ost-ben tárolt adatokkal, rengeteg információt kellett MAPI-n keresztül lerántania a szerverről. Márpedig a MAPI az RPC.
  • Valószínűleg az “extrém nagy” terhelés meg se kottyant a szervernek, hiszen egyedüli felhasználó voltam, azaz a “per second per user” érték lehetett nagy, de az abszolút terhelés bőven normálison belül maradt.

Ennek ellenére mégis érdemes elgondolkodni a számon. Sok felhasználó esetén nem tudhatjuk, ki milyen kérésekel bombázza a szervert: az ost reparálás mellett bejátszik a desktop search is, amennyiben beállítottuk, hogy az legyen a keresőnk az Outlook alatt, de ugyanígy bejátszik, ha alternatív keresőt – pl. lookout – használunk, bejátszhatnak archiváló szoftverek, bejátszhat egy CRM… bejátszhat minden, ami a postafiókot piszkálja. Ja, és bejátszhat a felhasználó is, pusztán azzal, hogy használja az Outlook-ját: levelez, megbeszélést szervez, kontaktok között keres.
A kérdés: mi történik, ha túlterheljük a szervert? Ha túl sok RPC kérést kap?

Alapvetően három viselkedési mód képzelhető el:

  • A szerver megpróbálja kiszolgálni az ígényeket, csak gyűjti, gyűjti… aztán halk sóhajtással összeszakad. A levelezés megáll.
  • A szerver, amikor észreveszi, hogy baj van, nem bír többet, nemes egyszerűséggel nem foglalkozik a bejövő kérésekkel, amíg nem lesz rájuk erőforrása. Ekkor néhány kliens fogja úgy érezni, hogy a szerver nem működik – dea többiek makacsul nyomulnak.
  • A szerver, amikor észreveszi, hogy baj van, akkor visszaszól. Egész pontosan azt fogja mondani a nagy terhelést okozó klienseknek, hogy lassítsatok be, nem bírom feldolgozni a kéréseiteket.

Nyilván az első mentalitás halálos. Nem szeretjük. A másodikat se túlzottan, de már megszoktuk: az Exchange szerver eddig ugyanis így működött. Eddig. Az Exchange 2007 SP1 viszont átváltott a harmadik módszerre. Ezt hívják úgy, hogy client throttling, azaz kliens fojtogatás.

Nézzük a részleteket. A szerver kezd lemerülni. Ekkor gyorsan beazonosítja, kik azok a kliensek, akik a legnagyobb terheléseket okozzák, majd küld nekik egy-egy pofabe üzenetet. Ezt úgy hívják, hogy back-off. Aztán mit mond erre a kliens? A nevelésétől függ.

  • Az Outlook 2007 kliensek úgynevezett ropBackoff üzenetet kapnak. Ebben benne van az az információ, hogy mennyi ideig ne próbálkozzanak új RPC kéréssel. De mi van, ha a kliens csak azért is próbálkozik? A szerver türelmesen küld neki egy újabb ropBackoff üzenetet, módosított időlimittel.
  • A korábbi kliensek nem értenék ezt az üzenetet, ezért nem is ezt kapják. Helyette a szerver a képükbe tol egy RPC_S_SERVER_TOO_BUSY üzenetet. Ilyenkor a kliens beállításától függ a várakozási idő. Alapban 1 másodperc. Aztán ha túl sűrűn kapja vissza ezt az üzenetet, akkor bontja a kapcsolatot és kiírja, hogy az RPC szerver nem elérhető.

Aki komolyabban is kíváncsi a jelenségre, perfmonból meg lehet tekinteni. A countert úgy hívják, hogy RPC Client Backoff/sec. Vigyázat, más nagyságrendeket fogunk látni, attól függően, hogy milyen klienseink vannak: ropBackoff üzenetek sokkal sűrűbben keletkeznek, pont a finomabb szabályozás érdekében. A normál értékek: Outlook 2007: 50/kliens, korábbi Outlook kliensek: 1/kliens. Azaz a korábbi kliensek csak 1 pofont kapnak, de az jó nagy.

Mi van még? Igen, lehet állítani azt a küszöbértéket, amikortól a szerver úgy érzi, hogy baj van. Természetesen registry varázslással. A magam részéről úgy vélem, átlagos környezetben erre nincs túl nagy szükség. Bízzunk a szerverben, csak tudja, mikor fárad el. Amennyiben valaki mégis állítgatni akarja, akkor ebben a cikkben megtalálja a szükséges matekozást.

Kilőttük

Nemrégiben végiggondoltam, merrefelé is vannak szakmai cikkeim, szerte az interneten. Gondoltad volna, hogy több, mint 300 van belőlük? Gondoltad volna, hogy egy érdeklődő olvasó milyen nehezen láthatja át ezt a kupacot? (Valószínűleg ezt már gondolhattad, ha itt vagy.)
Aztán öregnek öreg vagyok, de teljesen süket még nem. Időnként kapok azért olyan megjegyzéseket, hogy szedjem ki a magánéleti blogból a szakmai írásokat. Meg legyen egy hely, mely az Exchange-re koncentrál. És az se lenne baj, ha interaktív és jól kereshető lenne.

Nos, imhol.

Első körben kiválogattam durván 110 írást, melyeket jobbaknak tartok. Kapásból kiselejteztem például a saját otthoni hardvereim okozta kinlódásokat. Magánügy. Repültek az ún. forró hírek is, melyek valamikor felhívták valamire a figyelmet, de ma már annyira nem aktuálisak. (Ez nem jelenti azt, hogy itt sem lesznek ilyesmik. Miért ne lennének? Csak áthozni értelmetlen a régieket.)
Aztán továbbgondoltam az elképzelést. Az oké, hogy én grafomán vagyok, de be kell ismernem, van az Exchange-en belül olyan terület, ahol nem vagyok annyira otthon. Másfelől pedig, ha már azt mondom, Exchange blog, akkor legyen teljes, legyen tartalmas. Elvégre két Exchange MVP van az országban: felkértem Gömöri Zolit, szálljon be társszerzőnek. Ami Zolinak a szakterülete, az nekem a szürke zóna. És ha ketten írunk, akkor valószínűleg sokkal színesebb lesz a blog, mind stílusban, mind tartalomban. Színesebb, mintha csak én szórnám tele.

Végül egy megjegyzés. Az új skin elegáns, kellemes – de elsőre keveset mutat meg egy cikkből. Márpedig cím alapján nehéz belőni, miről is szól az írás – illetve ennyi alapján meglehetősen nehéz megtalálni azokat, melyekről rémlik ugyan valami, de nem tudjuk pontosan, mi is volt a címük.
Nos, több lehetőség is adott a navigációhoz:

  • A jobb oldali sávban a ‘Keresés’.
  • A jobb oldali sávban a ‘Kategóriák’.
  • A blog alján, a szürke zónában a címkefelhő.
  • A naptár alatt a havi adagok közötti gyors lépkedés.

Ha például valakit a ‘Félresiklott projekt’ néven elhíresült cikksorozat érdekelne, akkor a címkefelhőben ki tudja választani a félresiklott címkét – és már meg is kapta az írásokat. A kategóriák nagyobb krumplikat jelentenek, a címkék kisebbeket – és időnként át-átnyúlnak más kategóriákba.
A bloghoz két feed tartozik, az egyik az írásoké, a másik a kommenteké. Remélem, lesznek. Soha nem gondoltam tévedhetetlennek magam.

Nos, javaslom, gyakorolj, nézegesd végig a lehetőségeket – lehet, hogy még te is találsz számodra ismeretlen írást. 🙂 Most egy-két napig nem szándékozom új anyagot kirakni, nézegesd, ismerkedj – aztán aki bújt, bújt.

Legvégül külön köszönet Gabának, aki helyet biztosított a blog számára. Allah növessze hosszúra a szakállát.

Cikkek a Technet Magazinban

Ha már az a nagyívű célom, hogy lehetőleg minden értelmesebb írásom itt legyen, vagy elérhető legyen innen, akkor nem feledkezhetek meg a Technet Magazinban megjelent cikkekről sem.

Windows Server 2008 for Dummies

2007 végén, 2008 elején jelent meg a Technet blogon egy sorozat, melyben a Windows Server 2008 újdonságait igyekeztem bemutatni, kifejezetten egyszerű, szájbarágós módon. A megértést karikatúrák alkalmazásával próbáltam könnyebbé tenni.
Tisztára, mint a Dummies sorozat.

  1. Read-only Domain Controller
  2. A parancssor meglódul – server core
  3. A hálózat és annak védelme
  4. Látszólag
  5. A legegyszerűbb alkalmazásdisztribúció
  6. IIS7 – granulálok!
  7. Erőkagyló
  8. Aki nem lép egyszerre
  9. iSCSI
  10. Színház az egész világ
  11. Van másik!
  12. Címtár auditálás
  13. Kulcskérdés
  14. A klónok háborúja
  15. Szereti a tik a meggyet

Exchange 2007 SP1 Update Rollup 2

Megjelent az Exchange 2007 SP1 utáni második összefogott gyorsjavítás. Jujj, tudok fogalmazni. Lövésem sincs, hogy magyarul minek hívjam ezt a csomagot. Összesen arról van szó, hogy a Microsoft időnként összefogja egy csokorba a fontos hibajavításokat és kiadja. Ez nem olyan átfogó, mint egy szervizcsomag, ugyanakkor jóval sűrűbben jelenik meg. Az Exchange 2007 RTM és SP1 közötti alig több mint egy évben öt ilyet sikerült generálni. Ennyit a fogalmazásról.
A csomag letölthető innen, a benne lévő frissítések listája pedig itt található.