Author: SUF

Exchange 2010 OWA – Kép az aláírásban 2.

Most jön az, hogy hamut szórok a fejemre. Az előző cikk tesztjei során valamit nagyon benéztem.

Ami nem működik:

Attól, hogy egy megbízott tanúsítvánnyal aláírt oldalról érkezik a kép, az Outlook még nem fogja megjeleníteni.

Ami viszont működik:

Ha az OWA kliensen ahonnan a levelet küldjük feltelepítjük az S/MIME bővítményt, akkor az aláírásban elhelyezett kép beágyazott képként belekerül az elküldött levélbe így az Outlook meg fogja jeleníteni. A képet ehhez a mutatványhoz is egy megbízott SSL oldalon kell elhelyezni, viszont ehhez jó a saját tanúsítványunk is mert ebben a fogadó oldalnak nem kell megbíznia, a feladónak viszont, igen, hogy be tudja ágyazni a képet.

Ezzel a kérdés meg is lenne oldva, de mi történik, ha nem csak saját magunknak szórakozásból csinálunk ilyet, hanem cégesen több száz gépen kell az S/MIME-ot telepíteni?

Az S/MIME OWA kiterjesztés tulajdonképpen egy IE bővítmény, ami MSI alapú telepítővel rendelkezik. Ez az Exchange szerveren alapból a C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\smime könyvtárban owasmime.msi néven szerepel. Ezt ki tudjuk tolni Group Policy-ból az érintett kliensekre. Ezzel ugyanakkor még nem vagyunk meg, mert a bővítmény nem kerül automatikusan engedélyezésre. Ahhoz, hogy engedélyezzük a Group Policy User Configuration/Policies/Administrative Template/Windows Components/Internet Explorer/Security Features/Add-on Management alatt fel kell venni a {3050F819-98B5-11CF-BB82-00AA00BDCE0B} kulcsot, 1-es értékkel. Ez engedélyezik a bővítmény használatát.

Exchange 2010 OWA – Kép az aláírásban

Ha körülnézünk kicsit a neten akkor a címben szereplő dologról azt olvashatjuk, hogy  az Exchange beépített lehetőségeivel nem megvalósítható, vagy ha igen akkor körülményes és nem lesz teljeskörű a megoldás.

Megnyertem feladatként, hogy oldjam meg.

Első felvonás – google félmegoldások

Az interneten található félmegoldások egy weboldalra kirakott kép copy/paste-el való beillesztéséről szólnak. Ilyenkor ne tévedjünk nem a kép fog a levélbe bekerülni, hanem a kép linkje. Némelyik „megoldás” még azt a remek ötletet is elköveti, hogy küldjünk magunknak egy képet, majd az OWA-ba érkezett levélből copy/paste. Ez azért ÓRIÁSI ötlet, mert ezesetben a levél OWA-s linkje kerül bele az aláírásba ami a saját postaládánkra mutat amihez ugye senki sem akarja a címzettnek odaadni a hozzáférést.

Ok. Szóval tegyük ki a képet egy publikus oldalra, illeszük be a képet az aláírásba és már működik is. Mi ezzel a baj?

A HTML levélbe egy kép két módon kerülhet bele:

Külső oldalra oldalra mutató hivatkozásként. Mint esetünkben is.

A levélhez csatolt MIME part-ként (csatolmányszerű dolog) amire a HTML forrásból egy CID-val hivatkozunk.

Az első esetben, ha a levelet Microsoft Outlookban olvassuk, akkor az Outlook biztonsági okokból le fogja tiltani a képhez való hozzáférést mert nem megbízható oldalra vonatkozik a hivatkozás. Ez nekünk nem jó.

A második eset lenne jó, viszont ezt az OWA-ból nem tudjuk kikényszeríteni.

Második felvonás – nyomozzunk

Trükközzünk kicsit a HTML-el. A kép HTML tagje alapvetően így néz ki: <img src=”link” />. Ebbe be lehet ágyazni képet. Ez valami ilyesmi lesz: <img src=”data:image/jpeg,base64,a kép base64 kódja” />. Ha ezt rakjuk az OWA-ba (ez már copy/paste-el nem fog menni, csak EWS-ből kóddal) akkor a beállítások között szépen meg is jelenik a kép, de amikor egy levelet írunk már nem jelenik meg. Elküldve sem jó.

Harmadik felvonás – programozunk?

