By SUF on 2009.04.16. 9:22

Több mint két évvel ezelőtt írtam egy Transport Agentet arra, hogy az Exchange disztribúciós listái levelezőlistaként üzemeltethetőek legyenek. Nem publikáltam.

Másfél éve Szalay Marci írt egy hasonlót. Akkor leveleztem is vele és írtam is róla itt.

Majd tavaly december elsején elindítottam ezt a weboldalt.

Ma azzal foglalatoskodtam, hogy a régi blogomból átpakoljam az anyagokat ide. Ennek kapcsán ellenőriztem a linkek jó részét, hogy élnek-e még. Rá is bukkantam újra Szalay Marci cikkére. Ekkor hasított belém a felismerés, hogy ő már írt egy ClamAV alapú vírusirtót.

Szóval tartozom egy bocsánatkéréssel, mert a ClamAgentről legalábbis szólnom kellett volna előre.

By SUF on 2009.03.14. 6:00

Na tehát, az első bejegyzésben nem sikerült elkezdenem mert mennem kellet.

A céges hálózatunkban a levelek előzetes szűrését hosszú évek óta egy Linuxon futó Postfix végzi, pontosabban a szűrés mamár csak a vírusirtásra korlátozódik, mert a SpamAssasint sosem tudtam rávenni valami kulturált működésre (ebben fix én vagyok a hülye, de az ismereteim inkább Windowsosak mint Linuxosak). A vírusírtást a ClamAV végzi, a spamszűrést pedig az Exchange 2007 Hub Transportra telepített edge agentek.

Ettől a konfigurációtól nem vagyok különösebben boldog, mert az Exchange spam szűrő infrastruktúrája így félkarú óriásként viselkedik. Egy jó ideje megszületett bennem a gondolat, hogy az egész Postfixes miskulanciát elfelejtem és beállítok egy Edge szervert.

Ez idáig magánügy. Ugyanakkor van nekem egy Exchange MVP címem (ha még megmarad április után is). Ez arra sarkal, hogy a tervezett bevezetési folyamatot dokumentáljam és screencastokat gyártsak róla. Ide tartozik, hogy nincs szándékomban semmilyen eszközt bevetni, ami nem része az Exchangenek, pontosabban semmi olyat ami pénzbe kerül. Tehát a feladat a személyem, az Exchange Edge, és a minimális programozói tudásom felhasználásával a lehető legjobb eredményt elérni a spam és vírusszűrés fronton.

Van egy rakás ötletem jópofa segédprogramok (alkalmasint Transport Agentek) elkövetésére, amiket most még nem akarok felfedni, majd csak, ha elkészültek. Ízelítőnek egyet azért leírok. A vírusirtó, amit használni fogok az a ClamAgent névre hallgat, ezt már én követtem el.

Az előkészületek:

Már hónapok óta tervezem, hogy nekiugrok ennek az egésznek. A legnagyobb bajom az vele, hogy a tervezett végleges infrastruktúrát semmiképp sem tudom egy lépésben megvalósítani. Kénytelen leszek az éles (nem csak az itt vázolt screencastokhoz szükséges teszt) Edge szervert először virtuális környezetben elkövetni, majd amikor kész van, újra megcsinálni immár fizikai vason.

A Hyper-V szerverünk, amire ezt az egészet meg kellene csinálni sajnos memóriailag nem áll a helyzet magaslatán. Két Edge szerver biztosan nem fér el rajta. Akkor hova kerüljön?

Itt teszek egy kis magánéleti kitérőt. Nagyjából egy éve csináltam egy szervert itthonra Hyper-V-vel játszani. Két hónapja eladtuk a lakásunkat, vettünk egy félkész házat. Ezeknek, továbbá egyéb eseményeknek köszönhetően jelenleg egy a korábbinál jóval kisebb lakást bérlünk. Ide nem jöhettek velem a szervereim. A cuccaink alapvetően elhaladtak egy raktárba, kivéve a szervereket. Azokat kimentettem és bevittem a munkahelyemre. Szóval az otthoni Hyper-V lesz a homokozó az Edge-hez.

2009.03.12 Délután:

Végre eljutottam odáig, hogy a szervert felhozzam a szerverszobából, az íróasztalom alá. Adtam neki tápot. Be akartam dugni a konzol switch csatlakozóit (VGA, PS/2 egér, PS/2 billentyűzet). Pofára estem. mindig elfelejtem, hogy ezen az alaplapon nincs PS/2-es csatlakozó.

