MonthFebruary 2009

Némi Import-Export

Nemrégiben két esetben is szükségem volt arra, hogy két Exchange között vigyek át AD adatokat. Ezekhez írtam néhány pici scriptet. Ezek nem általánosan használhatóak, szóval, akinek kell, az mindenképp ésszel kezelje őket. Mindkét esetben szeparált tartományokról volt szó, tehát még trust sincs köztük.

Az első páros Exchange 2003-ból visz át felhasználókat Exchange 2007-be:

Export (ezt csak úgy parancssorból):

csvde -u -r “(objectCategory=user)” -l “cn,sAMAccountName,sn,givenName,displayName,mail,proxyAddresses,company,department” -f c:\work\users.csv

Import (PowerShell, vagyhívjam EMS-nek?):

Import-Csv c:\work\users.csv | foreach -process
 {
  New-Mailbox -Name ($_.cn) -OrganizationalUnit $_.ou -UserPrincipalName ($_.cn + ‘@domain.local’) -Alias $_.cn -SamAccountName $_.samAccountName -FirstName $_.givenName -LastName $_.sn -Password (ConvertTo-SecureString -string $_.Password -asPlainText -force) -ResetPasswordOnNextLogon $false  -Database ‘Server\Mailbox Database’
  Set-User -Identity $_.cn -Company $_.Company -Department $_.Department -DisplayName $_.displayName
  Set-CASMailbox -Identity $_.cn -EmailAddresses $_.proxyAddresses
 }

A második csomag jóval egyszerűbb. Kontaktokat visz át két Exchange 2007 között:

Export (EMS):

Get-MailContact | Export-Csv c:\work\contacts.csv –NoTypeInformation –encoding UTF8

Imprt (EMS):

Import-Csv c:\work\contacts.csv | foreach -process { New-MailContact -Name ($_.Name) -ExternalEMailAddress ($_.ExternalEMailAddress) }

Formás levél

Érdekes jelenségre hívta fel a figyelmemet az ügyfél egyik fejlesztője. Ha az Exchange 2007 OWÁ-ból küld html levelet, akkor a túloldalon már csak plain text-ként látszik. Miközben ha megnézzük a Sent Items folderben, ott bizony html.
Ez vajon mi lehet?

Ellenteszt. Mi van, ha Outlookból küldök html levelet? Úgy is érkezik meg.

Gyors teszt más cégek OWA rendszereiben – mindenhol ugyanez a jelenség.

Ez érdekes. Hiszen elméletileg nem szabadna, hogy különbség legyen a levélben, függetlenül attól, hogy OWÁ-ban vagy Outlookban állították elő. A formátumot saccra a Remote Domain objektumon lehet még utánállítani – és az egyformán kell vonatkozzon minden abba az irányba küldött levélre. De van egyáltalán ilyen állítási lehetőség a Remote Domain objektumokon? Bizony nincs. Legalábbis konzolból nincs.
Persze shellből van. Nézzük csak meg a get-remotedomain | fl parancs kimenetlét. Ott van, elbújva a többi tulajdonság közé a ContentType tulajdonság. Melynek értékei a következők lehetnek:

  • MimeHtmlText: Ha az eredeti levél text volt, akkor text MIME formátumba konvertál. Minden egyéb esetben html MIME formátumba.
  • MimeText: Text MIME formátumba konvertál.
  • MimeHtml: Html MIME formátumba konvertál.

Az alapértelmezés – a set-remotedomain parancs szerint – a MimeHtmlText beállítás. Ez jól is hangzik.

Csakhogy. Az én konkrét esetemben az volt, hogy MimeText.

Rögtön kérdések merültek fel:

  • Ha alapértelmezésben telepítettem, akkor miért nem az alapérték van beállítva?
  • Ha csak text MIME formátumban megy ki a levél, akkor hogyan mehetett ki Outlookból mégis html formátumban?

Jó magyar infomunkásként először azért beállítottam a MimeHtmlText értékét, leteszteltem – és tényleg ez volt a megoldás. Ment OWA alól a html levelezés.

Most már lehetett tipródni, mit is csináltunk. Mitől javult meg a rendszer?

