Author: SUF

Az elfelejtett screencast

A tegnap publikált hat screencaston túl készült egy hetedik is, amiről teljesen elfeledkeztem. Ez egy alapozó lett volna az Informatika Tisztán csoportmunka részéhez, ami a végleges előadások összerakásánál kimaradt. Erről el is feledkeztem tegnap, így ezt most adom közre.

POP3 – SMTP

A demo kicsit benéz a motorháztető alá. Bemutatja, milyen forgalom zajlik a pop3 és az smtp protokoloknál a kliens és a szerver között, pontosabban arról szól, hogyan tudunk egy telnet kliens segítségével levelet küldeni és fogadni.

Exchange Screencastok

Az elmúlt két évben gyártottam összesen 6 db screencastot az Exchange 2007-el kapcsolatban. Ebből kettő még a termékbejelentés körül készült, a maradék négy pedig az idei Informatika Tisztán előadássorozathoz. Ez utóbbi négy valahogy sosem jutott el az interneten való megjelenésig (vagy csak én nem találtam meg őket). Itt most közreadom mind a hatot némi magyarázattal.

Certificate

Arról szól, hogyan készítsünk saját Windowos Certificate Authority-vel tanúsítványt az Exchange 2007-hez

Exchange 2007 – WM6

Bemutatja, hogy az Exchange 2007 és a Windows Mobile 6 együttes használata milyen újdonságokat hozott a mobil kommunikációban

Outlook Anywhere

Az Outlook Anywhere (leánykori nevén RPC over HTTP) és az Autodiscovery szolgáltatás konfigurációja szerver és kliens oldalon

Sharepoint Integráció

Kétirányú SharePoint integráció bemutatása. Hogyan lehet az Outlook Web Accessből Sharepointon tárolt dokumentumokat elérni, valamint hogyan lehet Exchange naptárat a Sharepoint felületre publikálni

User Import

Egy egysoros PowerShell script ami képes csv fájlból Exchange felhasználók tömegét gyártani

Windows Mobile Konfiguráció

Windows Mobile 6-os eszköz konfigurációja az Exchange 2007 ActiveSync-hez.

DataViz RoadSync 4.0

Megjelent a DataViz RoadSync nevű termékének új, 4.0-ás változata.

Azoknak, akik esetleg nem ismernék, ez a termék teszi lehetővé az ActiveSync for Exchange használatát nem Microsoft operációs rendszerrel rendelkező mobil eszközökön (pl. Symbian S60, Symbian UIQ, stb.).

Újdonságok:

– HTML levél kezelés

– Taszk szinkronizálás

– Névjegyhez kapcsolt fénykép kezelés

– Pop-Up értesítés az új levelekről

– Gyorsbillentyűk használata

– S60 3d Edition FP2 eszközök kezelése

Ez a hír már kb. egy hetes, úgy terveztem, hogy kipróbálás után írok a szoftverről, kicsit bővebben, ezért vártam vele. Ma végre sikerült felraknom a jó öreg Nokia E60-asomra. Kicsit csalódtam, mert lassabb lett a korábbi változatnál és az én készülékemen nem kezeli a HTML leveleket (ehhez S60 3d Edition FP1 a minimum verzió). A csalódottságom egyértelműen a telefonomnak és nem a szoftvernek róható fel.

További infók: http://www.dataviz.com

Exchange 2007 Edge és az ISA

Nem vagyok egy ISA guru (őszintén nem is használom és piszokul nem is értek hozzá), ezért csak röviden írom le a mai küszködésem végeredményét. Próbáltam beüzemelni egy Edge szervert ami az ISA által kifeszített DMZ-ben lakott.