Keresgélés az asztalomon - vannak még csodák - két perc alatt meglett az átalakító.  Bedugtam, bekapcsoltam, bejelentkeztem. A gép működik, a mai napba ennyi fért. - Hazamentem

2009.03.13 Reggel:

Csináltam a gépnek LAN-t,
átállítottam az IP címét,
felraktam a biztonsági frissítéseket,
elindítottam a saját gépemen azt a virtuális Vistát ahonnan managelni lehet a Hyper-V-t (Miután a szerver egy ingyenes Microsoft Hyper-V Server, és mint ilyen egy Windows Server 2008 Core-on fut saját magán nem managelhető, kell hozzá egy Vista megfejelve a Hyper-V managerrel),
aktiváltam a Vistát, mert már lejárt,
erre is felraktam a biztonsági frissítéseket,
elindítottam a Hyper-V managert (kapásból működött, ez egy kissebbfajta csoda, azok után, hogy mennyit szívtam vele első alkalommal ),
felmásoltam az OS image-eket,
összeraktam a három virtuális gépet (teszt Edge, teszt Exchange, éles Edge),
feltelepítettem az első gépet,
pofáraestem.
Közölte velem az Integration Services telepítője, hogy nem kompatibilis az operációs rendszerrel. Jájj. Ha jól tudom egy Windows Server 2003 x64 R2-vel kompatibilisnak kellene lennie. Mit csesztem el? Némi küzdés után (nincs egér, a windows gombra a vista reagál, stb.) kiderült, hogy mellényúltam. A Windows amit felraktam SP1-es, és az Integration Services csak az SP2-vel kompatibilis. Nem volt kedvem küzdeni az SP telepítéssel, inkább újrahúztam az egészet.

Ezzel el is ment a napom. A telepítés felénél hazamentem. (ja, na nem csak ennyit csináltam egész nap, ez a Hyper-V-s story csak background process volt )

By SUF on 2009.03.12. 16:22

Ezt a cikket elkezdtem volna írni, de hirtelen nem lett rá időm.

By SUF on 2009.02.18. 16:11

Van nekem egy DistList nevű fejlesztésem, amiről itt írtam. Ennek most elkészült a következő kiadása, amiben megoldottam, hogy a címsor tag-elése listánként kapcsolható legyen (Ezt azért itt írom most, mert valami gubanc miatt nem tudok oda belépni).

Letöltés itt:

DistList (Exchange 2003-as verzió)

DistList 2007 (Exchange 2007-es verzió)

Forráskód

Dokumentáció

By SUF on 2009.02.16. 12:18

Egy jó fél éve egy HTC Touch Diamond boldog(talan) tulajdonosa vagyok (sok bajom nincs vele, csak a részemről volt egy kis mellényúlás, hogy megvettem).

Az elmúlt egy évben több Windows Mobile-os készüléket próbáltam összelőni az Exchange 2007 szerverünkkel. Az ActiveSync mindig működött, az Exchange AutoDiscover soha. Hozzá kell tennem, hogy az Exchange konfigurációján nem változtattam.

Nemrégiben láttam, hogy kijött a Diamond-hoz a 2.03.401.2-as szoftver. Kb. két hete megpróbáltam volna letölteni. Megnéztem a készülék széria számát, beírtam, közölte, hogy ehhez nincs újabb szoftver. Hopp, néhány hónapja cserélték a készülék belét. Miután még a kezdet kezdetén regisztráltam magam a HTC web oldalán, előszedtem az eredeti szériaszámot. Azt megette, letöltöttem a frissítést.

Máig nem volt időm foglalkozni a dologgal. Ma elindítottam a frissítést. Elszállt. Jujj, lehet, hogy mégse jó a frissítés? Letöltöttem újra, ezt már megette.

Na, akkor konfiguráljuk fel. Tanúsítvány felugrik, Exchange autoconfig, és láss csodát, működik az autodiscover, mint a kisangyal.

Jöjjön az ellenpróba. Vagy az Exchange-en történt valami, vagy a telefon firmware oldotta meg a kérdést. Beletúrtam a fiókba és előszedtem a régi HP 514-esemet. Ezen sosem működött, tehát ellenpróbának jó lesz. Leveszem a hátát, hogy bele tudjam tenni a SIM kártyát. Szembe jön egy púpos akkumulátor.

