Jó néhány hónappal ezelőtt volt egy elég kemény problémám egy WMI script-el

var objWMIServices; 
var Sink; 
var EventArr; 
var i = 0; 

EventArr = new Array(); 
objWMIServices = 
    GetObject("WinMgmts:{impersonationLevel=impersonate, (security)}"); 
Sink = WScript.CreateObject("WbemScripting.SWbemSink","SINK_"); 
objWMIServices.ExecNotificationQueryAsync(Sink,
    "SELECT * FROM __InstanceCreationEvent " + 
    "WHERE TargetInstance ISA 'Win32_NTLogEvent' " + 
    "AND TargetInstance.LogFile = 'Application'"); 

WScript.Sleep(5000); 

for (i = 0; i < EventArr.length; i++) 
{ 
    WScript.Echo(EventArr[i].TimeGenerated); 
    WScript.Echo(FromWMIDateTime(EventArr[i].TimeGenerated).toLocaleString()); 
    WScript.Echo(FromWMIDateTime(EventArr[i].TimeGenerated).toUTCString()); 
    WScript.Echo(((EventArr[i].User == null)? "N/A" : EventArr[i].User)); 
} 
Sink.Cancel(); 
delete Sink; 

function SINK_OnObjectReady(objEvent, objAsyncContext) 
{ 
    EventArr[i] = objEvent.TargetInstance; 
    i++; 
} 

function FromWMIDateTime(WMIDT) 
{ 
    var RetVal; 
    RetVal = new Date(ToInt(WMIDT.substr(0,4)), 
        ToInt(WMIDT.substr(4,2)) - 1, 
        ToInt(WMIDT.substr(6,2)), 
        ToInt(WMIDT.substr(8,2)), 
        ToInt(WMIDT.substr(10,2)), 
        ToInt(WMIDT.substr(12,2))); 
    return RetVal; 
} 

function ToInt(Str) 
{ 
    var i = 0; 
    while((Str.charAt(i) == "0") & (i < Str.length)) 
        i++; 
    return parseInt(Str.substring(i,Str.length)); 
} 

Ha ezt a kedves darabot Adminként futtatom, működik. Ha egy más felhasználó nevében, akkor is. Ha Adminként Scheduled Taskban megy akkor is működik, viszont ha egy más felhasználó nevében megy Scheduled Taskban akkor kapok egy kedves Eventlog hibát. Ezt:

Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10003
Date:  2005. 05. 26.
Time:  17:20:21
User:  XXXXX\backup
Computer: XXXXXX
Description:
Access denied attempting to launch a DCOM Server using DefaultLaunchPermssion. The server is:
{49BD2028-1523-11D1-AD79-00C04FD8FDFF}
The user is backup/XXXXX, SID=S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX.

Több helyen a neten feltettem mint kérdést, de nem jött rá válasz. Ma egy más probléma kapcsán elkezdtem vele megint játszani és ez lett a megoldás:

Az MMC Component Services Snap-in -ben a DCOM alatt a Microsoft WBEM Unsecured Apartment -re (ennek a GUID-je található az Eventlog bejegyzésben) Launch jogot kell adni annak a felhasználónak akinek a nevében a Scheduled Task fut.

SUF Blog Windows

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

SUF Blog Exchange

Az elmúlt kb. egy hetem gyakorlatilag a levelezéssel kapcsolatos dolgok megoldásával telt. Ennek kapcsan egy nagy rakás új script, kódrészlet készült, ami vagy teljesen új, vagy a már meglévő dolgaimat egészíti ki. Remélhetőleg a héten lesz időm, hogy ezeket ki is pakoljam az oldalamra. Most elsősorban magamnak le is írom ezeket, hogy tudjam hol tartok és milyen feladataim vannak (persze lehet, hogy mást is érdekel, hogy mik jönnek). Ha bárkinek szüksége lenne, az itt következő kódokra, még mielőtt kirakom őket a netre, akkor írjon és elküldöm e-mailben.

1. Névjegyek generálása az Outlookban lévő üzenetekből.

A technetklub levlistán felmerült egy igény, hogy jó lenne Outlook üzenetekből tömegesen névjegyeket gyártani:

http://listmanager.technetklub.hu/read/messages?id=126246
[Megjegyzés 2009.01.20: Ez a link már nem működik. Ha egyszer lesz archívum a régi levlistából, akkor majd frissítem]

Az eredeti "igénylőnek" elküldtem a scriptet. Ez még egy elég nyers fapados állapot. Dokumentálni, publikálni mindenképp fogom. Jó lenne valami kezelőfelületet is elkövetni hozzá, bár ezt nem igérem (van aki rágja a fülem a kezelőfelület miatt, ha megunom akkor írok egyet hozzá)

2. Microsoft Windows Server 2003 POP3/SMTP szolgáltatás Alias és Autoforward