Az Edge és a Hub transport valahogy nem akart kommunikálni egymással ezért a levelezés nagyon nem akart menni. Se be se ki. A protocol log-ból az derült ki, hogy amikor az Edge kapcsolódott a Hub-hoz próbált egy TLS csatornát kialakítani, amibe belehalt azzal, hogy az X-ANONYMOUSTLS ESMTP parancsra kapott egy nagy büdös 5.5.1 Unrecognized command választ. Nem tudtam mire vélni a dolgot, túrtam a netet, de választ azt nem találtam (persze ugyanezt a kérdést megtaláltam itt). Sokkszori kísérletezés és a TLS kapcsolgatása után megleltem a megoldást.

Az ISA SMTP Filtere nem ismeri a fenti parancsot ezért kiszűri. A DMZ és a belső háló között az ISA-n kikapcsoltam az SMTP Filtert (persze a 25-ös port átengedése az maradt) és most megy mint a kisangyal.

Outlook 2007 és a HTML

Az elmúlt hetekben a hírlevél küldés rejtelmeivel foglalkozom céges szinten. Miután saját hírlevélküldő motorom még nincs (a régi félkész levlista motorom, és a házi barkács scriptjeim nem igazán alkalmasak a feladatra) ezt használom erre a célra.

A napokban felmerült, hogy bizonyos saját termékeinket hirdetni kellene a hírleveleinkben. Azt gondoltam, hogy belepakolok a levélbe egy flash bannert. Csináltam is valami tesztet, el is küldtem magamnak. A banner helyett egy kedves piros X jött. Gondoltam biztos én vagyok a béna, mert a flash-t nem sima img-ként kell a html-be illeszteni (html-ből, css-ből eléggé limitált a tudásom). Fel is hívtam az ügyben guru ismerősöm, aki elmondta, hogy valóban nem img ami nekem kell, de:

1. Fejből nem tudja, hogy mi kéne

2. Az Outlook 2007 szerinte nem eszi a flash-t és a neten valahol van egy doksi ami beszél erről

Ok, akkor hagyjuk a flash-t van nekem egy animált gif-em az egyik termékhez, majd használom azt, ha elő tudom bányászni (az IE biztonsági beállításai miatt nem tudtam kimenteni az ADserver-ünkről). Addig is szóltam az online szerkesztőnek, hogy próbálja meg előkaparni.

Malmozás helyett nekiálltam túrni a netet a fenti Outlook doksi után.

Az első amit találtam egy cikk amiben azon pörög a szerző (mint később magam is rájöttem, joggal), hogy az Outlook 2007-ben a HTML rendering engine az IE helyett a Word.

Másodszorra rábukkantam az ismerős által emlegetett két Microsoft cikkre:

Rögtön az első cikkben meg is lett a válasz a flash/animált gif kérdésre:

Other Unsupported Web-Related Features

The following is a list of all other Web-related features that Word 2007 does not support:

  • Animated GIF images. Only a static representation of the GIF image shows.
  • Flash. Only a red “X” shows in the area where the flash would display.

Nem vagyok boldog.

Ráadásul a még csináltak egy külön HTML validatort kifejezetten az Outlook 2007-hez, amikor, ha csak betartották volna a szabványt, akkor nyugodtan lehetne ezt használni.

Exchange 2007 és a Relay

Az egyik kollégám jött azzal az igénnyel, hogy szeretne a cégen belülről is és kívülről is leveleket küldeni (ez ugye nem kaland), de mindezt egy MacBookról és egy iPhone-ról. Nosza rajta, beizzítottam az IMAP-ot és a Client Server nevezetű default SMTP receive connectort. A dolog működött, én nyugodtan hátradőltem, béke.

Eltelt 2-3 nap és a kolléga szól, hogy a céges mail-jét tudja így használni, de a magánt nem. Hirtelen nem értettem a dolgot, hiszen (tudomásom szerint) a Client SMTP connector pont azért van, hogy a bejelentkezett felhasználók tudják relay-nek használni.