Akkor ez csere lesz. Addig is az egyik kolléganőtől szereztem egy bele való aksit. Töltőre feldug: No or wrong battery.  Na még1x. Másodszorra elindul. Hard reset.

Amíg resetelget, aksit rendelek. Nettó 4eFt, ez nem is vészes. Meglátjuk, mikor jön meg.

Végzett. Exchange autoconfig indul, nem működik.

Ebből azt, a nem túl messzemenő következtetést vonom le, hogy a Diamond új szoftverében történt valami.

Ha nincs igazam, majd megcáfol valaki.

By SUF on 2008.12.20. 17:54

Már korábban írtam róla, hogy elkövettem egy ingyenes vírusirtót az Exchange 2007-hez. Most elkészült ennek az Exchange 2003-al vagy IIS SMTP szerverrel használható változata. Mind a kettő megtalálható a http://www.clamagent.org -on.

By SUF on 2007.10.18. 15:20

Valamikor tavaly december végén előjött egy nagyon kemény Exchange-es feladat. Meg kell oldani, hogy egy disztribúciós lista levelező listaként működjön. Ebben annyi a feladat, hogy minden levélbe amit a disztribúciós listára küldünk, bele kell rakni egy Reply-To  mezőt, hogy a válaszlevelek is a disztribúciós listára menjenek vissza. Meg is csináltam a dolgot, el is kezdtük használni, amikor kiderült, hogy az Exchange 2003-at 2007-re cseréljük és a 2003-hoz megírt sink nem jó a 2007-hez.

Nekiálltam és megcsináltam a 2007-es Transport Agentet. Ma mind a két verzió hibátlanul működik egy-egy szerveren.

Az elmúlt hónapokban valahogy sosem volt időm arra, hogy a fentiekhez kapcsolódó cikkeket megírjam és publikáljam az egészet. Ma vettem észre ezt:

http://www.microsoft.com/hun/technet/default.aspx?article=266802d4-92c0-42ad-836b-91bff94e8711

Lelőtték a poénomat. Így jártam.

Így utólag azt hiszem, hogy most rá fogom szánni az időt, kicsit gatyába rázom a cuccot és publikálom.

By SUF on 2005.07.25. 7:48

Csütörtökön Bende Imre kolléga feldobott egy magas labdát. Volt egy telefonbeszélgetésünk is ezügyben. A feladat a következő:
Van egy Exchange 2000 szerver ahol tömegesen kellene felvenni domaineket a tiltott domainek listájára.
Csak, hogy pontosan jelezzem miről is van szó, ide:
Exchange System Manager/Administrative Groups/First Administrative Group/Servers//Protocols/SMTP/Default Virtual Server, Properties, Access fül, Connection..., Add..., Domain
Ezt már megkeresni se egyszerű, hátmég tömegben felvenni ide valamit. Elkezdtem keresgélni, hogy honnan veszi a beállításokat. Végigtúrtam a metabase-t (adsutil.vbs-el), a registry-t, az AD-t és nem találtam semmit.  Azután hosszas keresgélés után rájöttem, hogy csak a metabase-ben tárolja a dolgokat, bináris formában egy IPSec tipusú (semmi köze az IPSEC protokolhoz) propertyben. Ezt a tipust a fent említett adsutil.vbs nem kezeli és miután az IPSec tipusnév nem kicsit félreérthető, elsiklottam felette. Végül némi küzdés árán megszültem a dolgot. VBScript (broáf) azért lett belőle mert a JScript a VBScript tipusú tömböt (azt hiszem SafeArray-nak hívják hivatalból) csak olvasni hajlandó és írni nem. Miután az adsutilban ignorálták az IPSec típus kezelését, ezért azt vettem a fejembe, hogy írok egy olyan scriptet ami teljeskörüen kezeli. A legszebb az lenne, ha beleraknám az adsutilba, de nem tudom, hogy ezzel milyen jogi macerákat vennék magamra, amihez semmi kedvem.
Az elkészült kód innen tölthető le.

By SUF on 2005.07.07. 10:40