Az első kérdésre viszonylag hamar meglett a válasz. Szűz rendszernél tényleg a MimeHtmlText az alapértelmezés. De ha 2003-ból migrálunk, akkor attól függően, hogy mi volt beállítva a kimenő levelek (Internet Message Formats) MIME kódolására, attól függően már más. Ha ott az volt, hogy ‘Provide message body as plain text’, akkor a migráció során a MimeText jön át. Azaz valószínűleg az összes helyen, ahol teszteltem, ez volt a beállítás a migráció előtt.

A második kérdésre a válasz már fogósabb egy kicsit. Logikusan gondolkodva, ha van egy organizáció szintű beállítás, de bizonyos levelekre vonatkozik, bizonyos levelekre meg nem, akkor léteznie kell legalább egy magasabb prioritású beállításnak, mely felülbírálja azt. Ezzel a témával kapcsolatban ezt a cikket találtam. Olvasgattam, olvasgattam… de nem akart összeállni a kép.

Mit is írnak a cikk vége felé?

Order of Precedence for Message Encoding Options
Exchange 2007 uses the order of precedence as described in the following list to determine the message encoding options for outgoing messages that are sent to recipients outside the Exchange organization:

  • Remote domain settings
  • Outlook settings
  • Mail user or mail contact settings

The list specifies the order of precedence from lowest to highest. A setting made at a higher level may override a setting made at a lower level.

Az utolsó pont szorulhat némi magyarázatra: az Outlook 2007-ben lehetőségünk van nekünk, személy szerint is bejelölgetni a kontaktokat (akár a sajátjainkat, akár a közöseket), hogy milyen formátumban szeretnénk nekik levelet küldeni.
Mondanom sem kell, ritka hülyén van megfogalmazva a szöveg. Hogyan értelmezzük a sorrendet? A higher level azt jelenti, hogy a legalsó a leggyengébb, a legfelső meg a legerősebb? De hát nem ez történt. Amikor beállítottam Outlook szinten, hogy html-ben akarok levelezni, akkor az úgy is ment ki, függetlenül attól, hogy remote domain szinten MimeText volt beállítva.
Megint a logikára kell hagyatkoznom. Ha ugyanis a felsorolás sorrendjét tekintem prioritási sorrendnek is, azaz fentről haladnék lefelé, akkor az a következőket jelentené:

  • Akárhogy is jelölném be a konkrét levél tipusát, ha a címzettre más típus van beállítva, akkor az utóbbi felülírja az elsőt.
  • Hiába van beállítva organizáció szinten a tartalomtípus, ha én a konkrét levelemben más adtam meg, akkor az lesz az erősebb. A levél úgy megy ki.

Ez már annyiból tetszetősebb, hogy ez lehetőséget ad megmagyarázni a jelenséget. Valamiért ha OWÁ-ból küldök html levelet, azt a remote domain nem úgy érzékeli, mintha Outlook-ból állítottam volna be, magasabb precedenciával. Tehát sima szövegként csomagolja MIMÉ-be. Ellenben amikor a remote domain objektumon azt állítom be, hogy vizsgálja meg a levelet, majd aszerint döntsön, akkor már felismeri, hogy ez eredetileg html levél volt – és így csomagolja MIMÉ-be.

Nagyon fontos. Amit a második kérdéssel kapcsolatban írtam, színtiszta spekuláció. Számomra így tűnik logikusnak. Ettől függetlenül abszolút máshogy is lehet.
Az életedet ne tedd fel rá.

DotNet

Egész biztosan vannak kellemetlenebbül hangzó szavak. De nem sokan.

Mit tudunk róla? Keretrendszer. Valami olyasmi, mint a Java. Megírnak egy programot valamilyen nyelven, a keretrendszer pedig képes értelmezni és az adott operációs rendszer keretein belül futtatni is azt. Mi itt a baj?
A fejlődés, barátom, a fejlövés fejlődés. Az első dotnet az 1.1 volt, aztán jött az sp1, majd jött a 2.0, persze az is kapott sp1-et, feltartóztathatatlanul jött a 3.0 az adekvát sp1-gyel, végül előmászott a 3.5, persze neki is van sp1 csomagja. Szerinted mire számíthat egy akármilyen program? Ezek közül vajh melyik lesz fent az operációs rendszeren? Ha azt mondod, mindegy, akkor látszik, nemrégóta vagy a szakmában. Ez az egész kóceráj visszafelé nem kompatibilis. Azt hiszed, ha van 2.0 verziód, akkor futni fognak az 1.1-hez írt programok? Erre csak annyit tudok mondani, hogy probatbicol pfdavadmin. Akkor esetleg elférnek egymás mellett ezek a keretrendszerek? Talán. De ha például az Exchange 2007 mellé (.Net 2.0) fel akarnád tenni a pfdavadmint és emiatt utólag a .Net 1.1-et… nem csak én nem tanácsolnám. (Mindemellett, ha a az 1.1 után teszed fel a 2.0-át, akkor simán elketyegnek egymás mellett.)