Megtehetném, hogy az img tagbe beteszek egy plusz spec attributumot, remélve, hogy az owa nem szedi ki, majd egy Transport Agentből a spec attributumos img-eket átalakítom CID-ra, de ez nem kevés munka. Talán majd egyszer.

Negyedik felvonás – megoldás pénzért

Gondolkozzunk fordítva. Mi kell ahhoz, hogy egy Outlook egy külső web oldalról származó képet megbízhatónak minősítsen? Vagy benne kell lennie az IE Trusted Zone-ban lásd: https://www.emaildetektiv.hu/2009/11/24/hianyzo-kepek/, vagy SSL oldalról kell származnia aminek a Root CA-jában a windows megbízik. Az első eset nem járható, hiszen a címzetteinket nem tudjuk arra kényszeríteni, hogy a weboldalunkat berakják a Trusted Zone-ba. Ha saját CA-t használunk (mint én a legtöbb esetben) az általa kiadott SSL tanusítvány szintén nem lesz jó, hiszen a saját CA tanúsítványa nincs rajta a Microsoft féle Trusted Root Certification Authorities listán. Nem marad más hátra, mint az, hogy veszünk valahonnan egy tanúsítványt, építünk egy SSL weboldalt, kirakjuk oda a képeket és ezeket használjuk az aláírásban. Ez működik, de pénzbe kerül, a tanúsítvány éves díjába.

Ötödik felvonás – a felhő ereje

Hogyan lehetne mégis kikerülni, hogy  pénzbe kerüljön ez a történet? Vannak ugye olyan szolgáltatók akik ingyen adnak valamennyi tárhelyet egy felhő alapú megoldásban. Ezekhez a tárhelyekhez, tipikusan van web alapú hozzáférés. Ez a web alapú hozzáférés titkosított kell legyen, hiszen a magán dokumentumainkat tároljuk rajta. Az ilyen szolgáltatók természetesen olyan Root CA-tól veszik a tanúsítványaikat aki fenn van a Microsoft listáján. Továbbá ezek a szolgáltatások tipikusan kínálnak publikus fájl elérést is.

Rakjuk ezt össze:

Gyártunk egy dropbox accountot. (Elég lesz az ingyenes 2GB tárhely az email aláírás beágyazott képének? Asszem.) felrakjuk a kliensét. Bedobjuk az aláíráshoz szükséges képet a Public mappába. nyomunk az explorerben egy jobb egérgombot a képfájlon, majd a menüből: Dropbox -> Copy public link. Amit kapunk, bedobjuk az IE-be, kicseréljük a http-t https-re, enter és már meg is jelent a kép a böngészőben. Képen jobb egérgomb, másolás, az owa aláírásmezőjében beillesztés és kész is vagyunk.

Nincs ingyen tanúsítvány, csak nem te fizeted.

Mathematics by Exchange: Unlimited = 5MB

Exchange migráció közepén vagyunk. Lassan gyűlnek a fejemben a cikkek, amiket meg kellene írni. Íme az első:
Egy felhasználó jelezte, hogy az OWA-ból nem tud 5MB-nál nagyobb levelet csatolni.

Ezen elcsodálkoztam. Sehol sem állítottam be 5MB korlátot a rendszerben. A ki- és bejáratokon 20MB limit van.  A felhasználóknál nem állítottam semmit így a szervezet beállításait öröklik, a globális beállításokat pedig kivettem (hogy miért, arról majd egy másik cikkben írok), tehát itt “Unlimited” a beállítás.
Megnéztem az Outlookban. Itt tudok nagyobb csatolmányt felvenni, tehát kell lennie valami külön az OWA-ra vonatkozó beállításnak. Elkezdtem keresgélni és találtam is valamit:

http://technet.microsoft.com/en-us/library/aa996835.aspx

Itt lehet állítani a limitet, de itt a gyári beállítás (és az én rendszeremben is) 35MB. Ez tehát nem okozhatja a problémát. Némi keresgélés után telefon Józsinak, hátha ő tud valamit. Tőle annyi infót kaptam, hogy az egyik kollégája belefutott már ebbe, volt is rá megoldás, de nincs meg, hogy mi.

Keresgélek tovább. Ráakadtam erre a cikkre:

http://www.exchange-genie.com/2009/09/when-unlimited-is-not-unlimited/

Szóval érdekes az Exchange matematika.

Ezek után a globális beállításokon beállítottam valami óriási méretet. Ez még önmagában nem oldotta meg a dolgot, de egy IIS újraindítás segített.