Valamikor május tájékán feldobtam egy labdát a különböző levelező rendszereink levél routolásával kapcsolatban. Akkor még nem okozott nagy gondot csak piszokul zavart. Megoldani nem tudta senki, kaptam ötleteket de egyik sem volt jó.
Néhány héttel később a dolog teljesen bedőlt. Egy nap kemény szenvedés és egy rossz éjszakai alvás árán sikerült megoldani a dolgot. A tettes elsősorban én voltam. Egy helyen A osztályu IP maszk helyett C osztályut írtam be a 10.0.0.0-ás hálóhoz a mail relay kivételei közé. Ez azért okozta a korábbiakban jelzett problémát mert azoknál a domaineknél ahol kivesszük a recipient policyban a "This Exchange Organization is responsible for..." című checkboxot a befelé jövő levél is relaynek fog számítani, mert az SMTP transport csak a domaint ellenőrzi az egyedi címet nem!!!
Ez utóbbit jó tudni. Végeredményben a sör/bor osztogatás elmarad (saját magamnak is mert alapban a saját hülyeségem)

By SUF on 2005.05.24. 9:40

Tegnap írtam, hogy elkezdtem csinálni egy kis scriptet ami képes kilistázni egy Outlook elem összes tulajdonságát. Na ez nem fog elkészülni mert újra ráakadtam erre:

http://www.outlookspy.com

Egyszer már láttam, de akkor nem érdekelt különösebben mert mással foglalkoztam. A mostani feladataimhoz pontosan jó.

By SUF on 2005.05.21. 22:05

A napokban elkezdett rendetlenkedni az egyik régi, nem Exchange mail szerver az egyik cégünknél. Pontosabban nem elkezdett, hanem láthatóan már régen ilyen volt, csak egy hibás konfiguráció rendberakására volt szükség arra, hogy ez kiderüljön. Pontosan az történik, hogy az illető szerver néha nem veszi át a leveleket egy-két órán keresztül, utána pedig minden ok nélkül megjavul. Az adott termék nem épp egy mai gyerek, eredetileg NT4-en futott, úgy tették át a kollégák w2k3-ra, és ezen a platformon nem támogatott, akár ez is okozhatja a gondot. Arra a döntésre jutottunk, hogy nem kezdjük nyomozni az okokat, hanem megy a dolog a kukába és helyette a w2k3 beépített POP3/SMTP párosa lesz (Exchange sajnos nem lehet pénzügyi okokból). Ez már a platformváltáskor is felmerült, de akkor nem lépték meg, mert hiányoltak két funkciót, az alias-okat és az átirányítást. Én még nem néztem utána, hogy valójában tudja-e ezeket a POP3/SMTP. Most elkezdem olvasni a doksit, és gyártok némi teszt konfigurációt.

Ha nem tudom vele megoldani az említett funkciókat, akkor jön a kódgyártás, mert a fejemben már megvan, hogy az említett funkciókat hogyan lehet SMTP Sink-ben megoldani. Szóval, ha szükség lesz rájuk akkor megcsinálom és publikálom a kódot.

By SUF on 2005.05.21. 7:46

Épp egy Outlook Formot próbálok irogatni. Eközben belefutottam egy érdekes üzenetbe. Az ember megtervezi a formot, tesz mögé valami kódot, minden szépen ketyeg, elmennek az üzenetek, ráadásul úgy ahogy szeretném, jó is lenne, de....

Amikor megérkezik az üzenet, a másik oldalon az olvasó ablakban az üzenet szövege helyett ezt találom:

"This item contains active content that cannot be displayed in the Reading Pane. Open the item to read its contents."

Na jó, ha megnyitom a levelet akkor szépen tudom olvasni, de se én, se a felhsználók nem akarják megnyitni, úgy látszik, hogy az emberek legnagyobb százaléka az olvasó ablakban szeret levelet olvasni. Akkor keressük meg, mit követtem el, hogy ez történik. Megtaláltam:

http://support.microsoft.com/?id=241205

A cikk szerint, ha egy üzenet életrajzának bármely időpillanatában a form mögött volt VBScript kód akkor a fenti kedves üzenetet kapom. Beállít valami flag-et és ez már örökre így is marad. Hurrá!

Kipróbáltam, hogy fogtam egy egyszerű eredeti Message formot, beleraktam a kód részébe egyetlen megjegyzést, és elküldtem a levelet rögtön látszik a fenti üzenet, tehát valóban így van és nem én vagyok a hunyó.

Csináltam két referencialevelet egy jót és egy rosszat és megvizsgáltam őket ezzel az eszközzel:

http://www.microsoft.com/downloads/details.aspx?familyid=3d1c7482-4c6e-4ec5-983e-127100d71376&displaylang=en