A röpke bemelegítés után térjünk a tárgyra. Hiszen projekt van.

Eddig nem beszéltem róla, de az ügyfél nem csak Exchange 2007 clustert akart, hanem profi levélarchiválási rendszert is. A választásuk a Symantec Enterprise Vault (a továbbiakban SEV) rendszerre esett. Az ajánlatot tevő cég a projekt során az alvállakozónk lett. Némi vérgőzös ütésváltás szakmai egyeztetés után abban maradtunk, hogy a SEV egy Windows 2003 clusterre kerül, ahol az ún. Storage Foundation (SF) lövi ki a klasszikus failover cluster spof-ját. (Nem baj, ha nem érted elsőre, annyira nem lényeges.)
Bele is vágtunk. Feltelepítettük az operációs rendszereket. A kolléga kérdezte, hogy tegyen-e rá valamilyen dotnet-et. Elgondolkodtam. Ha már fent lesz a cluster meg az SF, utólag sokkal bonyolultabb lesz biztosítani a megfelelő dotnet keretrendszert. Végül azt mondtam, tegye fel a .Net 3.5-öt, az olyan ultimate dolog, az felrakja az összes olyan keretrendszert, mely még nem volt fent. Aztán ha minden fent van, akkor a SEV is ki fogja majd tudni választani, melyik kell neki.
Utána jött a cluster, jött az SF, szépen haladtunk. Jött a SEV telepítő ember is. Elkezdtük silabizálni a prerekviziteket. És amikor odaértünk, hogy a számíítógépen _nem lehet_ dotnet kettőnél _magasabb_ verziójú keretrendszer, akkor azért kezdtem hülyén érezni magam. Miért? Erre nem tért ki a doksi. De tudjuk, milyen ravasz dolog a felelősség – ha telepítési előírás, akkor be kell tartani, még akkor is, ha azt írja, hogy a telepítő mérnöknek aranyszínű tangabugyiban kell felszaladnia virradatkor a Gellérthegyre, fényáldozatra bemutatva telepítő cédét.

Jó, távolítsuk el. Itt másztunk bele a mocsárba. Hivatalosan ugyanis el lehet. De. Az internet tele van rémtörténetekkel, mi is történt azokkal, akik naív módon nekiálltak uninstallálni a keretrendszert. Eleve a 3.5 csomagot csak úgy tudod kilőni, ha minden csomagot leszedsz, melyet az rakott fel. De le tudod szedni? A történet ott kezdett tragikomédiába fordulni, amikor rátaláltam Aaron Stebner – MS alkalmazott srác – blogjára, ahol megemlíti, hogy szabadidejében írt egy progit – As Is – mely le tudja szedni akkor is a dotnetrusnyákat, ha azok nem akarnak eltávozni. (Legfrissebb változat.) Ekkor mondtam azt, hogy kösz, de nem. Legalább induláskor legyek biztos abban, hogy a rendszer flottul működik, nincs belekódolva semmiféle döglött(?) akna.

Formatcé.

Szépen összeraktuk újra az egészet, csak most már kihagytuk a dotnet kettő feletti csomagokat. Mindenki megnyugodott, csak bennem maradt némi tüske a dotnetekkel kapcsolatban.

Aztán itt volt a mai nap.

A héten keresett egy kolléga, hogy az ügyfél rendszerében, ha Outlook 2007-ből akarnak megbeszélést szervezni, nem látják a foglaltsági információkat.
Sóhaj.
Apa, kezdődik.