Mi lesz veled ActiveSync?

Ma olvastam egy hírt:
“A RIM kezébe került a DataViz”

Azt gondolom, hogy egy átlag Exchange rendszergazda jó eséllyel átsiklik felette. Nálam viszont megkongatta a vészharangot. Miért?
Először is a két cégről:
RIM: gondolom mindenki ismeri őket. Aki mégsem annak a BlackBerry név biztosan ismerősen hangzik. Ez a cég aki a BlackBerry-t, a hozzá tartozó operációs rendszert és szoftvereket gyártja. Valamint ő a (jelenleg az Exchange ActiveSync-ben is használt) Direct-Push szinkronizációs technika atyja.
DataViz: Egy jóval kevésbé ismert cég. Mobil szoftver fejlesztő társaság. Gyártanak kliens szoftvert az Exchange ActiveSync-hez.

Az Exchange ActiveSync ugye egy a Microsoft által fejlesztett szinkronizációs technika, ami eljuttatja a szerveren tárolt adatainkat a mobiltelefonunkra. Microsoft fejlesztésben csak a Microsoft Windows Mobile operációs rendszert használókra. Ezt a többi platformra úgy tették elérhetővé, hogy különböző cégek megvásárolták a technológia licenszét. Ebből született pl. az iPhone 2.0 exchange kapcsolata, vagy a Nokia Mail for Exchange-e. Ez szép, de mi van azokkal a készülékekkel, amelyeket nem a Nokia vagy az Apple gyárt?

Itt jön a képbe a DataViz. Van nekik egy RoadSync nevű termékük. Ez, talán mondanom sem kell, egy ActiveSync kliens. Ebből viszont egy kitüntetett darab. Azok a cégek, ugyanis akik nem vették a fáradságot, hogy saját klienst fejlesszenek, szinte kizárólag e termék licenszének megvásárlásával jutottak ActiveSync klienshez. Így lett Exchange kapcsolat a Sony-Ericsson, az LG, a Samsung készülékein. Ezen túl a terméket még külön is árulják azokra az eszközökre, amelyeken nincs előre telepítve.

Ez a felvásárlás számomra kicsit kétségessé teszi a jövőt. A RIM-nek véleményem szerint nem érdeke a RoadSync termékvonalat tovább vinni, következő okból:
Ha nincs széles támogatottsága az ActiveSyncnek akkor a nagyvállalatok könyebben választják a RIM szinkronizációs megoldását. Ezzel több készüléket és több BlackBerry Enterprise Server-t lehet eladni.

ClamAgent & ClamSink

Amiről már rég írnom kellett volna.

Lassan másfél hónapja tetszhalott állapotából felélesztettem az Exchange-re szabott ingyenes vírusirtómat. Az új darab ugyan csak build számban tér el a régitől, mégis nagy lépés előre.

– ClamD használata. A korábbi verzió a ClamWin-t használta, mint motort. Ez azt jelentette, hogy minden egyes beérkezett csatolmányt lementett a temp könyvtárba, majd elindította rá a clamwin-t. A clamwin felolvasta a saját adatbázisát, majd a tempből a fájlt. Ez a műveletsor, mint látható igencsak disk intenzív ügy. A jelenlegi verzió ezzel szemben a csatolmányt egy TCP csatornán keresztül áttolja a ClamD-nek ahol megtörténik a vírus ellenőrzés. Ráadásul a ClamD csak időnként olvassa fel az adatbázist.

– MSI telepítő. A korábbi verzió kézi telepítése sem volt egyszerű. Ennél a verziónál ez már mintegy tizenöt lépés lenne a kézi telepítés ezért inkább készítettem egy msi-t ami tartalmazza a clamd-t a szükséges futtatókörnyezeteket, beállításokat.

– Pici hibajavítás. Az Exchange 2007 verzió 2010 alatt futtatva egy .NET osztály nevét írja a logba az értéke helyett. Egyébként az Exchange 2007 alatt is produkálja ugyanezt a hibát SP3-tól.

– Támogatás az Exchange 2010-hez. Lényegében nincs sok különbség a 2007-es és a 2010 verzió között, csak a 3.5-ös Frameworkre fordítottam és a 2010 transport dll-jeit használtam. A lényegi különbség a telepítő, ugyanis a 2007 és a 2010 másképp intézi a powershell plug-in-jeit így másképp kell telepíteni.