Azt tapasztaltam, hogy egy rakás mapi property különbözik a leveleim között, ráadásul a rossz levélben RTF!!! body van, csak tudnám minek. Gyanítom, hogy ha elkezdenék bogarászni és c/c++-ban elkövetnék valami com objektumot, akkor át tudnám állítani a dolgot. Ezzel csak két bajom van:

- Az ilyen irányú programozó ismereteim elég korlátosak, tehát nagy biztonsággal hónapjaim mennének rá, ennyit meg az egész nem ér

- Amikor publikálom a saját dolgaimat, ma még nem szívesen adok ki a kezemből se bináris kódot, se olyan forrást amihez azoknak akik olvassák az oldalamat még fordítgatnijuk kell, elvégre a dolog rendszergazdáknak és nem fejlesztőknek szól

A dolognak az lett a vége, hogy készül egy VBA makró az Outlookhoz ami megoldja azt, ami a Microsoft cikk szerint lehetetlen.

A történet a háttérben fog generálni egy az eredetivel megegyező üzenetet, és el fogja dobni az eredetit (még nincs kész, de már működget ).

Utolsó megjegyzésként azért hozzátenném a történethez, hogy láthatóan ez a működés már az Outlook 98-ban is fennált (találtam egy 1999-es OL98-as verziót is a fenti cikkből). Drága Microsoft! Miért nem lehetett ezt röpke 6 év alatt megoldani?

By SUF on 2005.05.11. 12:12

Elég régóta adminisztrálok Exchange szervereket. Sok-sok bajom volt már a levelek routolásával. Most épp egy olyan környezetünk van ahol több domainben több Exchange szerver található ráadásul nem is meinden levelező rendszer Exchange (valami régi SMTP/POP3 cucc, na meg egy Notes). Ezt megfejelve a szokásos kis Exchange Event Sinkjeimmel egy elég nagy routing gubanc jön ki.

Ma reggel a fent említett Notes-től (róla migrálunk és nem lesz már sokáig, hála istennek) át akartam tenni a levelek beérkeztetéssét arra az Exchange szerverre amire a régi Notes felhasználók levelei kerültek.

Szépen átírom a DNS-t, erre a tűzfalon csücsülő sendmail elkezd balhézni, hogy Relaying denied. Megnézem telnetből és tényleg. Eldobja az INBOUND !!! leveleket RELAYING !!! denied-al.

Na én ilyet még nem láttam.

Hogy tiszta legyen, egyszerüsítve a környezet a következő. Vegyünk két Exchange szervert, legyenek EX1 és EX2. Mind a két szerveren van két-két SMTP Virtual Server legyenek EX1_def, EX1_ext, EX2_def és EX2_ext. Legyen két domainünk local.ex és corp.local.ex. Legyen egy felhasználónk akinek mind a két domainben van címe user@local.ex és user@corp.local.ex. Van még egy Notes szerver ami eredetileg a local.ex domain leveleit kezelte. Az EX1_def és az EX2_def a 25-ös porton hallgat és a 9025-ös porton csatlakozik kifelé. Az EX1_ext és az EX2_ext a 9025-ös porton hallgat és a 25-ös porton csatlakozik kifelé. Az EX1_def-nek az EX1 a smarthostja az EX2_defnek az EX2, az EX1_ext-nek és az EX2_ext-nek a tűzfal. Na ez idáig működik is mint a kisangyal.

Most jön a gáz. Ugye a recipient policy-ban a corp.local.ex domainre be van kapcsolva az, hogy "This Exchange Organization is responsible for all mail delivery to this address" a local.ex -re pedig ki van kapcsolva. Van továbbá egy olyan SMTP Connector ami átirányítja a local.ex-es leveleket a Notes szerverre és az EX1_ext virtual serveren csücsül.

Ezek után ha az EX2-re küldök levelet akár user@loacal.ex -nek akár a user@crop.local.ex -nek akkor azt átveszi a szerver, ha az EX1-re küldök levelet a user@corp.local.ex -nek akkor azt átveszi, viszont ha az EX1-re küldök levelet a user@local.ex -nek akkor azt relaying denied-al eldobja.

Na most az a kérdés, hogy valamit rosszul konfiguráltam, vagy ez egy icipici bug az Exchange-ben?

Ez az egyész egy olyan probléma amit nem tudok megoldani. A környezet E2K3SP1.

A megfejtőnek söröket/borokat osztok...

By SUF on 2005.05.09. 16:04