Egy nagyméretű rendszerben, ahol egyszerre vannak jelen Exchange 2003 és 2007 szerverek, ahol egyszerre van jelen az összes MAPI kliens, melyet a Microsoft az utóbbi tíz évben gyártott, beleértve az összes service pack kombinációt is – nagyjából huszonötmillió oka lehet, hogy egy konkrét kliensen miért nem megy a Free/Busy.
– Látja a CAS szervert? Internet Explorer beállításainál benne van a CAS a proxy kivételek között? – kérdeztem rá.
– Hoppá – jött a válasz.
Nem volt benne.
– Megjavult?
– Nem mondhatnám. Mostantól Váratlan Hibával elszáll az Outlook.
– Hah. Kliens oldali hiba. Apage Satanas.
– Mi legyen?
– Pecseljétek halálra. Aztán majd meglátjuk.
Felraktak rá minden létező szervízcsomagot, javítófoltot.
– Na? – kérdeztem rá.
– Ugyanaz. Sőt, az Out of Office be sem jön.
– Miaf? Állítsátok be légyszi, hogy elérjek egy tesztgépet.

És tényleg. Pedig az Autoconfiguration teszt szépen megmutatta, hogy az Autodiscovery a pontos OOF webservice útvonalat adta vissza. (Azaz az EWS útvonalát.) Ha ezt az útvonalat bemásoltam az IE-be, meg is kaptam a korrekt xml-t. Jogosultság az EWS-en? Tökéletes.
Az mindenesetre ekkor már látszott, hogy nem kliens oldali hibáról van szó. Mind az OOF, mind az Availabilty service (Free/Busy) az EWS-t használja, tehát ott lesz valami gubanc. De mi?

Nézzük, itt van a test-outlookservices parancs. Mit mond, ha megkérdezzük?
Ekkor koppant az állam a padlón: a harmadik lépésben error-ral elszállt. Na de kérem…? Egy default telepítésű CAS+HTS szervernél nem működik az EMS? Szar a powershell?

Vad guglizás következett.

Nem akarom a végtelenségig fokozni a feszültséget, az első értelmes nyom ez a thread volt egy fórumon. A jelenség pont ugyanaz, gyönyörűen látni, hogyan gyűlnek a károsultak, hogyan válik belőlük izgatott tömeg, hogyan saccolnak először a .Net 3.5 sp1-re, hogyan lesz egyre élesebb a gyanú, végül hogyan válik bizonyossággá: az egyik bátor jelentkező leszedte a 3.5 sp1-et (Hogyan?? – hördült fel a közönség.) és egyből megjavult nála a helyzet. Végül kialakult az a konklúzió, miszerint a tuti módszer az sp1 leszedése, bár valaki megjegyezte, hogy a Microsoftnak mintha lenne egy nem publikus javítófoltja is.

Ehhez képest volt felüdülés a következő találat, ahol az a bizonyos javítófolt nevesítve is lett. Innen lehet letölteni a csomagot. (Igen, csomagot. Nem csak a 3.5-höz kell patch, hanem az egész bagázshoz. Vigyázat, a sorrend is számít.)

Most már jó. Legalábbis, majdnem. A kliensek már nem panaszkodnak, megy rendesen minden, ami EWS-re épül. Egyedül a test-outlookservices nem fut még le rendesen, telesírja a képernyőt sémahibákra panaszkodva. Azaz lesz még itt néhány tiszteletkör.

Utazó fájlok

Ilyen is régen volt, hogy egy napra két bejegyzés jusson.

Néhány napja kaptam egy kérdést, ami a fájl share-ek és sharepoint dokumentumtárak elérésére vonatkozott mobil eszközről.

Az Exchange 2007 tud olyat, hogy fájl share-ekhez, vagy sharepoint dokumentumtárakhoz nyújt hozzáférést az OWA felületén keresztül, csak olvasható módon. Ezt korábban demonstráltam is egy screencastban.

Mindenféle marketing anyagokból kiderül, hogy a szerkezet tud ilyet ActiveSync-en keresztül a Windows Mobile eszközön is. Ennek a szerver oldali konfigurációs lépései meg is találhatóak itt.

Viszont most jön a 100 forintos kérdés: Hogyan lehet az így publikált információhoz hozzáférni a mobil eszközön?

Körülnéztem. Az ActiveSync-en nincs erre vonatkozó beállítási lehetőség. A File Explorerbe beírva a linkeket hibát dob.

Hosszas keresgélés után végül megtalátam a választ. Bár az OWA-s és az ActiveSync-es konfiguráció és a marketing anyagok arra utalnak, hogy ez két egyenrangú funkció, a valóság eltér ettől. Ha a céges hálózatunkon egy asztali gépen írunk egy levelet, amibe nem belecsatoljuk az elküldendő fájlt, hanem az unc elérési útvonalával belerakjuk a levélbe, és az Exchange-et megfelelően konfiguráljuk (megengedjük, hogy az ActiveSync-et használó eszköz hozzáférjen a fájl, vagy sharepoint szerverhez), akkor a fenti levelet Mobile eszközön olvasva hozzá tudunk férni a fájlhoz. Erről bővebben itt olvashatunk.