Folytatás következik (vannak még ötleteim). A cucc letölthető a clamagent.org-ról némi regisztráció után

Javítsuk meg a semmit

Linux tűzfalat használok (jujj, de ez egy Exchange blog). Évek óta bosszant az Exchange Server Event Logban ez a bejegyzés.

Ha van egy mobil eszközünk, ami az ActiveSync for Exchange-el direct push módban beszélget akkor a kliens nyit egy TCP kapcsolatot a szerver felé, a szerver pedig jó sokáig hagyja várakozni a klienst. Némelyik tűzfal ebbe beleun és lekapcsolja a villanyt idő előtt. Ha ez megtörténik, akkor pakolja a fenti kedves üzenetet az Exchange a logba.

Két lehetőségünk van:

1. Megmondjuk az Exchange-nek, hogy ne várjon addig. Ezt a Program Files\Microsoft\Exchange Server\ClientAccess\Sync\web.config fájlban található heartbeat bejegyzések módosításával érhetjük el. Pontosabban ezekről beszélek: MinHeartbeatInterval, MaxHeartbeatInterval, HeartbeatSampleSize, HeartbeatAlertThreshold

2. Csökkenteni a heartbeat értékeket mégsem célravezető. Inkább a csomagok útjában álló tűzfallal kéne tudatni, hogy várjon vagy 30 percet (ez a Microsoft ajánlás)

Térjünk vissza a linuxhoz. A linuxon az ide tartozó bejegyzések a /proc/sys/net/ipv4 alatt találhatóak. Próbáltam kideríteni, hogy melyekhez kellene hozzányúlni. Végül is találtam erre vonatkozóan egy cikket.

Puff neki, ezek szerint a linux vonatkozó timeout-ja három nap (ennyit a 30 perces ajánlásról). Végig is néztem a sajátom beállításait, és valóban.

Akkor ki a tettes? Láthatóan mostmár senki. Július 5.-e óta megszűntek a bejegyzések. Valaki észbekaphatott valamelyik a mobilok és a tűzfal közötti szolgáltatónál és állítottak valamit.

Probléma lezárva.

Cache vagy nem Cache, ez itt a kérdés

Van egy kis bajom az Exchange szerverünk sebességével.

Az egyik gyanúsítottam, hogy néhány kliens nem Cached Mode-ban használja az Outlookot és ez terheli a szervert. Át kéne őket állítani.

Itt jön a kérdés, hogy melyeket. Hogyan tudjuk kideríteni, hogy mely klienseink mennek Online módban?

Így:

Get-LogonStatistics | Where-Object { $_.ClientMode -eq “Classic” } | ft -Property UserName,ClientMode

Hiányzó képek

A biztonság jó dolog.

Csak épp néha piszokul bosszantó.

Vegyük elő kedvenc Outlookunkat és tapasztalni fogjuk, hogy a beérkezett levelek egy jó részében nincsenek képek, csak egy kék figyelmeztető sáv, hogy ha akarjuk, akkor letölthetjük a képeket, de ez biztonságilag kockázatos.

Miért van ez így? Miért van az, hogy bizonyos levelekben vannak képek és bizonyos levelekben nincsenek?

A HTML formátumú levelekbe a képeket két módszer szerint tudjuk berakni.

Az egyik az úgy nevezett Online HTML. Ebben az esetben a levélben van egy img tag, aminek az src attributuma egy web szerveren tárolt képre mutat. Ennek a megoldásnak az az előnye, hogy az elküldött levél maga viszonylag kicsi lesz, mert a képek nincsenek benne. További előny, hogy a küldő tud a háttérben statisztikát vezetni arról, hogy az adott levelet megnyitották-e (ha letöltötte a címzett a képet, akkor megnyitotta a levelet). Előny lehet még a feladó számára, hogy a képet utólag is tudja módosítani*. Ennek a megoldásnak vannak hátrányai is. Az Outlook az ilyen levelekre rakja fel a fent említett kék csíkot és nem tölti le a képeket. Ha valamiért a címzett, vagy a küldő web szervere offline, akkor nem tudunk hozzáférni a képekhez.

A másik az Offline HTML, amelyben az img tag src attributuma egy cid bejegyzést tartalmaz ami a levélben magában lévő rejtett csatolmányra mutat. Ez tartalmazza a képet magát. Előnye, hogy mindig elérhető a címzett számára, az Outlook nem szűri ki, ugyanakkor hátránya, hogy nagyméretűek lesznek a levelek tőle.