Mint azt egy korábbi bejegyzésben írtam, be kell vezetnem az egyik cégünknél a címben jelölt szolgáltatást. Megnéztem mind a dokumentációt, mind az eszközt magát és arra a megállapításra jutottam, hogy a fenti két funkciót nem tudja megoldani (ettől persze még lehet, hogy tudja, csak nekem nem sikerült kicsikarnom belőle), ezért írtam egy SMTP Event Sink-et ami megoldja a feladatokat. Kész is van, némi dokumentáció, fazonírozás szükségeltetik még hozzá és mehet ki a netre.

3. Outlook Form, VBScript és Olvasóablak

Szintén az egyik korábbi bejegyzésben volt róla szó, hogy az Outlook az olvasóablakban nem tudja megjeleníteni azokat a leveleket amiknek az eredeti form-jában VBScript kód van. Kitaláltam rá egy koncepciót, hogyan lehet ezt megkerülni. A kód már el is készült olyan 80-90% -ig. Már működik, csak be kéne fejezni és ki kéne találni egy olyan módszert amivel más is fel tudja használni a saját programjaiban. Azt hiszem nincs már sok munka vele, talán ebből is cikk lesz még a héten.

4. Maildump

Az előző probléma megoldásának a mellékterméke egy olyan kis script ami képes egy Outlook levél (remélhetőleg összes hasznos) tulajdonságait kilistázni fájlba, megkönnyítve ezzel a különböző leveleket piszkáló programocskák fejlesztését. Tudom, hogy a Microsoft rendelkezik egy ilyen eszközzel http://www.microsoft.com/downloads/details.aspx?familyid=3d1c7482-4c6e-4ec5-983e-127100d71376&displaylang=en , de ez elsősorban c/c++ programozóknak készült, ebből következően nem igazán jó script és VBA makrók gyártásához. Ez a darab még eléggé kezdetleges állapotban van, de ettől függetlenül nem sok munka van már vele.

5. Alternatív feladó

Már elég régen csinálgatom ezt az alternatív feladó nevű dolgot. Most a publikáció mellett éles környezetben is kipróbáltam és kiderült ez-az (ennek lett a következménye a 3. pont is). Ezeket összefoglalva, összerakva ki fogom rakni az egész megoldás egy új verzióját, ami néhány már meglévő hiányosságot és néhány azóta talált újat javít. Még tervezem az OWA kiegészítését egy megfelelő form-mal, de ez nem most lesz.

6. Hasznos fügvények

A hasznos fügvények szekciót akarom kiegészíteni néhány apró osztállyal mint pl. fájlba logolás, vagy template-ek kezelése. Ezekben nincs semmi trükk vagy nagy ötlet, csak jól jönnek a scriptek gyártásához.

Na szóval mára ennyi. Lesz min rágódnom.

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.

SUF Blog Exchange

É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?

SUF Blog Exchange

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

SUF Blog Exchange

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

SUF Blog Exchange

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á!

SUF Blog Exchange

El kezdtem gondolkozni ezen a blog dolgon. Vajon olvassa ezt valaki? Eddig semmi visszajelzést sem kaptam.  Egyenlőre még nem vesztettem el a kedvem, hogy írjak. Meglátjuk.

Az előző bejegyzésem kapcsán (OWA programozás) újra eszembe jutott, hogy sok minden piszkálja a csőröm az Exchange-ben. Mindenféle hírekben lehet róla olvasni, hogy jön az E12 az Exchange következő verziója. Nem tudom, hogy időben vagyok-e még, de úgy gondolom, hogy össze kéne állítani egy kívánságlistát a Microsoftnak, hogy mit is szeretnénk látni a következő verzióban. Én leírok néhány ötletet, remélem másoknak is lesz hozzáfűzni valójuk, utána megpróbálom eljuttatni az illetékeseknek.

- Programozható, dokumentált OWA felület. Legalább olyan szinten dokumentált és testreszabható legyen mint az Outlook, hiszen egyre többen már csak ezt használják és ebből következően a mai helyzetben, az Outlook hozzáfejlesztések nem érhetők el az OWA-t használók számára.

- SQL motor a JET engine helyett. Tudom, ez nem fog bekövetkezni, de akkor is leírom

- Az SMTP szerver jobb scriptelhetősége. Szeretném elérni, hogy ne csak a jelenlegi OnArrival ponton lehessen scriptből beavatkozni, hanem a többi EventHandlernél is.

- A több e-mail címmel rendelkező felhasználók korrekt kezelése. Értem ez alatt, hogy az alapértelmezettől eltérő címekkel lehessen levelet küldeni, a különböző címekre beérkező levelekről a felhasználó lássa, hogy melyik címére érkezett, az elküldött elemek szétválogathatóak legyenek.

- A scripting egységesítése. A különböző pontokon lévő scripting engine jelenleg különböző tudással rendelkezik. Pl. a Store Eventeket és az Outlook formokat csak VBScriptben lehet megírni. Az SMTP-nél és a WSHnál működik a JScript is.

Most hirtelen ennyi jutott eszembe, ha valakinek van még ötlete, akkor azt várom, hátha el tudunk érni valamit.

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.

SUF Blog Exchange