Gondolom már mindenki unja a témát aki véletlenül olvassa ezt (csak reménykedem benne, hogy van ilyen), én legalábbis nagyon unom.

Összearktam kipróbáltam, oda akartuk adni a kedves felhasználónak aki miatt újra elővettem a témát (eredetileg egy bő éve írtam meg a kódot, de eddig a saját rendszerünkben nem kellett). Természetesen nem volt jó. Írtam a cikkben pár korlátozásról, mint például, hogy a display name nem cserélhető le vele (elvégre az adatok az AD-ból jönnek és ott nincs lehetőség arra, hogy valahol értelmesen el tudjam tárolni ezeket, schemá-t pedig majd hülye leszek bővíteni e miatt).

Na ez persze nem volt így jó.  Végül is kitaláltam a megoldást. A kód nagyrészét már át is írtam ennek megfelelően, tehát lassan jön az egész megoldás következő kiadása ami már ezt is tudni fogja (talán még ezen a héten).

By SUF on 2005.05.09. 15:56

Na ma végre hosszas küszködés után (főleg az idővel és a lustasággal) befejeztem ezt a Sent Items szétválogató szerkezetet.

Elkészült, működik, de nem vagyok vele elégedett. Ennyit sikerült megoldanom. Ha valakinek van rá ötlete, hogyan lehetne rajta javítani (ne kelljen időzíteni és ne generáljon "Sent behalf of" tipusú leveleket), azt szívesen veszem.

Használja mindenki egészséggel akinek szüksége van rá!

By SUF on 2005.05.04. 6:14

Azt vettem a fejembe, hogy belenyúlok a Microsoft Exchange 2003 OWA kódjába. Ezt ugye alapvetően meg tudom tenni, hiszen az egész OWA láthatóan DHTML (HTC objektumok) alkalmazás. Azért akarom ezt megtenni, hogy ugyanúgy ahogy az Outlook-hoz az OWA-hoz is tudjak saját formokat elkövetni. Dokumenttációt nem találtam a dologhoz (ha valaki tud ilyet azt megköszönöm), összesen ennyit találtam:

"OWA customization and component reuse is not supported by Microsoft"

Tehát saját magamnak kell kibogarásznom a dolgokat. Belenéztem a kódba, hogy

Próbálok finoman fogalmazni. Nem vagyok róla meggyőződve, hogy az OWA-ban használt programozási stílus (a forráskód kinézete, dokumentáltsága) megfelel a Microsoft belső szabályainak. Ráadásul ez olyan kód ami ki is kerül, nemcsak bináris állományként. Nem akarok ítélkezni, miután nem vagyok programozó. Mindenki győződjön meg róla saját maga! Egy telepített Exchange 2003 SP1-esen érdemes megnézni ezt:

C:\Program Files\Exchsrvr\exchweb\6.5.7226.0\controls\ctrl_Message.js

Nem tudom mi lesz belőle, de megpróbálok valamit összehozni. Majd beszámolok, hogy mire jutottam.

By SUF on 2005.04.29. 7:56

Ma reggel leültem a gép elé, hogy megírjam a dokumentációt az elmúlt napokban reszelgetett scriptemhez, valamint belekzdtem néhány új dologba - pontosabban - csak belekezdtem volna, de ennek kapcsán észrevettem egy hibát a már publikált dolgokban amit ráadásul elég sok helyre beraktam, így most javítgatok.

Az történt, hogy a "Levelesláda méretértesítő"-höz tartozó doksi megírásakor a HTML template-jeimben használt megjegyzés tag-ekben amiket a behelyettesitendő pontokra raktam lemaradtak a felkiáltójelek így helyett <--TAG--> került oda.

A script doksi írása félrerakva, most a hibákat javítgatom.

A "Levelesláda méretértesítő", és a "Jelszó lejárat értesítő", az "Exchange Store méret" dokumentációját javítottam, valamint ez utóbbinál a scriptet és a minta htm fájlt is mert ezekbe is belekerült az idióciám.

Ez rögtön arra is lehetőséget ad, hogy az "Exchange Store méret" scriptben még a múlt héten elkövetett kis plusz funkcionalitás is kikerüljön, nevezetesen az, hogy már a levél címében is lehet használni a template tag-eket.

By SUF on 2005.04.28. 7:05