Vajon az Outlook miért szűri ki az első levél típusban szereplő képeket?

Mert ez a gépre nézve potenciális támadást is hordozhat. Az elmúlt években több olyan sérülékenység is napvilágra került, amit a Windows képfeldolgozó motorjában találtak és speciálisan formázott képfájlal kihasználhatóak voltak. Tehát, ha nem töltöm le a képet, akkor nem tud kárt okozni.

De engem zavar, hogy állandóan kézzel kell letöltenem a levelet. Ki lehet kapcsolni?

Igen, de nem érdemes, az ok az előbb taglalt biztonság.

Jó, de akkor mi a megoldás? Hogyan lehetne elérni, hogy azoknál a leveleknél, amiknél én szeretném automatikusan letöltődjenek a képek (pl. rendszeres, olvasott hírlevelek).

Erre van megoldás. Ha megnézzük az Outlook biztonsági beállításai között találunk egy ilyet:

 Trusted Zone

Bekarikáztam a lényeget. Tehát, ha a kép forrását berakjuk az Internet Explorer Trusted Zone-ba akkor a képet automatikusan le tudjuk tölteni.

Ok. Akkor rakjuk be. Na, ezzel lesz némi gond. Nincs olyan gomb, menü, valami az Outlookban, ami ezt megtenné nekünk. Ha van egy levelünk, aminek a linkjeit használni szeretnék, akkor szükségünk lenne a levél HTML forrására, hogy ki tudjuk másolni a megfelelő linket. Sajnos ezzel sem rendelkezünk, ugyanis ezt az  Outlook eldugja előlünk.

Mit tehetünk? Programozunk.

Írtam egy pici Outlook makrót, ami beköltözik a levél context menüjébe és ha ott rábökünk a Trust Picture Source menüpontra, akkor a levélben (vagy levelekben) lévő img src attributumokból kibogarássza a web oldalak címeit és berakja őket a Trusted Zone-ba.

A dolog működik, csak egyetlen szépséghibája van. A működés eredménye, csak az Outlook újraindítása után látható. A kód Outlook 2007-en működik (a korábbiakon nem).

Akkor rakjuk fel!

Nyissunk az Outlookban egy VBA ablakot (Alt+F11) A ThisOutlookSession-on jobb egérgomb, View Code.

Ide másoljuk be ezt:

Option Explicit
Private TrustPictureContextMenus As TrustPicturesMenu
Private WithEvents objOL As Outlook.Application
Private Sub Application_Quit()
    Set TrustPictureContextMenus = Nothing
End Sub
Private Sub Application_Startup()
    Set TrustPictureContextMenus = New TrustPicturesMenu
End Sub

Ezek után a Class Modules ágon jobb egérgomb, Insert/Class Module. Majd a keletkezett modult nevezzük át TrustPicturesMenu-re.

A kód ablakba pedig rakjuk be ezt:

Option Explicit
Private WithEvents objOL As Outlook.Application
Private WithEvents objTrustPictureButton As Office.CommandBarButton
Private Sub Class_Initialize()
    Set objOL = Outlook.Application
End Sub
Private Sub objTrustPictureButton_Click(ByVal Ctrl As Office.CommandBarButton, CancelDefault As Boolean)
    Dim RE As Object, REMatches As Object
    Set RE = CreateObject("vbscript.regexp")
    With RE
        .MultiLine = False
        .Global = True
        .IgnoreCase = True
        .Pattern = "<img\b[^>]*src=""(https?)://([^/]*)[^""]*""[^>]*>"
    End With
    ReDim Sites(1, 0) As String
    Dim objItem
    Dim SiteFound As String
    Dim ProtocolFound As String
    Dim SiteInArr As Boolean
    Dim SiteMatch
    Dim Site
    Dim i
    For Each objItem In objOL.ActiveExplorer.Selection
        Set REMatches = RE.Execute(objItem.HTMLBody)
        For Each SiteMatch In REMatches
            SiteFound = LCase(SiteMatch.SubMatches(1))
            ProtocolFound = LCase(SiteMatch.SubMatches(0))
            SiteInArr = False
            For i = 0 To UBound(Sites, 2)
                If Sites(0, i) = SiteFound And Sites(1, i) = ProtocolFound Then
                    SiteInArr = True
                    Exit For
                End If
            Next
            If Not SiteInArr Then
                If Sites(0, UBound(Sites, 2)) <> "" Then
                    ReDim Preserve Sites(1, UBound(Sites, 2) + 1)
                End If
                Sites(0, UBound(Sites, 2)) = SiteFound
                Sites(1, UBound(Sites, 2)) = ProtocolFound
            End If
        Next
    Next
    Dim DomainPartArr
    Dim HostPart As String
    Dim DomainPart As String
    Dim j, k
    For i = 0 To UBound(Sites, 2)
        DomainPartArr = Split(Sites(0, i), ".")
        DomainPart = ""
        HostPart = ""
        For j = 0 To UBound(DomainPartArr) - 2
            HostPart = HostPart + DomainPartArr(j)
            If j < UBound(DomainPartArr) - 2 Then
                HostPart = HostPart + "."
            End If
        Next
        For k = j To UBound(DomainPartArr)
            DomainPart = DomainPart + DomainPartArr(k)
            If k < UBound(DomainPartArr) Then
                DomainPart = DomainPart + "."
            End If
        Next
        RegKeySave "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\" _
                    & DomainPart & "\" & HostPart & "\" & Sites(1, i), 2, "REG_DWORD"
    Next