A mobil eszközön rákattintva a levélben lévő linkre feljön egy Internet Explorer és a következő formátumú linket nyitja meg:

activesync:file:////server/share/file

 

Ebből azt gongolhatnánk, hogy így bármilyen publikált fájlhoz hozzá tudunk férni. Sajnos ez a gyakorlatban nem működik. Csak azokat a fájlokat nyitja meg, amelyeket ilyen módon átküldtek nekünk.

 

DistList & DistList 2007

Ezzel a cikkel két éve tartozom magamnak. A cikket akkoriban meg is írtam, de sosem publikáltam, mert elsodort az élet. Most publikálom, de azóta sok minden változott. Azok a részleteket, amik az eredeti cikkből származnak, itt dőlt betűvel írom.

Az előzmények:

Van egy kedves baráti társaságunk (InetPub). Ez a baráti társaság üzemeltet egy levelezőlistát. Ezt végtelenül egyszerűen oldottuk meg. Az egyik kolléga Exchange szerverén felvettünk egy disztribúciós listát és a külsős tagokat felvettük az ő Active Directory-ába contact-ként.

Ezzel  a dologgal csak egy gond van. Miután az egész levelező listaként működik, jó lenne megoldani, hogy a kimenő levelekben a Reply-To cím a lista címe legyen. Mi sem egyszerűbb ennél, a csapat egyik tagja írt egy SMTP Sink-et ami alig pár sor és a rajta áthaladó leveleken beállítja a Reply-To mezőt. Ez a Sink-et pedig egy RCPT TO=<listacíme> rule-al regisztrálta. Ez a megoldás szép és jó, mindaddig, amíg a levelek külső feladótól érkeznek. A külső feladóknál szépen végrehajtódik a Sink, de a belső feladónál nem hajtódik végre, hiszen az eredeti listás címzettel rendelkező levél el sem jut az SMTP szerverig, hiszen hamarabb feloldja a rendszer a lista címét az egyenkénti címzettek címére.

Valamikor 2006 decemberében nekiláttam, hogy a fenti állapotot megszüntessem. Elkészült (akkor még Exchange 2003-hoz) egy sink, ami képes a belső címekkel is megcsinálni a fenti trükköt. Tehát folytatva:

Ez a megközelítésem, mint későbbiekben rájöttem, alapvetően hibás. Az Exchange-ben azok a levelek amik belső feladótól MAPI kliens-el küldve belső feladóhoz tartanak is átmennek az SMTP szerver transport részein és végrehajtódnak rájuk az OnTransportSubmission (OnArrival), PreCategorize, PostCategorize események. Ha ezek az események végrehajtódnak, akkor mégis miért nem találkozunk ezekkel a levelekkel az OnArrival Sink-re írt scriptekben? Ennek egyszerű oka van. Amikor regisztrálunk egy Sink-et akkor megadunk egy szabályt (Rule) ami alapján kiválogatja a rendszer azokat a leveleket amiket a Sink-űnk megkap. Ezzel egy gond van. Ez a szabály egy protokoll szabály, azaz az SMTP protokoll kommunikációban lévő elemekre (MAIL FROM, RCPT TO) lehet szűrni. A MAPI levelek viszont nem haladnak keresztül az SMTP szerver protokoll részén így protokoll szabályokat sem lehet rájuk érvényesíteni. A képlet egyszerű: Ha van szabály, akkor nem látjuk a MAPI leveleket. Ezt sajnos a Microsoftnál sem gondolta végig senki így a Sink regisztrációra írt smtpreg.vbs egyetlen verziója sem képes szabály nélkül Sink-et regisztrálni (sajnos az üres szabály is szabály).

Ezen felfedezéseim alapján arra gondoltam, hogy írok egy olyan SMTP Sink-et ami megoldja, hogy a belső felhasználók által küldött leveleken is jó Reply-To cím szerepeljen.

Elképzelések:

Nincs semmi különös teendőm, mindösszesen a fenti eredeti Sink-et kiegészítem egy belső a címzettre vonatkozó szűrővel és már kész is vagyok. Ez alapvetően bukott meg. A MAPI levelek nem MIME formátumban utaznak az SMTP szerveren hanem TNEF formátumban. Bármit módosítok a levélen azt a rendszer eldobja és az eredetivel dolgozik tovább (http://support.microsoft.com/?id=273233)

Ez az a pillanat amikor el kellett vetnem, hogy ezt az egészet script-ben meg tudom írni. Elővettem a Microsoft menedzselt kódban való Sink írásról készült cikkét és a benne található Interop és Wrapper osztályokat. Rengeteget kísérleteztem, sajnos az eredeti Wrapper-t is ki kellett egészíteni (nem képes kezelni a MAPI címzést, csak az SMTP-t). Itt kell megemlítenem, hogy Dean Harding cikke (http://codeka.com/blogs/index.php/dean/2005/06/06/managed_iis_smtp_sink_wrapper_message_co) alapján a CopyContentToStream funkciót is módosítottam (miután kénytelen voltam az eredeti wrapperbe több helyen belenyúlni, így nem követtem az ő kívülről módosítgató módszerét itt sem, hanem beleírtam az eredeti kódba).  A dolog igencsak nyakatekert lett. Megpróbálom felvázolni nagy vonalakban, hogyan is működik:

1.       Az OnTransportSubmission Sink-en végignézem a bejövő levél címzettjeit és a Global Catalog alapján megnézem, hogy van-e köztük disztribúciós lista. Ha találok ilyet, akkor ezt a címet lecserélem egy olyan dummy címre ami három szabálynak felel meg.

a.       Egy későbbi Sink felismeri, hogy ezt a címet az én Sink-em csinálta.

b.      Tartalmazza a disztribúciós lista objectGUID azonosítóját

c.       Olyan e-mail domain-be tart, ami mindenképp az Exchange hatókörén kívül van. Erre azért van szükség, mert ha belső cím lenne, akkor az SMTP szerver a későbbiekben nem konvertálná a TNEF levelet MIME-ra és így nem tudnánk feldolgozni.

2.       Az OnMessagePostCategorize Sink-en megkeresem azt a levelet, ami a korábbi Sink által berakott E-Mail címmel rendelkezik. A Global Catalog alapján visszacserélem az eredeti lista címre, belerakom a Reply-To mezőt, és a levelet leteszem az SMTP szerver pickup könyvtárába.

3.       A szerver felveszi a levelet és újra végigmegy a folyamaton (a levélbe közben tettem egy olyan fejléc mezőt is, amit észrevéve az első Sink nem módosítja újra). Ekkor a categorizer már kibontja az eredeti disztribúciós listát a végső címzettekre.

Ennyit az eredeti cikkből. Itt most az következne, hogyan kell telepíteni és használni az egészet. Ez azóta változott. Hogy miért, arról később.

Szóval valamikor 2007. január elején el is készült egy verzió, amit használatba is vettünk. Nem telt el egy hónap, amikor a kolléga (BB), akinél a rendszer volt tudata velem, hogy átállás lesz, és a lista költözik Exchange 2007-re. Ő akkor azt gondolta, hogy semmi gáz, biztos megy a régi sink az új szoftveren. Tévedett. Kemény küzdések árán ekkor tanultam megy Exchange 2007 Transport Agent-et írni.

Az új verzióra szánt szerkezet is működött. Időm továbbra sem volt publikálni.

Valamikor 2008-ban megszültetett egy MVP levelező lista, Exchange 2003 alapon, amit az első verzióval oldottak meg a kitalálói.

2008 nyarán volt egy Rendszergazdák napja című esemény, ami után született több levelező lista a fenti Exchange 2003 szerveren.

Az üzemeltető (GT) ezt a szervert most a napokban állította át 2007-re, így esedékessé vált a sink cseréje is. Ezen felbuzdulva nekiláttam, hogy

1. Egy kicsit kipofozzam mind a 2003-as, mind a 2007-es verziót.

2. Írjak hozzá némi dokumentációt (ez egyelőre még angol, mert máshol is publikálni akarom)

Az elkészült darabok itt érhetőek el:

DistList (Exchange 2003-as verzió)

DistList 2007 (Exchange 2007-es verzió)

Forráskód

Dokumentáció

Ha valakinek kérdése, megjegyzése, továbbfejlesztési ötlete van, azt szívesen fogadom.