Mint már kedden is írtam, belekezdtem az alternatív feladó játékomhoz tartozó, az elküldött elemeket szétválogató script gyártásába. Második nekifutásra sikerült is megcsinálni a dolgot (szépséghibája az lesz, hogy időzítve kell futtatni, mert ugye Store Sink-ként nem lehet). Már össze is raktam, amikor jött az ötlet, hogy nem elég szétválogatni a leveleket és kiírtani belőlük a speciális csatolmányt (ami a valós e-mail címet tartalmazza), hanem át is kellene írni az e-mail feladóját.

Ez ugye nem jelenthet gondot, hiszen alig kell nyúlni valamihez. A CDO.Message objektumon át kell írni a From property-t és már kész is vagyunk.

Átírtam, megnéztem az eredményt és meglepetten tapasztaltam, hogy az Outlookban nem látok változást. Elkezdtem kisérletezni. Állítgattam az ide vonatkozó propertyket (From, Sender) - Semmi. Állítgattam a lehetséges httpmail és mailheader mezőket:

"urn:schemas:mailheader:from"
"urn:schemas:mailheader:sender"
"urn:schemas:httpmail:from"
"urn:schemas:httpmail:fromemail"
"urn:schemas:httpmail:fromname"
"urn:schemas:httpmail:sender"
"urn:schemas:httpmail:senderemail"
"urn:schemas:httpmail:sendername"

(Már ami ebből állítható és nem Read-Only)

Eredmény semmi.

Arra gondoltam, hogy én berakom a levelet úgy ahogy kell, ő pedig az AD alapján visszakeresi az e-mail-t és változatlanul a számomra épp nem jó AD objektumot rakja be a levélbe. Emlékeztem az Exchange ResolveP2 funkcionalitására, ami kísértetiesen ilyen. Megnéztem a KB-t. Meg is találtam az Exchange 2000-es cikket:

http://support.microsoft.com/kb/288635

Majd miután sejtettem, hogy ez nem jó a 2003-ra tovább keresve azt is megtaláltam:

http://support.microsoft.com/kb/828770

Ez utóbbiból kiderült, hogy amire gondoltam az

1. A 2003-ban már ki van kapcsolva tehát nem lehet a tettes

2. Csak a transporton beérkező levelekre vonatkozik, így az adott esetre nem.

Továbbmenve végül találtam egy ilyen névteret:

"http://schemas.microsoft.com/mapi"

Ugye ehhez a névtérhez tartoznak azok a paraméterek amik az Outlook kiegészítő információit tartalmazzák. Az Exchange ugye MIME formátumú levelekkel beszélget a nagyvilágban, az Outlook meg MAPI leveleket használ (ez utóbbi többet tud, de nem szabványos). Az az információ, hogy egy e-mail cím nem SMTP formátumú ezek között a paraméterek között keresendő. Olvasgattam az MSDN-t (CDO, Exchange schema, MAPI doksi) turkáltam a Platform SDK-ban (Mapitags.h) és meg is találtam amit kerestem. Az eredeti Exchange-es (Active Directory-ból származó) e-mail cím (pontosabban AD user object) ebben a három paraméterben található:

PR_SENDER_NAME
PR_SENDER_ADDRTYPE
PR_SENDER_EMAIL_ADDRESS

Át is írtam az értékeket megfelelően, és láss csodát működik. Legalábbis félig. Mostmár megjelenik a várt feladó, csak éppen a meghatalmazott (on behalf of) státuszban. Túrtam tovább, de nem találtam megoldást (az ide vonatkozó mezőket átírva nem történik semmi).

Ez volt az a pont ahol úgy gondolom, hogy a dolog már használható, így amint dokumentálva össze lesz rakva (remélhetőleg legkésőbb holnap reggelre) megy ki a web-re.

By SUF on 2005.04.26. 5:34