End Sub
Sub RegKeySave(i_RegKey As String, i_Value, Optional i_Type As String = "REG_SZ")
    Dim myWS As Object
    Set myWS = CreateObject("WScript.Shell")
    myWS.RegWrite i_RegKey, i_Value, i_Type
End Sub
Private Sub objOL_ItemContextMenuDisplay(ByVal CommandBar As Office.CommandBar, ByVal Selection As Selection)
    Dim objItem As Object
    Dim blnFoundItem  As Boolean
    Dim objCBB As Office.CommandBarButton
    For Each objItem In Selection
        If objItem.Class = olMail Or objItem.Class = olPost Then
            blnFoundItem = True
            Exit For
        End If
    Next
    If blnFoundItem = True Then
        Set objCBB = CommandBar.Controls.Item(1)
        objCBB.BeginGroup = True
        Set objCBB = CommandBar.Controls.Add(msoControlButton, , , , True)
        objCBB.Style = msoButtonWrapCaption
        objCBB.Caption = "Trust Picture Source"
        objCBB.BeginGroup = True
        Set objTrustPictureButton = objCBB
    End If
End Sub

 Mentsük el az egészet.

Ezek után, már csak a kód biztonsági beállításokat kell megtennünk, hogy a dolog működjön (digitális aláírás, miegymás 🙂 )

Használata:

Odanavigálunk kiszemelt levelünkhöz, nyomunk rajta egy jobb egérgomot és…

Context Menu

 * Erről van egy történetem. Van egy ismerősöm, aki az egyik magyar banknál dolgozott biztonsági szakértőként. Egy spammer banda az ő bankjuk nevében küldött megtévesztő leveleket (phishing). A rosszfiúk elkövették azt a hibát, hogy Online HTML levelet küldtek, amiben a logo a bank honlapjára mutatott. Az ismerősöm fogta magát és kicserélte a logót a honlapon egy figyelmezetésre, melyben jelezte, hogy a levél hamis és a tartalmát senki se vegye figyelembe.

Exchange 2010 Beta

Megjelent a következő Exchange első publikus beta verziója, amiről bővebben itt olvashatunk.

Ezzel együtt megjelent a hozzá tartozó nyelvi csomag, ami innen tölthető le (ez nem a Unified Messaging nyelvi csomagja). Ezentúl még két érdekes dolog került ki a Microsoft új nyitott kommunikációs stratégiájának jegyében:

A teljes protokol dokumentáció

És a felhasznált kommunikációs szabványok dokumentációja

Én a fenti csomagból személy szerint egyetlen dolgot hiányolok ebben a pillanatban. A 32bites verziót. Ma már egyre kevesebbeknek okoz ez fejfájást, ugyanakkor aki desktop gépen virtuális környezetben szeretne az új Exchange-el ismerkedni, annak még ma sincs igazán lehetősége a 64bites platform használatára.

Event Sink -> Transport Agent, vagy mégse

A Technet fórumon volt egy kérdés ami egy Outlook hibára vonatkozott (megosztott postafiókban a jogosult nem látja a privátnak jelölt levelet még akkor sem, ha ezt megengedtük neki). A környezet Exchange 2003. Egy megoldási javaslatként (vagyis inkább a hiba megkerüléseként) feldobtam, hogy írok egy Event Sink-et ami leveszi a megosztott postafiókba beeső levelekről a privát jelzést.

