27.-én volt a kicsi fiam második születésnapja. A nagycsalád összegyűlt délután a fiatalurat ünnepelni. Gyártattunk neki egy porszívó alakú tortát, mert mostanában nagyon rá van csatlakozva a nevezett eszközre.

A délután eltelt, sőt az este is. 10 óra magasságában hazafuvaroztam az anyósomat. Nem picit fáradtan az egész napi rohangálás után hazaérek és próbálnék behaladni a kertkapun.

Na ez nem jön össze, mert valami okos BMW-s (ki más) teljesen beállt a kapuba (azt ugye mondanom se kell, hogy az utcán természetesen öt méterrel arrébb volt olyan hely, ahol nem zavart volna senkit.

Elkezdtem dudálni, hogy hátha valaki észreveszi. Hát nem. Mintegy 15 perc alatt majdnem az összes szomszéd kijött az ablakba, hogy ki az a barom, aki dudál. Ebből arra következtettem, hogy nem a mi házunkban található a tulaj.

Nagyon berágtam. Beálltam az okostojás elé két centire. Majd elindultam fel a lakásba a párom autókulcsáért. Be akartam állni mögé két centire a másik autoval.

A párommal a lépcsőn találkoztunk, mert ő közben rájött, hogy én vagyok az az őrült, aki esztelenül dudál. Neki még volt egy ötlete, hogy hátha a barátnőjénél van valaki.

Felhívta.

Nyert.

Fickó előkerült, még volt hozzá néhány keresetlen szavam, melyben tudattam vele, hogy ha most nem jön, akkor lett volna még három perce addig amíg már nem tud mozogni az autójával.

Távozott.

Úgy döntöttem a nagy idegbetegségemre, hogy erre inni kell. Feljöttünk a lakásba így hárman (a barátnő, a párom és én). Megkínáltuk a barátnőt a fiam tortájából. A hölgy elkezdett gondolkozni. Majd a következővel állt elő:

A fickó, akinek az előbb leharaptam a fejét cukrász. Abban a cukrászdában ahol a tortát rendeltem és mesélte neki, hogy csinált ma egy porszívó alakú tortát...

Eddig a DotNetNuke-al kapcsolatban csak a problémáimról számoltam be. Most álljon itt az első megoldás.

Van Full-Text RSS !!!

Ezzel a dologgal három bajom volt:

1. A jövőbeni működésemhez saját magamnak is, és másoknak is statisztikákat kell produkálnom a működésemről. Ez az egyik oka annak, hogy egyáltalán belekezdtem az önálló oldal gyártása című projectbe. Azt gondoltam, hogyha nem csinálok full-text RSS-t akkor az olvasót ráveszem, hogy ellátogasson az oldalra, javítva ezzel a statisztikámat (egyelőre fogalmam sincs, hogyan lehetne a feed olvasást statisztikázni). Közben többen jelezték, hogy legyek olyan kedves és csináljak full-text feedet. Átgondoltam. Ám legyen.

2. Már az elején gondot okozott, hogy annak ellenére, hogy a dokumentáció ezt írja nem generál automatikusan summary-t.

3. Ugyan megtaláltam, hogyan lehet full-text feedet csinálni, de ez a 2. pontból következik, így meg vagyok lőve. Nincs automata summary - nincs full-text feed.

Akkor a megoldás:

Automata summary azért nincs, mert az FCK Editor magától bepakol valamit az üres szöveges mezőbe, a blog motor ebből azt érzékeli, hogy írtam summary-t tehát nem generál.
Ezt két módon lehet rendbetenni. A kézi hajtány mód, hogy basic text-re kapcsolom a formot és kitörlöm, amit az FCK belerakott. Az automata megoldás, hogy kicsit reszelgetek az FCK konfigján. Ezt:

FCKConfig.FillEmptyBlocks    = false ;

kell két fájlban javítani. Ezekben:

[dnnroot]\Providers\HtmlEditorProviders\Fck\FCKeditor\fckconfig.js
[dnnroot]\Providers\HtmlEditorProviders\Fck\Custom\fckconfig.js

Na nem én vagyok ilyen okos, hanem itt találtam a megoldást.

Ha ezzel megvagyunk, akkor teljes summary-t gyártani már nem nagy kaland, összesen a blog modul konfigjában a "Limit Auto-Generated Entry Summary To" című beállítást kell 0-ra állítani.

Na ezt se magamtól tudom, hanem innen szedtem.

Plusz megjegyzés. A 0 nem jó, mert akkor nincs link a teljes bejegyzésre. -1 lett a megoldás, ez már saját felfedezés.

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.

További kalandozások következnek a DotNetNuke világában.

Tegnap beharangoztam, hogy a blogom költözik ide. Rögtön kaptam is megjegyzést hozzá, hogy

1. Nem lehet kommentet írni.

2. Ha azt akarom, hogy olvassák, csináljak full text rss-t.

Az elsőhöz annyit, hogy lehet kommentet írni, de csak bejelentkezve. Ezen nem is nagyon szeretnék változtatni, mert kíváncsi vagyok, hogy ki jár erre. Kiraktam egy szöveget, ami tájékoztat erről. A másodikon egyrészről sokat gondolkozom, hogy szeretném-e. Valószínűleg meg fogom csinálni. Másrészről, még nem sikerült kibogarásznom, hogyan lehet megcsinálni.

Az egyéb bajom viszont kínos. Elkezdtem a Downloads szekcióba átköltöztetni a saját honlapomon, valamint a skydrive-on található fájlokat. Ezek egy része viszonylag méretes. A beépített korlátokat sikerült átlépnem a web.config szerkesztgetésével, de változatlanul nem tudom a 40MB fölötti fájljaimat feltölteni, mert egy 404-es hibát kapok. A korlát valahol 30 és 40 mega között lehet.

Egyenlőre küzdök.

Kicseréltem a logót, de ennél több kellene. Kéne valami design-t elkövetni, amihez nem értek. Se design, se DNN skinning oldalról.

A lokalizációval jó lenne még tenni valamit, mert jelenleg elég korlátozott a több nyelv használata.

Folyt. köv.

Az elmúlt hónapjaim nagyrészt a Microsoft Dynamics CRM bevezetésünkkel töltöm. Ennek kapcsán be kellene tölteni a partnertörzset. Az ügyviteli rendszerünkből származó adathalmaz mára többszörös tisztításon esett át. Ma rendbe akartam rakni az országkódokat, ugyanis az eredeti rendszerben sok külföldi partnerünk magyar országkóddal szerepelt.

A CRM alapvetően a címzésnél nem használ országkódokat. A saját ügyviteli rendszerünk kódjait pedig nem akaródzott használni, tekintve, hogy a kiadás sorrendjében generálódik, így nem kötődik semmihez.

Kiadó vállalat lévén, adódott, hogy a Magyar Posta országkódjait használjam. Kaptam is egy listát, ma nekiugrottam a munkának.

Az első dolog, ami szembejött, hogy Magyarország nincs rajta. Ám legyen, 0-ás nincs, önkényesen Magyarország fogja kapni a 0-át. Amint tüzetesebben nézem a listát, mit találok...

Édes arany bogaraim, 2008-at írunk.

Elkészült a legújabb elkövetményem. Ezt most remegő kézzel adom közkézre, mert ilyet még nem csináltam. Mit is? Portált. Pontosabban írtam egy programocskát (ilyen már volt) és ehhez készítettem egy web portált (ilyen még nem volt).
Ha valakit érdekel, hogyan lehet az Exchange 2007-hez ingyenesen vírusirtót fabrikálni, akkor az itt talál megoldást:
http://www.clamagent.org

Egyenlőre küzdök. Próbálok kihozni valamit a DotNetNuke-ból. Még neki sem álltam, hogy a kinézetet testreszabjam. Egyenlőre van néhány bajom van vele:

Nem találtam meg, hogy cikk jellegű információt melyik modullal tudnék kényelmesen elhelyezni. Egyenlőre sötétben tapogatózom és a Blog, a Wiki, és a külön lapokra feltett html content között vacillálok.

A lokalizáció még nem egészen tiszta nekem. Szeretném az oldal bizonyos részeit angolul és magyarul is elérhetővé tenni. Az alap rendszerben nem igazán találom ennek az értelmes megoldását. Találtam ingyenes lokalizált modulokat, fel is tettem őket, de sajnos csak nagyon korlátozottan használhatóak.

Nem találtam meg, hogy a blog motornál, hogyan lehetne elérni azt, hogy a teljes tartalom kerüljön ki mind az oldalra, mind az rss feedbe.

Addig amíg nem tudok valami értelmeset a főlapra kirakni, kiraktam annak a blognak a feedjét amit írni szoktam.

Eredetileg nem írtam ide semmit, mert a motor azt mondta, hogy "(The summary is optional, if you choose to not supply one, a short summary will be generated from your entry.)". Hittem neki. Nem kellett volna, üres lett. Szóval itt írok az okokról, hogy miért kezdtem ebbe bele.

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.

Nagyjából két éve írtam egy cikket "Bevezetés az SMTP EventSink világába rendszergazdáknak" címmel itt a honlapomon. Ez a cikk alapvetően a script író, programozó kedvű rendszergazdákat célozta meg akik a Microsoft Exchnage 2000/2003 környezetben (ide értendő a Microsoft Windows 2000/2003 IIS SMTP szervere is) valamilyen okból bele akartak nyúlni a rendszeren áthaladó e-mailekbe. Azóta a világ sokat változott és benne én is. Megjelent az Exchange 2007, ami teljesen új alapokra helyezi a Windowsos világ üzenetkezelését, valamint én is sokat tanultam, fejlődtem ebben a témakörben amit szeretnék itt és most közzétenni.
Ez a cikk tekinthető a fent említett darab 2.0-ás változatának. Tartalmazza az összes információt ami abban a cikkben megtalálható volt, továbbá sok pontosítást és kiegészítést amire az évek során jöttem rá, szedtem össze információmorzsákból. Ezen túl az Exchange 2003 oldalán átvezet a .NET világba betekintést nyújtva abba a lehetőségbe, hogy script nyelvek helyett .NET-ben írjunk SMTP eseménykezelőket, valamint átvezet az Exchange 2007 ide vonatkozó technológiai (Transport Rule-ok és a Transport Agentek) világába.
1. Bevezetés az SMTP EventSink világába
A Microsoft Exchange Server 2000/2003 és az alatta található Windows Server komponensei (IIS SMTP szerver) lehetőséget kínálnak arra, hogy a rajtuk áthaladó levelekhez programozottan hozzá tudjunk nyúlni. Ezt különböző bonyolultsággal és ebből következően különböző lehetőségekkel tehetjük meg.
Ezek közül a lehetőségek közül, először azt szeretném bemutatni ahol egy egyszerű VBScript vagy JScript kódból bele tudunk nyúlni a rendszerünkbe beérkező és onnan kimenő levelekbe.
Ehhez az Exchange által használt SMTP szerverhez kell egy beépülő modult írnunk és regisztrálnunk. Ez a modul lesz az úgy nevezett SMTP EventSink. Az SMTP levélküldés folyamatába több ponton lehet beavatkozni. Ezek közül most csak azzal az egy pontal foglalkozunk amihez script nyelven is hozzá lehet férni. Az összes pont COM eseménykezelőként érhető el, ezek közül egyhez (OnTransportSubmission vagy más néven OnArrival) készült egy script host (CDO.SS_SMTPOnArrivalSink), amit regisztrálni tudunk a saját scriptünk helyett és ennek a script hostnak adjuk meg paraméterként a végrehajtandó script nevét.
A scriptünk így fog kinézni:

eventsink.vbs

<SCRIPT LANGUAGE="VBSCRIPT">
    Sub ISMTPOnArrival_OnArrival(ByVal Msg, EventStatus)
        ' Ide kerül az EventSink kódja
 End Sub
</SCRIPT>

eventsink.js

<SCRIPT LANGUAGE="JSCRIPT">
    function ISMTPOnArrival::OnArrival(Msg, EventStatus)
    {
        // Ide kerül az EventSink kódja
    }
</SCRIPT>

Az eseménykezelőnk két paramétert kap. Az egyik egy CDO.Message objektum ami tartalmazza a teljes e-mailt. Leírása itt található: CDOEX IMessage Interface. A másik egy EventStatus nevű változó, amin keresztül jelezhetjük a rendszernek, hogy a mi eseménykezelőnk lefuttatása után a hátralévő még sorban lévő eseménykezelőket lefutassa e.
Azzal, hogy megírtuk az eseménykezelő scriptünket még nem vagyunk kész, ugyanis ezt regisztrálnunk kell az általunk kiválasztott SMTP Virtual Serveren. Erre a regisztrációra a Microsoft által írt SMTPREG.VBS script használható. Ebből a scriptből az évek során alapvetően két verzió készült. Az egyik (egyszerűbb) kiadás része az Exchange SDK Documentation And Samples csomagnak, telepítés után a C:\Program Files\Exchange SDK\SDK\Support\CDO\Scripts könyvtárban található (Ha valaki nem akar bíbelődni az egész SDK-val akkor csak magát a scriptet letöltheti innen). Ez a verzió jól használható azok számára akik kizárólag script nyelven írnak eseménykezelőt, ugyanis ezzel, csak a korábban már említett OnArrival eseményre lehet feliratkozni, ugyanakkor könnyebbséget jelent, hogy a regisztrációk listázásánál nem kapjuk meg feleslegesen az egyéb eseményekre regisztrált számtalan Exchange eseménykezelő listáját. A másik verzió ami teljes funkcionalitással használható itt érhető el, valamint a teljesség kedvéért a saját oldalamra is kiraktam ide. Abban az esetben, ha nem script nyelven írunk eseménykezelőt és nem az OnArrival eseményre szeretnénk feliratkozni mindenképp ez utóbbit kell használnunk.

Most néhány példán keresztül bemutatom az smtpreg.vbs használatát.

Meg tudjuk vele nézni, hogy jelenleg milyen eseménykezelők vannak regisztrálva:

cscript smtpreg.vbs /enum

Tudunk regisztrálni eseménykezelőt:

cscript smtpreg.vbs /add 

Nézzük meg, hogy mit is jelentenek ezek a paraméterek:

Tudunk eseménykezelőt törölni:

cscript smtpreg.vbs /remove 

Tudunk az eseménykezelőnkhöz különböző plusz paramétereket adni:

cscript smtpreg.vbs /add <Virtual Server> <Sink>
	<Név> <Eseménykezelő> <Protokol szűrő>

Ezekről a paraméterekről két fontos dolgot kell még tudnunk. Sajnos az itt beállított paraméterek lekérdezésére az általunk írt scriptekből nincs lehetőségünk (A Microsoft által írt scripting host ezeket a paramétereket nem adja át a scriptünknek). Fontos ugyanakkor tudnunk, hogy nekünk a scriptünk regisztrációjakor meg kell adnunk egy paramétert, ami a scripting host-nak mondja meg, hogy hol találja a végrehajtandó scriptet.

Minden további magyarázat helyett lássunk egy példát:

cscript smtpreg.vbs /add 1 OnArrival Disclaimer
	CDO.SS_SMTPOnArrivalSink "mail from=*"
cscript smtpreg.vbs /setprop 1 OnArrival Disclaimer
	Sink ScriptName "c:\Scripts\SMTP\disclaimer\disclaimer.js"

Ha regisztráció után elkezdjük használni az első eseménykezelőnket, meglepetten fogjuk tapasztalni, hogy az csak a bejövő leveleinkre hajtódik végre. Sem a kimenő leveleinken, sem a belső Exchange felhasználók közötti leveleken nem hajtódik végre. Ez ugye azon kliens programokból küldött levelekre vonatkozik melyek nem SMTP-t vagy Pickup könyvtárat használnak küldésre, hanem natív MAPI kapcsolaton keresztül küldik a leveleket (Outlook, OWA, OMA, stb.).
Mi ennek az oka? A jelenség ismert a Mcrosoft KB 273233 cikk foglalkozik vele részletesen. Saját tapasztalataim ugyanakkor azt mutatják, hogy az említett cikk hiányos.
Először is szeretnék eloszlatni egy tévhitet (saját magam is rosszul gondoltam jó ideig):
Az általános vélekedéssel ellentétben azok a levelek amiket egy Exchange felhasználó küld egy másik Exchange felhasználónak még abban az esetben is amikor azonos adatbázisban található a mailboxuk áthaladnak az SMTP Transporton. Ha ez így van, tehát minden levél áthalad az SMTP Transporton, akkor az eseménykezelőnk miért nem hajtódik végre a kimenő és az átmenő leveleken?
Ennak alapvetően két oka van:
1. Ezek a levelek az SMTP Szervernek csak a transport részén haladnak át és a protokol részén nem. Ezzel alapvetően még nem is lenne baj, mert az eseménykezelőnk nem az SMTP protokol utasításait figyeli, hanem azokat a leveleket amiket az SMTP szerver már teljesen átvett, tehát a transport fázisba jutottak. A gond az eseménykezelőnk regisztrációjánál van. Azokon a leveleken amik nem haladtak át a protokol szakaszon nem található meg az SMTP boríték, ezért ezeken a leveleken nem tudjuk érvényesíteni a regsztrációnál megadott protokol szabályt (pl. "mail from=*"). Sebaj mondhatnánk, akkor regisztráljunk szabály nélkül, vagy üres szabállyal. Ez nem fog működni. Az első esetben az smtpreg.vbs hibát ad, a második esetben viszont létrehozza a regisztrációt, de benne lesz a szabály (rule) üresen, így változatlanul nem hajtódik végre az eseménykezelőnk az említett leveleken. Hogyan lehet ezt kikerülni? Egyszerűen. Kicsit bele kell javítani az eredeti smtpreg.vbs-be például úgy, hogy ha üres szabályt adunk meg akkor ne is regisztrálja azt. Nem kell megijedni, nem kell megkeresni az smtpreg.vbs kódjában, hogy mibe is kellene belenyúlni, mert én ezt már megtettem. A módosított verzió letölthető innen. Ha ennek a változatnak üres rule-t adunk meg akkor nem fog rule-t regisztrálni.
2. A második probléma már keményebb dió. Itt jön be először is amit a KB cikk ír, az, hogy a rendszer eldobja azt az üzenet példányt amit nekünk mint eseménykezelőnek átadott, így a módosításaink elvesznek. A helyzet sajnos ennél sokkal rosszabb. Nem is tudunk mit kezdeni az átadott levéllel, ugyanis a levéltovábbításnak ebben a szakaszában még nem történt meg a TNEF/MIME konverzió (a TNEF az Exchange által használt belső formátum) és eszközünk sincs arra, hogy ezt scriptből megtegyük.
Ezt a problémát kétféleképpen tudjuk áthidalni. Az egyik megoldás, hogy maradunk a script nyelveknél és az SMTP Virtual Serverekkel trükközünk, a másik, hogy elhagyjuk a script nyelveket és C/C++-ban, vagy .NET-ben írjuk meg az eseménykezelőnket és azt az OnArrival helyett az OnPostCategorize eseményre regisztráljuk.
Először nézzük meg, hogyan tudjuk a kérdést megoldani az SMTP Virtual Serverek konfigurációjával. Előre kell bocsátanom, hogy ilyen módon a belső leveleket nem fogjuk tudni kezelni, csak azokat amik az Exchange-ből kifelé haladnak.
Az elv az, hogy létre kell hoznunk egy második SMTP virtual server-t és át kell irányítanunk minden levelet az első virtual server-ről a másodikra. Ezek után az eseménykezelőnket a második SMTP virtual server-re telepítjük. Ez biztosítja, hogy mire az eseménykezelőnk végrehajtódik a levél MIME formátumú legyen.
A következő lépésekben létre fogunk hozni egy második SMTP virtual servert ami a szabványos 25-ös TCP port helyett egy másik porton figyel (pl. a 26-oson) és a szabványos 25-ös porton küldi a leveleket. A default SMTP virtual server pedig a 25-ös TCP porton figyel és a 26-os TCP porton küldi ki a leveleket, amit a második SMTP virutal server fog átvenni. Alapvetően bármilyen levél halad át, annak a default SMTP virtual server-re kell megérkeznie. Ha a levél belső címre irányul akkor azt a default SMTP virtual server kézbesíti és nem halad át a második SMTP virtual serveren. Ha a levelet kifelé kell kézbesíteni akkor a default SMTP virtual server átaja a második SMTP virtual servernek.
1. Nyissuk ki az Exchange System Manager-t és navigáljunk az SMTP mappához. Ez a mappa a First Administrative Group/Servers/szerver neve/Protocols/SMTP.
2. Kattintsunk a jobb egérgombbal a mappára, majd a New menüpontra, majd az SMTP Virtual Server menüpontra.
3. Írjuk be az új virtual server nevét és nyomjuk meg a Next gombot. IP címnek adjuk meg az All Unassigned bejegyzést és nyomjuk meg a Finish gombot. Egy figyelmeztető ablakot fogunk kapni arról, hogy a szerver nem fog elindulni az ütköző IP címek és portok miatt. Ezt a figyelmeztetést figyelmen kívül hagyhatjuk. Nyomjuk meg a Yes gombot.
4. Kattintsunk jobb egérgombbal egyenként a virtual server-ekre és utána válasszuk ki a Stop menüpontot.
5. Kattintsunk jobb egérgombbal a default SMTP virtual server-re és válasszuk ki a Properties menüpontot.
6. A Delivery fülön kattintsunk az Advanced gombra. A Smart host szövegdobozba írjuk be a gépnek azt a teljes domain nevét ami pontosan a Smart host szövegdoboz fölött található, vagy a szerver IP címét szögletes zárójelbe foglalva, majd kattinsunk az OK gombra. A Delivery fülön kattinsunk az Outbound connections gombra. A TCP szövegdobozba írjuk be a 26-ot és kattintsunk az OK gombra. Kattintsunk az OK gombra a párbeszédablak becsukásához.
7. Kattintsunk jobb egérgombbal a másik SMTP virtual server-re és válasszuk ki a Properties menüpontot. A General fülön kattintsunk az Advanced gombra válaszuk ki az All Unassigned sort. Kattintsunk az Edit gombra, változtassuk meg a TCP portot 26-ra és kattintsunk az OK gombra. Kattintsunk mégegyszer az OK gombra.
8. Kattintsunk az Access fülre, majd a Relay gombra, majd adjuk hozzá az engedélyezett gépek listájához a gépünk IP címét és a 127.0.0.1-es címet. Kattintsunk az OK gombra majd mégegyszer az OK a párbeszédablak bezárásához.
9. Kattintsunk jobb egérgombbal egyenként a virtual server-ekre és utána válasszuk ki a Start menüpontot.
10. Regisztráljuk az eseménykezelőnket a második SMTP virtual serverre. Használjuk a következő parancsot:

cscript smtpreg.vbs /add 2 OnArrival PeldaOnArrivalEsemeny
	PeldaSMTPEsemeny.EsemenyInterface "mail from=*"

Vegyük észre, hogy egy 2-es áll az "/add" után ami megmondja a scriptnek, hogy a második SMTP virtual server-re regisztrálja az eseményt. Normál esetben ez 1 az első (default) SMTP virtual server-re.
Ennek a módszernek két szépséghibája van. Az egyik, hogy abban az esetben ha az Exchange szervezetben több szerver is szerepel, akkor a fenti beállítások nem elégségesek és nem is megfelelőek. Ez esetben a beállítások az Exchange routing alapos elméleti szintű ismeretét ígénylik. A másik gond, hogy ez a megoldás az eredeti Microsoft leírások szerint nem üzembiztos, ugyanis az Exchange szerver nem a Default Virtual Serveren keresztül küldi ki a leveleket, hanem azon keresztül amelyik egy rendszerindításnál, vagy a Virtual Serverek kézi indításánál/leállításánál először elindul. Zárójelben jegyezem, hogy nagyjából 5-6 éve használok ilyen módon felépített rendszert és miután a kézi indításnál/leállításnál mindíg kínosan ügyeltem arra, hogy a Default Virtual Servert indítsam el először, soha nem volt problémám abból, hogy esetleg az Exchange rossz Virtual Serveren keresztül küldte volna ki a leveleket.
folyt. köv...

Átmenetileg kiraktam az internetre a tegnapi webcast anyagát. Nem sokára a Microsoft oldalán is meg fognak jelenni ezek a fájlok.
 
Powerpoint Prezentáció:
http://www.it-pro.hu/Default.aspx?tabid=95&id=60
Powerpoint Demo:
http://www.it-pro.hu/Default.aspx?tabid=95&id=61
Előadói megjegyzések (pdf):
http://www.it-pro.hu/Default.aspx?tabid=95&id=62

Lassan jönnek a scriptek is, csak az egyiken még kicsit fényezek.
 
[Update 2006/09/22 16:53]
Kiraktam a scripteket is végre:
http://www.it-pro.hu/Default.aspx?tabid=95&id=63 
[Update 2006/09/25 16:16]
Kikerültek az anyagok a Microsoft weboldalára. Mostmár a Webcast felvétele is kint van:
http://www.microsoft.com/hun/webcast/default.aspx?id=07c01307-e5b7-4918-bd40-d6e6a6d16011

Tegnap megtartottam a mentésről és visszaállításról szóló webcastomat. A visszajelzések szerint nem volt csúfos bukás a dolog ugyanakkor én nem vagyok elégedett magammal.
Ma reggel megint bejött: egy Murphy nevezetű alak összes fel és lemenőinek folyamatos emlegetésével kezdtem a napot.
Előzmény:
Úgy két hete az egyik szerverünk RAID-jében kikönyökölt az egyik vinyó. Ki is cseréltem valamire amit épp a fiókban találtam, újra is építette, de a fiókból berakott disk-et nem akartam véglegesen bennehagyni, ráadásul némi kapacitás bővítés is ráférne az egyedre így megrendeltem egy teljes garnitúra új vinyót, melyek meg is jöttek.
Ma reggel 9 körül:
Lementem a szerver szobába, hogy elkezdjem egyesével kicserélni a disk-eket amit ugyebár on-line meg tudok tenni. Valamit meg akartam nézni a gépben belül ezért kihúztam a rackből. Figyelmetlen voltam, túl rövid volt a 230-as kábel így a gépet sikerült áramtalanítani. Amikor visszakapcsoltam egy kék képernyős nemindulással fogadott (gratula Murphy).
Na boldog vagyok, kipróbálhatom, hogy én mennyire vagyok jó abban amiről tegnap dumáltam.
9:23:
Először is ASR kilőve. Az előadásban sem beszéltem róla, mert nem használom és időm sem volt foglalkozni vele (úgy látom mindenképp utána kell néznem)
Gép boot CD-ről, Recovery Console elindít. Ez az a dolog amit a büdös életben nem használtam. Rájöttem, hogy ma sem fogom. Se az AD Admin jelszavát, se az AD Recovery Admin jelszót nem fogadja el (ja nem mondtam még, a gép hogy könnyítsünk a helyzeten egy DC).
9:46:
Megpróbálom a CD-ről a telepítsünk és reparáljunk opciót. Sok bizodalmam nincs benne, mert nekem még sosem működött (nagy gáz persze nincs, mert legrosszabb esetben újratelepít az egész és mentésből visszatölt. Ez sem tarthat sokáig, mert ugye disk nem sérült és éles szerveren mindig külön tartom a boot partíciót, így csak a c-t kéne visszatölteni).
10:18:
Csoda történt. Egyszer az életben működött a repair. Elindult az egész.
10:32:
Települnek újra a biztonsági hotfixek.
11:06:
Hotfixek fenn, újraindulunk.
11:16:
Működik a dolog. Most nekikezdek a vinyócserének.

A hét eleje óta napja nem megy a weboldalam. Csak most vettem észre mert az elmúlt időszakban se web oldalt reszelni, se fejleszteni nem volt időm. Ma átraktuk Subicz Peti segédletével egy másik szerverre, remélem, hogy működni fog. Egyenlőre azt várom, hogy a DNS bejegyzés replikálódjon.

Megjelent az Office 2003 SP2
Letöltés itt:
http://www.microsoft.com/downloads/details.aspx?familyid=57e27a97-2db6-4654-9db6-ec7d5b4dd867&displaylang=en

Ilyet nem szoktam írni, de mostmár piszokul bosszant. Ismét rájöttem, hogy az internet szolgáltatónk a T-Offline (http://www.domain.hu/domain/domainsearch/?domain=t-offline&tld=hu). Megint nincs netünk, bérelt vonalon rengeteg pénzért. Unom. (Ezt a PDAmról írom)

Ma elszórakoztam egy rég problémám megoldásával. Az oldalamon két helyen is használtam a WMI repositoryba fordított mof fájl olyan eseménykezelőkhöz amik a rendszer újraindítása után is tovább működnek:
http://www.gomori.hu/elog_db_hu.htm
http://www.gomori.hu/storesize_hu.htm
Felmerült az a kérdés, hogy mi van akkor, ha el szeretnénk távolítani az így regisztrált eseménykezelőt. Eddig csak egy Microsoft WMI adminisztrációs eszközzel, kézzel tudtam eltávolítani. Most elkövettem egy eszközt ami képes ezt eltávolítani. Majd később az oldalra is ki fogom rakni. Ez a fentiek közül az elsőhöz készült.
A kód innen tölthető le