A múlt pénteken publikáltam az Exchange Alternatív Feladó nevű kis szösszenetemet (http://www.gomori.hu/as_hu.htm). Valahogy nagy közlési kényszerem volt így kihagytam belőle egy még el nem készült kiegészítést. Bele is írtam a szövegbe:

"A megoldáshoz tartozik még egy opcionális elem, ami megoldja, hogy a felhasználó Elküldött üzenetek (Sent Items) mappája alatt különböző mappákba szortírozza feladó szerint a leveleket. Ez a kiegészítő elem Exchange Store Sink formájában lesz elérhető, amint elkészült."

Na most gratulálhatok magamnak.  Nem készült el. Ebben a formájában nem is fog.

Péntek óta írtam az igért Store Sinket folyamatosan. Tegnap reggelre már majdnem elkészült amikor rájöttem, hogy kiszúrtam magammal.

Regisztáltam a Store Sinket a teszt felhasználóm Sent Items mappájára és azzal tesztelgettem, hogy megfelelő leveleket dobáltam bele kézzel. Amikor már majdnem kész volt az egész, akkor egyszer kipróbáltam úgy is, hogy küldtem egy levelet a teszt felhasználó nevében (ami ugye bedobja a Sent Items-be a levelet) és csodáloztam rajta, hogy nem lövi el a Sinket. Több órát bohóckodtam vele, hogy mit rontottam el. Nem találtam. Feldobtam mint kérdést a levlistára is. Még mielőtt választ kaptam volna rá, ezt találtam:

http://support.microsoft.com/?id=297274

Hurrá, kiszúrtam magammal (mellesleg nem értem, hogy mi a halálért nem volt képes az MS megoldani, hogy a Sent Items-en is működjön a Store Sink, vagy inkább mondjam azt, hogy nem ártana végre ezt az RPC-s, MAPI-s bohóckodást bevágni a kukába), amit kitaláltam soha a büdös életben nem fog működni.

Ahogy egy kedves kollégám szokta mondani:

"Akkor most középkezdést hirdetünk"

Miután az, hogy a Sent Items legyen szétválogatva feladónként nem az én saját agyszüleményem volt, hanem az egyik kedves felhasználó találta ki, így nem mondhatom azt, hogy "ok, ezt felejtsük el", hanem valahogy meg kell oldanom. Nekiugrottam mégegyszer, most 80%-os állapotában van az a script ami mondjuk óránként időzítetten futtatva végigmegy a Sent Items-en és leválogatja az elemeket.

Ennyi, majd ha kész lesz kirakom.

By SUF on 2005.02.02. 0:00

Ez a kis script az egyik legegyszerűbb SMTP EventSink. Semmi mást nem csinál, csak a megadott könyvtárba lementi a beérkező leveleket. A levelek formátuma olyan, hogy az Outlook Express tudja olvasni. A script archiválásra, vagy levelezéssel kapcsolatos hibakeresésre használható jól. Ezt a verziót még jó néhány dologgal ki akarom egészíteni a közeljövőben.

[2009.04.10] Már nem fogom kiegészíteni. A kód innen tölthető le.

By SUF on 2005.01.27. 0:00

Azt hiszem a fenti feladat nagyjából mindenki előtt ismert aki vállalati környezetben Exchange Server-t használ. Bárki aki SMTP Sink-ekkel kezd foglalkozni általában ezzel a feladattal és a megoldásával találja szembe magát. Erre a Microsoft saját maga írt egy VBScript Sink-et ami a KB 317680-as cikkben található. Amikor hosszú évek után újra programozgatásra adtam a fejem nekem is ez volt az első feladatom, kicsit átírva sokáig használtam is az említett Microsoft megoldást.

Az évek során kiderültek e script hibái:
- A jogi nyilatkozat szövege nem módosítható a forrás megváltoztatása nélkül
- A script belepiszkál az elektronikusan aláírt levelekbe, ezzel tönkreteszi a biztonsági borítékot
- Ha az Exchange Server több domaint (céget) kezel, akkor nehézkes megoldani, hogy különböző jogi nyilatkozat legyen a különböző domainekre

Az itt közzétett script a fenti kérdésekre ad megoldást. Használatához mindössze:
1. El kell készíteni hozzá domainenként két fájlt ami a jogi nyilatkozat szövegét tartalmazza text és html (a html formátum csak a szöveget esetleg a formázásokat tartalmazza, se a html fejléc, se a tag-ek ne legyenek benne!) formátumban valahogy így:
.txt
.htm
Ezekből természetesen annyi kell ahány domain-hez akarunk jogi nyilatkozatot rendelni.
2. A 1. pontban létrehozott fájlok elérési útvonalát be kell írni a script-be a DisclaimerFiles változóba.
3. A levéltovábbítás eseményeinek kezelése című cikkemben vázolt módon regisztrálni kell a scriptet.
[2009.04.11] Ez a Sink az Exchange 2003-hoz használható. Az Exchange 2007-hez nem szükséges, mert ott beépített megoldás van a feladat megoldására. A Sink forrása innen tölthető le.