Útközben kiderült, hogy éppen Exchange 2007-re migrálnak. Ó, semmi gond, akkor nem Event Sink-et írunk, hanem Transport Agent-et. Vagy mégsem?

Az Exchange 2007-ben létezik a Transport Rule intézménye. Meg lehet oldani a fenti problémát ezzel?

Próbáljuk meg!

Itt van az a EMS Script ami a megoldást adja:

$DGOU = "test.local/Users"
$NoSensitiveDGName = "No Sensitive Message"
$NoSensitiveDGAccount = "nsdg"
New-DistributionGroup -Name $NoSensitiveDGName -OrganizationalUnit $DGOU -SAMAccountName $NoSensitiveDGAccount -Type "Distribution"
$condition = Get-TransportRulePredicate SentToMemberOf
$condition.Addresses = @(( Get-DistributionGroup $NoSensitiveDGName ))
$action = Get-TransportRuleAction RemoveHeader
$action.MessageHeader = "Sensitivity"
New-TransportRule -Name "RemoveSensitivity" -Conditions @($condition) -Action @($action) -Enabled: $true

Az eredeti feladatnál kicsit tovább mentem. a fenti script létrehoz egy disztribuciós listát. Aki ennek a listának a tagja lesz annak a bejövő leveleiről lekerül a privát jelzés (valamint a Personal és a Confidential is).

A fenti feladat kapcsán eszembe jutott egy régi Event Sink. Karsai Peti írta valamikor a távoli múltban. Ez a Sink képes Exchange 2003 alatt leszedni a levelekről az olvasási értesítőt, ami sokakat zavar.

Kicsit átírtam az előző EMS scriptet, így alkalmas lett olvasási értesítők eltávolítására. Természetesen ez is egy disztribúciós lista tagsággal kontrollálható:

$DGOU = "test.local/Users"
$NoReceiptDGName = "No Read Receipt"
$NoReceiptDGAccount = "nrr"
New-DistributionGroup -Name $NoReceiptDGName -OrganizationalUnit $DGOU -SAMAccountName $NoReceiptDGAccount -Type "Distribution"
$condition = Get-TransportRulePredicate SentToMemberOf
$condition.Addresses = @(( Get-DistributionGroup $NoSensitiveDGName ))
$action1 = Get-TransportRuleAction RemoveHeader
$action1.MessageHeader = "Disposition-Notification-To"
$action2 = Get-TransportRuleAction RemoveHeader
$action2.MessageHeader = "Read-Receipt-To"
New-TransportRule -Name "RemoveReadReceipt1" -Conditions @($condition) -Action @($action1) -Enabled: $true
New-TransportRule -Name "RemoveReadReceipt2" -Conditions @($condition) -Action @($action2) -Enabled: $true

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

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.

Exchange kívánságlista

Új évet kezdtünk. Én az új évvel egyetemben elkezdtem a régi saját blogom költöztetését. Miután a régi cikkeimen módosítani is akarok, nem egyben pakoltam át mindent, hanem a bejegyzéseket átnézve egyesével rakosgatom át.

Ennek kapcsán belefutottam egy régi cikkembe:

http://www.it-pro.hu/Blogs/tabid/94/EntryId/22/Exchange-kivansaglista.aspx

Ez egy amolyan óhaj lista volt, hogy én mit látnék szívesen az akkor még E12 kódnéven futó jelenleg Exchange 2007 néven létező termékben. Ma, az Exchange 2007-et ismerve, az E14-et várva újra arra adnám a fejem, hogy összeállítsak egy kívánságlistát.

A régi vágyaim:

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

Erről nem tudom, hogy megvalósult-e mert az elmúlt időszakban nem foglalkoztam az OWA testreszabásával. Annyi biztos, hogy ASP.NET lett belőle, valamint webpart-okat használ, így gyanítom, hogy egyszerűbben lehet hozzányúlni.

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

Valóban nem valósult meg, sőt, a következő verzióban sem fog bekövetkezni. Azt az információt kaptam róla, hogy a jelenlegi SQL típusú adatbáziskezelők egyszerűen nem alkalmasak az itt ellátandó feladatra, ebből következően nem óhajtják megfizetni azt a teljesítménycsökkenést, mint árat, amit az átállás okozna.

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