El kezdtem keresgélni és kiderült, hogy rosszul tudom. A bejelentkezett felhasználó alapból, csak a rendszerben létező domainek nevében tud küldeni. Azt, hogy bármilyen domain-t használhasson a következő PowerShell paranccsal lehet megengedni:

Get-ReceiveConnector -Identity “SERVER\Client SERVER” | Add-ADPermission -user “DOMAIN\Domain Users” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Sender”

További információk itt:
http://technet.microsoft.com/en-us/library/bb232021.aspx

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:

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

https://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);
        }
    }
}

 

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

Keresés az AD-ben e-mail címre

Egy régi problémám volt az, hogy hogyan találjunk meg egy felhsználót az Active Directoryban az e-mail címe alapján. Volt erről egy hosszú thread a technetklub levlistán (http://listmanager.technetklub.hu/read/messages?id=122959 [2008-05-30: Ez a link már nem él. A technetklub levlista kimúlt, béke poraira. Még nem adtam fel, hogy az archívumot egyszer kirakom az internetre publikusan, de sajna nincs időm befejezni a kódot.]) amiből az derült ki, hogy valamelyik proxyAddress alapján nehéz megtalálni a felhasználót, ráadásul lassú is. A probléma alapja, hogy azt gondoltom (gondoltuk többen), hogy a proxyAddresses propertyben nem lehet keresni mert az egy multivalue property. Már tervezgettem, hogy írok valami szolgáltatást a dologra. Egy progi megadott időközönként végigtúrja az AD-t épít belőle egy adatbázist amiben utána én tudok gyorsan keresni.
Ma megint kellet volna ez a dolog így tüzetesebben utánnanéztem a Windows 2000 Scripting Guide-ban (http://www.microsoft.com/technet/scriptcenter/guide/default.mspx). Olvasva az ADSI keresésre vonatkozó részt egy mondatra figyeltem fel (itt: http://www.microsoft.com/technet/scriptcenter/guide/sas_ads_jgtf.mspx):
…use objectCategory rather than objectClass because objectCategory is single-valued and ideal for servicing search requests…
 
Várjunk csak, ezek szerint lehet multivalue propertyben keresni. Kipróbáltam. Íme az eredmény:
var SearchMail = "test@domain.hu"; 
var ADConnect = new ActiveXObject("ADODB.Connection"); 
var ADCommand = new ActiveXObject("ADODB.Command"); 
var rootDSE, ForestRoot, ADRS; 
rootDSE = GetObject("LDAP://rootDSE"); 
ForestRoot = rootDSE.Get("rootDomainNamingContext"); 
ADConnect.Open("Provider=ADsDSOObject;"); 
ADCommand.ActiveConnection = ADConnect; 
ADCommand.CommandText = "<GC://" + ForestRoot + 
    ">;(&(objectCategory=user)(proxyAddresses=smtp:" + 
    SearchMail + "));name;subtree"; 
ADRS = ADCommand.Execute(); 
for(; !ADRS.EOF; ADRS.MoveNext()) 
    WScript.Echo(ADRS.Fields("name").Value); 
ADConnect.Close();

Mail fájlok és a CDO 2.

Pár napja írtam már a fenti címről. Akkor úgy gondoltam, hogy egy JScript példa elég lesz. Közben rájöttem, hogy .Net környezetben ez kevés (a típusosság miatt jóval több dolgot meg kell adni). Ezért most itt egy C# metódusként megírt példa (a referenciák közé fel kell venni az ADO és a CDO COM Objektumokat):
public static CDO.Message LoadMsgFile(string FileName)
{
    CDO.Message Msg = new CDO.MessageClass();
    ADODB.Stream MsgStream = new ADODB.Stream();
    MsgStream.Type = ADODB.StreamTypeEnum.adTypeBinary;
    MsgStream.Open((object)System.Type.Missing,
        ADODB.ConnectModeEnum.adModeUnknown,
        ADODB.StreamOpenOptionsEnum.adOpenStreamUnspecified,
        "","");
    MsgStream.LoadFromFile(FileName);
    Msg.DataSource.OpenObject(MsgStream,"_Stream");
    return Msg;
}

Mail fájlok és a CDO 1.

Abba a problémába futottam a levlista program fejlesztgetése során, hogy hogyan dolgozzuk fel azokat a leveleket amik az SMTP szerver drop könyvtárába érkeznek, vagy bármilyen más MIME formátumú levelet. Ha ez a levél eml kiterjesztéssel rendelkezik és egyszerűen rákattintunk akkor jön az Outlook Express és megmutatja a levelet. Természetesen ha programból kell csinálnunk valamit vele, akkor ez nem lesz ilyen egyszerű.  Például mi van akkor, ha szükségünk van egy From egy To vagy egy Subject mezőre? Esetleg a levél törzsét (HTML Body) szeretnénk letárolni egy adatbázisba?
Megtehetjük azt, hogy reguláris kifejezésekkel kiszedjük a fájlból amire szükségünk van. Megtehetjük, hogy írunk egy feldolgozó programot ami megfelelően szétszedi a levelet az igényeinknek megfelelően. Egyik megoldás sem egyszerű, ráadásul szükségtelen. A Microsoftnak van egy megfelelő objektum könyvtára erre. Ez a CDO (vagy CDOEX).
A feladatunk annyi, hogy a levelet betültsük egy CDO.Message objektumba. Ezzel csak egy probléma van. Ez az objektum nem kínál közvetlenül olyan lehetőséget, hogy fájlból betöltsük a tartalmát. Ezért azt tehetjük meg, hogy a fájlt megnyitjuk egy ADODB.Stream-ként és ezt adjuk meg adatforrásként a CDO.Message objektumnak. Ez JScriptben így fog kinézni:
function LoadMsgFile(FileName) 
{ 
    var adTypeBinary = 1; 
    var Msg; 
    var MsgStream; 
    Msg = new ActiveXObject("CDO.Message"); 
    MsgStream = new ActiveXObject("ADODB.Stream"); 
    MsgStream.Type = adTypeBinary; 
    MsgStream.Open(); 
    MsgStream.LoadFromFile(FileName); 
    Msg.DataSource.OpenObject(MsgStream,"_Stream"); 
    return Msg; 
}

Másodlagos SMTP (Exchange Karbantartás)

Feltettem egy kérdést a levlistán a minap. Viszonylag ritkán szoktam kérdezni, de most megtettem. Kiváncsi voltam, hogy az előttem álló problémát mások hogyan szokták megoldani.
A feladat a következő:
Van egy Exchange szerverem (ami mellesleg DC, meg fájl szerver is) ami kezd kifogyni a szabad helyből. Úgy döntöttem, hogy a bővítést nem plusz diskek berakásával, hanem a jelenlegiek cseréjével fogom megoldani. Ez néhány órás rendszerleállást okoz. Ez felveti azt a problémát, hogy mi legyen a közben beérkező levelekkel. Az is lehetőség lenne, hogy nem törődöm az egésszel, mert a levelezőrendszerek alapértelmezett időtúllépései miatt nagy valószínüséggel nem okozna problémát, de ennél biztosabb megoldást szeretnék két okból:
1. Ha esetleg mégsem jönne össze az időtúllépésen belül megoldani a dolgot, nem  vet jó fényt rám, hogy a leveleket küldők felé késleletetésre vonatkozó üzenetek menjenek vissza, ráadásul ha valaki átállítgatta a saját SMTP szerveret időzítéseit, akkor nyugodtan lehet, hogy eldobja a leveleket.
2. Mi van akkor, ha az upgrade valamilyen okból nem sikerül, de az SMTP service mégis elindul és elkezd leveleket fogadni. Hogyan fogom ebben az esetben kibogarászni a közben bejött leveleket?
Feltettem azt a kérdést, hogy:
“Ki, hogyan oldaná meg azt a feladatot, hogy mondjuk van egy Exchange szerver amit karbantartási okokból néhány órára le kell állítani és nem szeretném, ha ez idő alatt a rendszerről visszapattannának a levelek. Magyarán az lenne a feladat, hogy valami átmenetileg átvegye a leveleket és tárolja addig amíg az Exchange újra nem él, majd beadagolja ezeket a leveleket.”
Többféle választ kaptam a kérdésre:
1. Megpróbálták megmagyarázni, hogyan működik az MX rekord, az SMTP és a DNS. Ezekről van némi távoli körvonalas fogalmam, nem igazán erre vonatkozott a kérdés. Tuti, hogy rosszul fogalmaztam (szoktam. ).
2. Többen javasolták a szolgáltató által nyújtott másodlagos relay szolgáltatást. Ez technológiailag jó lenne, ugyanakkor pont most versenyeztettem a szolgáltatókat, mert a bérelt vonalért jelenleg fizetett összeg nem picit barokkos. Ebben a képlékeny helyzetben nem szeretnék semmit megrendelni a jelenlegi szolgáltatótól.
3. Álítsak be másodlagos SMTP szervet! Na igen, erre gondoltam. Ugyanakkor senki sem fejtette ki, hogy ezt hogyan tudom a legkissebb munkával megoldani. Magánbeszélgetésekben hallottam erre PostFixet, másik Exchange-et stb. Ezekkel az a baj, hogy messze vannak a legkissebb munkáról alkotott elképzeléseimtől. A PostFix azért mert nem értek hozza, az Exchange meg azért mert nem szeretnék atombombával lövöldözni a bolhára.
Ezek után gondoltam, hogy maradok a fejemben lévő eredeti megoldásnál. Ez abból állna, hogy fogok egy XP-t, felrakom rá az SMTP Service-t, írok egy Event Sink-et ami berakja a levél fejlécébe az SMTP boríték recipient mezőjét és egy scriptet ami felveszi a Drop könyvtárból a leveleket és az Event Sink által berakott fejléc mezőben lévő címekre elküldi a levelet (ezek a scriptek úgy is jól jönnének nekem később másra).
Neki is kezdtem a munkának amikor is az MSDN-en mászkálva (http://msdn.microsoft.com/en-us/library/ms875938(EXCHG.65).aspx) valamin megakadt a szemem:
“The address list corresponds to the set of RCPT TO SMTP protocol commands received for the message, or the X-receiver headers present at the beginning of the message if it was submitted to the local SMTP service pickup directory.”
Nézzük csak meg. Mi van akkor, ha a bejövő levelet az SMTP szolgáltatással lepakoltatom a Drop könyvtárba? Kipróbáltam. Szépen megjelenik benne az X-receiver mező. Hopp, Event Sink kilőve. Nem kell mert az SMTP megcsinálja maga. Ha már itt tartunk, továbbmentem. Némi konfig után beraktam az így kapott levelet a Pickup könyvtárba. A levél elment és megkaptam a céges levelezőben. Hurrá!!!  Ugy látszik sikerül megoldanom a legkisebb munkával a problémát, még programolni sem kellett, hozzá. Akkor most a procedúra (hátha egyszer jól jön másnak is):
1. XP telepítés (Na ez nem fog kelleni, mert van gép amit tudok rá használni)
2. SMTP Service telepítés (XP tűzfalon beengedni a 25-ös portot!!!)
3. SMTP Service-en beállítani a szóban forgó domain-t mint lokális domain-t.
4. DNS-ben átírni az MX-et
5. Megcsinálni a szerver átállást, leellenőrizni, hogy minden megy-e
6. Visszaírni (kivenni) az MX-et
7. Kivenni az SMTP Service-en a szóban forgó domain-t a lokális domain-ek listájából.
8. A Drop könyvtár tartalmát átmásolni a Pickup-ba.
Kész.
Ha minden jól megy a jövő hét végén meg is csinálom az upgrade-et. Remélem sikerül gördülékenyen lebonyolítani a dolgot. Valahogy nem szeretnék olyan cikket írni a jövő hétvége után amilyet JoeP-nek sikerült (https://www.emaildetektiv.hu/2005/07/14/a-lehetetlenre-egy-kicsit-varni-kell/). Abszolult együttéreztem vele annak idején amikor olvastam.
[2008-05-30: Kicseréltem a linkekeket élőkre, remélem nem nyúltam mellé]

SMTP Tiltott domainek listája – avagy IIS Metabase reszelés

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/<szerver neve>/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.
Option Explicit 

'Constants
Const ForReading = 1 

'Initial parameters
Dim FileName,IsOverWrite,SmtpVsAdsi
IsOverWrite = True
FileName = "c:\work\metabase\test.txt"
SmtpVsAdsi = "IIS://LocalHost/SMTPSVC/1" 

'Variables
Dim DomainName
Dim i
Dim FSO, f
Dim DomainList 

'Code
If IsOverWrite Then
    DomainList = Array("")
    DomainList(0) = ""
Else
    DomainList = GetDomainList(SmtpVsAdsi)
End If 

Set FSO = CreateObject("Scripting.FileSystemObject")
Set f = FSO.OpenTextFile(FileName, ForReading, True) 

Do While f.AtEndOfStream <> True
    DomainName = Trim(f.ReadLine)
    If DomainName <> "" Then
        AddDomain DomainList, DomainName
    End If
Loop 

f.Close 

SetDomainList SmtpVsAdsi, DomainList 

'Functions 

Function GetDomainList(Path)
    Dim SmtpVS
    Set SmtpVS = GetObject(Path)
    GetDomainList = SmtpVS.IPSecurity.DomainDeny
End Function 

Sub SetDomainList(Path,DomainArr)
    Dim SecObj
    Dim SmtpVS
    Set SmtpVS = GetObject(Path)
    Set SecObj = SmtpVS.IPSecurity
    SecObj.DomainDeny = DomainArr
    SmtpVS.IPSecurity = SecObj
    SmtpVS.SetInfo
End Sub 

Sub AddDomain(DomainArr,DomainName)
    If Not ((UBound(DomainArr) = 0) and (DomainArr(0) = "")) Then
        ReDim Preserve DomainArr(UBound(DomainArr)+1)
    End If
    DomainArr(UBound(DomainArr)) = DomainName
End Sub

vcf bulk export

Egy valami kis kézi eszköz egyszeri szinkronizációjához szükségem volt arra hogy az Outlook névjegyalbumból kipakoljam a bejegyzéseket vcf formátumba. Ahogy elnéztem ezt a drága Outlook csak egyesével hajlandó előadni. Gyorsan összedobtam egy scriptet rá. Azt, ha keletkezett név nem felel meg a fájlnév konvencióknak nem kezeli le, de egyenlőre nekem ennyi elég volt. Minden egyéb magyarázat helyett itt a kód:

var olFolderContacts = 10; 
var olContact = 40; 
var olVCard = 6; 
var Application; 
var Namespace; 
var ContactsFolder; 
var TargetFolder; 
Application = new ActiveXObject("Outlook.Application"); 
Namespace = Application.GetNamespace("MAPI"); 
ContactsFolder = Namespace.GetDefaultFolder(olFolderContacts); 
TargetFolder = "c:\\work\\vcf\\"; 
e = new Enumerator(ContactsFolder.Items); 
for(;!e.atEnd();e.moveNext()) 
{ 
    Item = e.item(); 
    if(Item.Class == olContact) 
    { 
        Item.SaveAs(TargetFolder + Item.FileAs + ".vcf",olVCard); 
    } 
}

 

Outlook Form

É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 ).

[2008-05-30: Ebből nem lett publikálható dolog]

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?