Ez meg is valósult, meg nem is. Az SMTP szerver megszűnt scriptelhető lenni, ugyanakkor a programozói felületét közelebb hozták egy olyan botcsinálta kóderhez, mint amilyen én vagyok. Az egész motor .NET-ben programozható.

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

Ennek sajnos nyomát sem látom. Az igény még mindig fent áll, jó lenne, ha a következő verzióban történne valami. Ezt újra felteszem a listámra.

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

Hát ez az egész kérdés megváltozott, hogy úgy mondjam okafogyottá vált. A programozói felületek átmentek .NET-be, Web Service-ekbe, a management felületek pedig PowerShell-be.

Ennyit a múltról. Most jöjjön a jövő. Mit szeretnék a következő verziótól:

– Először is a fentiekből származtatva: A több Exchange e-mail címmel rendelkező felhasználók kezelése.

– Jogosultság kezelés az OWA felületen. Ez talán az egyik legnagyobb hiányossága a webes felületnek az Outlookhoz képes.

– Nem egészen Exchange, de szorosan kapcsolódik: egy normális html viewer/editor az Outlookba. A jelenlegi Word-os verzió egy katasztrófa. Erről bővebben itt: https://www.emaildetektiv.hu/2008/09/11/outlook-2007-es-a-html/

– Jogosultság kezelés a grafikus management felületen (EMC). Ami jelenleg van, az igen gyenge.

– Natív import/export megoldás a store-hoz (ez az import-mailbox, export-mailbox a kötelező 32 bitjével és kötelező telepített Outlookjával egy vicc)

– Normális, egyszerű, API felület a MAPI-MIME (TNEF-HTML) konverzióhoz. A jelenlegi állapot nem egészen kielégítő. Ezt a konverziót belül az Exchange maga megoldja automatikusan, ugyanakkor, ha API-n keresztül ez nem érhető el.

Nekem így hirtelen ennyi jutott eszembe magamtól.

Kéretik kommentezni, megköpködni, kiegészíteni!!!

Exchange 2007 – első adatbázis törlése

Két hete volt egy rendszerátállásunk. Mintegy háromszáz felhasználó költözött egy hétvégén Windows Server 2003/Exchange 2003-ról Windows Server 2008/Exchange 2007-re.

A költözés mondhatni sikeresen, láthatóan buktatók nélkül zajlott le. Két nappal az átállás után a helyi informatikus hívott, hogy valami (azóta is relytéjes) okból elkezdett nőni az Exchange adatbázis mérete 100% processzor terhelés mellett úgy, hogy közben senki sem dolgozott. Sikerült óránként kb. 10GB-ot hozzátenni az adatbázishoz.

Az Event Log-tól nem lettem okosabb és miután még igazán fontos adatok nem kerültek az adatbázisba megkockáztattam a gép teljesen szabályos újraindítását.

Elindult, a store is. Nem nőtt tovább a mérete (ekkor potom 42GB volt). Miután ez egy esti időpillanat volt, arra gondoltam, hogy majd másnap foglalkozom vele.

Ezt a számításomat keresztül húzta a következő telefon. Elkezdtek store hibaüzenetek keletkezni az Event Logba.

Na ez két lehetőséget adott:

1. A mindig fennálló gyűlölt csoda: eseutil

2. Miután a store még valamilyen szinten élt, átköltöztetni az összes fiókot egy új adatbázisba.

Ez utóbbit választottam. Létrehoztam egy új storage group-ot, benne egy új store-t és hiba nélkül átpakoltam mindenkit.

Ez rendben is van. Kaptam egy 2GB-os adatbázist, örülök. De mi legyen a régivel. Régi Exchange ismereteim arra figyelmeztetnek, hogy az infrastruktúra első adatbázisa, első szervere, első anyámtyúkja mindig tartalmaz valami olyan információt, amit meg kell őrizni.

Végigtúrtam a netet és azt találtam, hogy az egyetlen dolog, ami az első adatbázisban van és a mozgatás során nem költözik el az a System Attendant mailbox. Ennek a költözésével pedig nem kell foglalkozni, mert amikor megszüntetjük azt az adatbázist, amelyikben volt, akkor automatikusan újragenerálódik egy másik adatbázisban (az eredeti cikk linkjét idetenném, ha nem dobálna 500-as hibákat a Microsoft fóruma).

Kipróbáltam. Működik. Probléma megoldva. Az eredeti hiba azóta nem fordult elő.

ClamAgent

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