Category2010

CAS Array 02/03 – Amikor kezd bonyolódni az élet

Nos, nézzük meg alaposabban, mi is történik a különböző RPC kapcsolatok esetén, ha már van CAS Array objektumunk és rendesen be is lett állítva mind az adatbázisokban, mind az Outlook profilokban.

1. Sima RPC over TCP

From Segédlet

Ez egy viszonylag egyszerű eset. Van egy CAS Array, mondjuk outlook.cegnev.local. (Javasolt best practice.) Ennek az IP címét a DNS-ben úgy állítjuk be, hogy az egyik CAS szerverre, jelen esetben a CASy-ra mutasson. Az Outlook profilban az outlook.cegnev.local név szerepel, így az RPC kérés elmegy a CASy-ra, ott az MSExchangeRPC szolgáltatás a felhasználó MDBHome értéke alapján megkeresi, melyik Mailbox szerveren van éppen az aktív adatbázisa, és már proxyzza is a kérést.

2. Magas rendelkezésreállású RPC over TCP

From Segédlet

Magas rendelkezésreállás. Csináltunk DAG-ot, van több DC-nk, mind a hardverek, mind a network eszközök redundánsak. Most már csak az Exchange elérésének kellene annak lennie. Az RPC kommunikációt kétféleképpen tehetjük azzá:

  • Windows Load Balance Service, magunk között csak WLBS.
    Felejtős. Anyira, hogy a Microsoft sem ajánlja. Ha érdekelnek a részletek, akkor a legnagyobb hiányossága az affinitás. Pontosabban a hiánya. Csak akkor hagy figyelmen kívül egy node-ot, ha az már IP szinten sem érhető el. Exchange esetében van még egy durva hátrány: a failover cluster és a WLBS nem fér el egy gépen, tehát a korrekt megoldás még két Windows és még két Exchange licenszbe kerülne.
  • Hardware loadbalancer
    Ennyi pénzért már korrekt hardveres loadbalancer kapható. Ez ügyes, okos, mindent tud.

Tehát betettük a loadbalancer clustert a belső hálózatunkba. Cluster, mert ugye magas rendelkezésreállás. Belső háló, mert az RPC csak ott van értelmezve. Jól is néznénk ki, ha kintről is jönnének RPC kérések.
A CAS Array IP címe egyben a loadbalancer cluster virtuális IP címe. A kliensről ide érkezik be a kérés, a loadbalancer pedig a beállított konfigurációja alapján továbbítja a kérést valamelyik CAS szerver felé. Jelen esetben ez megint a CASy. Onnantól minden megy ugyanúgy, mint az előző esetben.

3. RPC over HTTPS

From Segédlet

Eddig beszéltünk a belső hálózatról. De mi van azokkal, akik valamilyen okból kifolyólag kívülről szeretnék elérni a postafiókjukat? Outlookból?
Erre találták ki az RPC over HTTPS-t. Az Outlook kliensben megadom az elérendő belső címet (outlook.cegnev.local), de mellette megadjuk a DMZ-ben elrejtett reverse proxy kinti nevét is. (Ez simán lehet egy mezei virtuális Linux egy akármilyen webszerverrel.) A reverse proxy tudja, hogy a kívülről jövő HTTPS kérést – mert ő csak ennyit lát belőle – melyik belső webszerverre kell dobnia. (Megjegyzem, itt már remekül lehet affinitást is konfigurálni – de webproxynál csak webes protokollokra működik.) A fenti ábrán a CASx webszervert választotta. A CASx terminálja a HTTPS csatornát. Itt bújik ki belőle az RPC és nekiáll keresni a CAS Array-t. A DNS vissza fogja dobni neki a beállított IP címet, a kérés továbbpattan, majd onnan megy minden, mint korábban.

4. Magas rendelkezésreállású RPC over HTTPS

From Segédlet

Ha már van egy loadbalancer készülékünk, mely az Exchange szerverek RPC szolgáltatásait proxyzza, simán használhatjuk arra is, hogy ugyanezen szerverek webszolgáltatásaival is megtegye ugyanezt. (Sajnos a Linux szervert nem tudjuk használni RPC proxyzásra, mert az már layer7.) Ettől persze egészen érdekes lesz a táncrend. A loadbalancer VIP címe van kiforgatva a külvilág felé, ide érkezik be a HTTPS forgalom. Az eszköz a HTTPS loadbalance paraméterek szerint dobja tovább a kérést egy tetszőleges CAS szervernek, ez megint a CASx. A CASx terminálja a HTTPS forgalmat, kibújik az RPC, keresi a CAS Array-t – mely jelen esetben megint a loadbalancer VIP címe. Viszont ekkor már RPC forgalomról beszélünk. A forgalom az RPC loadbalance szabályok szerint megy tovább, immár a CASy-ra, ahonnan már ismerjük a mókát.

Hogy tetszik?
Mert nekem nem túlzottan. Az utolsó két ábra olyan, mint egy Klampár-Jónyer pingpongmeccs. Muszáj ekkora adok-kapokba belemennünk?
Nem. Az MSExchangeRPC szolgáltatás képes arra, hogy megtalálja a rövidebb utat az erdőn keresztül.
De ehhez durván le kell szarnia az etikettet.
A valós működés az, hogy abban a pillanatban, amint egy CAS szerver kap egy proxyzandó kérést, mindent félretéve megpróbálkozik maga elérni az illetékes Mailbox szervert. Amennyiben ez sikerül, akkor a kérés már nem pattog tovább.

Tessék ezen egy kicsit elgondolkodni. Az utolsó két ábráról egyből látszik, hogy hülyeség. Valótlan. Már a CASx szerver megpróbálkozik elérni a Mailbox szervert és amennyiben sikerül neki, akkor a többi elem nem játszik.
Konkrétan letojja, hogy van-e CAS Array és mi a konfigurációja. Megpróbálja elérni a Mailbox szervert, és ha sikerül, akkor sínen vagyunk. Sőt, a sima RPC over TCP kapcsolatoknál sem foglalkozik egyik CAS szerver sem a CAS Array objektummal. Tőlük fel is fordulhat.

Fogadok, most összezavarodtál. A cikkek lényege éppen az lett volna, hogy megmutassam, mennyire fontos dolog ez a CAS Array objektum. Aztán kiderül, hogy a kutya sem használja. Írtam két hosszú cikket, ábrákat rajzoltam… majd kinyírtam a főhőst, mintha egy Trónok Harca szereplő lett volna. Ennek mi értelme?

Jó, pihenjünk meg egy kicsit.

Ha már lehiggadtunk, észre fogjuk venni, hogy tulajdonképpen minden rendben van: az MSExchangeRPC szolgáltatás akkor önállóskodik, amikor a kérés már elérte a CAS szervert; a CAS Array pedig arra szolgál, hogy a kliens elérje az első CAS szervert. A CAS Array nem tehet arról, hogy az RPC over HTTPS egy reverse proxyn keresztül jön be és már ez a proxy megmondja, melyik CAS szervert kell elérni. Az RPC over TCP protokoll esetében meg természetes, hogy a CAS szervereket nem érdekli a CAS Array: nem nekik találták ki. A CAS Array objektumot a MAPI kliensek használják.

Viszont ajánlanék a figyelmedbe két töprengenivalót.

  1. Ha minden forgalmat sikerülne RPC over TCP helyett RPC over HTTPS-re terelni, akkor szükség lenne-e a magas rendelkezésreállás biztosításához a drága loadbalancer cuccokra? Nem lenne-e elég helyettük az ingyenes Linux reverse proxy?
  2. Meg lehet-e oldani, hogy minden kliens forgalom RPC over HTTPS-en keresztül menjen?

CAS Array 01/03 – Alapozás

Már régóta terveztem írni egy részletesebb cikket az Exchange 2010 CAS Array működéséről, mert úgy tapasztaltam, hogy még a legprofibbak fejében sem tiszta teljesen a kép.

Kezdjük rögtön a fogalom tisztázásával. Sokan az ‘array’ névből egyből magas rendelkezésreállásra gondolnak, és összekeverik a loadbalance megoldásokkal. Hiba. Nagyon pongyola megfogalmazással a loadbalance feladata a kliens kérését egy adekvát szerveren futó szolgáltatás felé irányítani, míg a CAS Array feladata… tulajdonképpen ugyanez, de nagyon nem mindegy, mit értünk adekvát szerver kifejezés alatt, hol történik meg az irányítás… és természetesen terheléselosztásról szó sincs.

Mielőtt teljesen belebonyolódnék, kezdjük el boncolgatni az Exchange 2010 kliens oldali hozzáféréseit.
Vannak a tiszta webes hozzáférések. Ezekről túl sokat nem kell magyarázni, mindenki látott már webszervert, webes szolgáltatást. Aztán van az RPC over TCP, azaz a klasszikus MAPI. Ezt használja a vastag kliens – Outlook – de léteznek más külső alkalmazások is, mint például a Blackberry szerver. Ez nagyon nem webes hozzáférés: alaphelyzetben több tízezer port közül választhat kapcsolatonként egyet, illetve kell neki a 135-ös, ahol az endpoint mapper azt mondja meg, melyik is lett kiválasztva. (Szerencsére ez az egész konfigurálható, de jelen sorozatban ezzel nem foglalkozok.) Az Exchange-ben létezik az RPC-nek webre erőszakolt verziója is, az RPC over HTTPS, azaz az Outlook Anywhere. Itt az RPC forgalmat HTTPS csatornába gyömöszölték, így lett belőle webes adatforgalom.

Foglalkozzunk most egy kicsit részletesebben ezzel az RPC-vel. A 2010-es verzióban az RPC over TCP elérésben nagy változás történt: az Outlook kliensek immár nem közvetlenül a Mailbox szerverre kapcsolódnak, hanem egy baráti CAS szerverre, mely proxyzza az RPC kérést a Mailbox szerver felé. Innentől lesz érdekes a dolog. Honnét tudja az Outlook, hogy ki az a baráti CAS szerver, aki valószínűleg el fogja tudni érni a Mailbox szervert?

Amikor létrehozunk egy adatbázist, akkor annak az RPCClientAccessServer változójába beleíródik egy név. Ha magán a szerveren fut CAS szerepkör is, akkor a saját neve, ha nem, akkor az Exchange keres egy közeli, RPC-n elérhető CAS szervert és annak a nevét írja bele. Ez lesz az a CAS szerver, aki proxyzza a kérést az adott adatbázis felé.
Amikor a felhasználó létrehoz egy Outlook profilt a gépén, akkor az történik, hogy az Outlook kiolvassa, melyik adatbázisban van a felhasználó postafiókja, majd megkeresi ennek az adatbázisnak az RPCClientAccessServer értékét – és erre a szerverre állítja be a profilban a kapcsolódást.
Ez szépen működik is addig, amíg az a bizonyos CAS szerver elérhető. De mi van akkor, ha ledől? Az Outlook továbbra is a profilban lévő CAS szervert fogja ostromolni – sikertelenül. Hiába létezik másik CAS szerver és hiába tökéletesen egészséges az adatbázis, a felhasználó nem fér hozzá a postafiókjához.

Akár külön cikkben is lehetne részletezni, hogy mikor, mi történik. A pontos forgatókönyv csak a következőktől függ: az Exchange verziója, service pack száma, rollup pack száma, hány AD site-on vannak Exchange szerverek, használunk-e DAG-ot, loadbalancer-t, reverse proxy-t, vannak-e public foldereink és nem utolsósorban, milyen verziójú Outlook-ok vannak a cégnél.

Maradjunk annyiban, hogy ilyen esetben kisebb-nagyobb kényelmetlenségek történhetnek, melyek között szerepel az elérhetetlenség is.

Ennek a szituációnak az elegáns kezelésére találták ki a CAS Array-t.

A CAS Array egy meglehetősen absztrakt objektum az Active Directoryban. Van neki neve, FQDN értéke és egy listája, hogy mely CAS szerverek tartoznak bele. Ez egy AD site szintű objektum, azaz automatikusan a site-on belüli összes CAS szerver tagja lesz. A létrehozását nem fogom leírni, tele van ilyesmivel a net. Arról, hogy az FQDN értelmezhető legyen, nekünk kell gondoskodnunk, azaz létre kell hozni hozzá egy DNS bejegyzést.

Innentől kezdve ha kreálunk egy új adatbázist, akkor annak az RPCClientAccessServer értéke a CAS Array neve lesz. A MAPI kliensek a CAS Array nevét kapják meg. Itt jön be a képbe a DNS. A CAS Array IP címe magas rendelkezésreállású környezetben lehet a loadbalancer IP címe, egyébként pedig lehet egy általunk kiválasztott CAS szerver IP címe.
Nézzük, mi történik most a korábban vázolt példában. Azt mondtuk, hogy a Mailbox szerveren nincs CAS funkció, ezzel szemben van több különálló CAS szerverünk. Ha kidől az egyik, akkor semmi gond sincs, a DNS-ben átírjuk a CAS Array IP címét a másikra. Életszagúbb példa, hogy teszem azt, lecseréljük a CAS szerverünket. Megint csak elég átírni az IP címet a DNS-ben. A kliensek mindkét esetben gond nélkül veszik az akadályt, hiszen nem kell módosítani a profiljukban semmit. (Természetesen ezek a szituációk kezelhetőek CAS Array nélkül is, de sokkal nyögvenyelősebben. Természetesen a korábbi kiemelés megjegyzései most is érvényesek.)

Még egy apróság: a régi, azaz a CAS Array létrehozása előtti adatbázisokban az RPCClientAccessServer értéke nem változik meg magától, itt manuálisan kell módosítanunk. Hasonlóképpen a már létrejött Outlook profilokban sem történik meg magától az átállás, ehhez különféle varázslások kellenek. (Nem mindig, és nem minden varázslás működik minden esetben, de ebbe most megint ne menjünk bele.) Ezért szokták azt mondani, hogy Exchange 2010-es környezetben az első dolgunk legyen létrehozni a CAS Array-t, még azelőtt, hogy a kliensek hozzákapcsolódnának. (És persze a default adatbázisban írjuk át manuálisan az értéket.) Ezt célszerű megtenni még akkor is, ha nem foglalkozunk magas rendelkezésreállással, hiszen nem tudhatjuk, mit hoz a jövő, és a legótvarabb munka egy Exchange organizáció átvariálásakor a kilensek átkonfigurálása.

Mit fogunk ekkor látni? Ha megnézzük az Outlookban, akkor azt, hogy a kliensünk mind a webes kapcsolódásokban, mind az RPC-ben immár a CAS Array nevet használja, azaz azt az IP címet fogja támadni, amit mögé tettünk. Innentől bármikor nagyon könyen tudjuk terelni a forgalmat.

Két megjegyzés:

  • A fenti állítás nem teljesen igaz. A Public Folderek RPC elérése nincs proxyzva, tehát ott, ha mandinerből is, de a Mailbox szervert támadja a kliens.
  • Bárkiben felmerülhet az ötlet, hogy hoppá, itt olcsón lehet magas rendelkezésreállást létrehozni: a DNS-ben round robin módon felveszem ugyanarra a névre az összes CAS szervert. Ez jó addig, amíg mindegyik CAS szerver működik, de ha bármelyik ledől, arról a DNS nem fog tudni és simán kiadja a nem elérhető címeket is a hozzá fordulóknak.

Ennyi volt az alapozás. A következő írásban némileg mélyebben beleásunk a különböző RPC kapcsolódásokba, megvizsgáljuk, hogyan befolyásolja mindezt a loadbalancer, illetve a HTTPS csatornázás.

Copy/Paste a mi barátunk

Jelenleg egy Exchange 2013 alapú hosting infrastruktúra tervezésével foglalkozom. Mint kiderült bizonyos dolgok kikerültek a grafikus management felületből a korábbiakhoz képest. Például nincs OAB reszelés a felületen. A vége az lett, hogy nagyjából mindent PowerShell-ből kell megcsinálni. Ennek kapcsán az ember olvasgatja a helpet. Részletek különböző parancsok helpjeiből:

Get-Help New-DynamicDistributionGroup -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-AddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Get-Help New-GlobalAddressList -full

-RecipientContainer <OrganizationalUnitIdParameter>
The RecipientContainer parameter filters the recipients used to build the dynamic distribution group based on their location in Active Directory. The value of the RecipientContainer parameter can be the canonical name of an organizational unit (OU) or a domain. If you don’t specify a value for the RecipientContainer parameter, the cmdlet will default to use the local container. This location is specified by using the OrganizationalUnit parameter.

Tombol a copy/paste, ellenőrzés nélkül. Nyugi, ez már a 2010-ben is pontosan ugyanígy van a helpben.

Exchange 2013 CU1

Az Exchange Team Blogon jártam. Megláttam a rég várva várt címet Exchange 2013 RTM CU1 … Status.

A “Status” szó így hirtelen nem tett gyanakvóvá. Pedig kellett volna.

Szóval az ígéretekkel ellentétben a fenti update nem jelenik meg az első negyedévben. Tehát még nem tudok a meglévő 2010-es infrastruktúrámba 2013-at telepíteni.

A cél azért nincs messze. Ha igaz amit ígérnek, jövő hét kedden a kezünkbe kerül az új játék. 🙂

Az eltűnt e-mail esete

Tegnapelőtt este egy weboldal nem engedett be. Megpróbáltam resetelni a jelszavam. A folyamat:

Küldenek egy e-mail-t, amiben van egy link, erre kattintva kapok egy másik levelet, benne az egyszerhasználatos jelszavammal. Szokásos eljárás.

Megjött az első levél, rákattintok a linkre, közli, hogy küldi a jelszavam.

Második e-mail sehol. Várok… várok… még mindig várok. Nem jön.

A dolog nem volt se fontos, se sürgős, így napirendre tértem a téma felett.

Másnap reggel a telefonomon nézem az adott postaládát, a levél ott van. A megfelelő időben, előző este érkezett.

Leültem az irodai gépem Outlookja elé. A levelet ott sem látom. Akkor nézzük meg OWA-ban. Bejelentkezek a saját nevemben, majd megpróbálok átlépni abba a postaládába, ahova a levél érkezett (ez nem az elsődleges fiókom, hanem a freemail fiókom “exchange-esített” változata). Nem sikerül, az OWA dob egy ronda hibát valami null property-re.

Keresgélek a neten és ezt találom:

http://support.microsoft.com/kb/2777852

Remek, ezek szerint akkor tudom megnyitni a másik mailboxom ilyen módon az OWA-ban, ha a freemail.hu-t felveszem az accepted domain listára. Ehhez valahogy nincs kedvem.

Belépek a postaládába az eredeti felhasználója nevében.

A keresett levél ott van… és … azt állítja magáról, hogy private. Ok. Ez teljesen érthető. A private jelzéssel rendelkező leveleket a Full Access joggal rendelkező másik felhasználó nem láthatja.

Ez így nekem nem jó.

Tehát a megoldás:

– csinálok egy terjesztési csoportot

– belerakom az összes érintett másodlagos postaládát

– csinálok egy Transport Rule-t amely az összes a terjesztési csoport tagjainak menő levélről leszedi a Sensitivity fejlécet, ha abban private/personal/confidental van.

Teszt kívülről. Működik.

Disable-ExchangeCertificate

Ne is keressük a címben szereplő EMS cmdletet. Nincs ilyen. A párja az Enable-ExchangeCertificate természetesen létezik. Van még olyan, hogy Remove-ExchangeCertificate, de az nem ugyanaz.

Miről is van szó?

Egy kissé is tapasztalt Exchange rendszergazda tudja, hogy az Enable-ExchangeCertificate parancsal lehet, a certificate store-ban tárolt tanúsítványokat az Exchange különböző szolgáltatásaihoz rendelni.

Néhány héttel ezelőtt az egyik ügyfelünknél azt a feladatot kaptam, hogy rakjam rendbe a tanúsítványokat. Ez abból állt volna, hogy a régi, már nem használt tanúsítványokat leszedjük a szolgáltatásokról, majd a tesztidőszakot követően eltávolítjuk a store-ból.

Először elkezdtem keresni, hogy milyen parancsal lehet ezt megtenni. Sokat keresgéltem, de csak azt találtam, hogy a tanúsítványt el tudom távolítani a store-ból, de a szolgáltatást nem tudom leszedni róla.

Az ügyfélnél ez egy alacsony prioritású feladat volt, így  a dolgot végül is ennyiben hagytuk.

Tegnap a nagy álljunk vissza androidra című felbuzdulásom kapcsán nekiálltam, hogy rendbetegyem a saját Exchange-emen az IMAP tanúsítványát. A problémáról itt írtam: http://it-pro-hu.blogspot.hu/2013/02/mi-bajom-az-androiddal.html A feladat a következő:

Az IMAP-nak a már jó ideje megvett, de be nem üzemelt Netlockos tanúsítványt kell használnia, az IISnek ugyanakkor a saját CA által kiállítottat mert nem akartam most szétszedni az egyész SAN-os/Autodiscover-es miskulanciát.

Megpróbáltam az IMAP-ról leszedni a régi tanúsítványt és természetesen újra a néhány héttel ezelőtti problémába futottam. Itt és most viszont nem akartam feladni. Arra gondoltam, hogy az Exchange azt az információt, hogy melyik tanúsítvány van hozzárendelve egy adott szolgáltatáshoz, biztosan tárolja valahol. Az Exchange tudtommal a különböző konfigurációs beállításokat alapvetően két helyen tárolja: az Active Directory-ban és különböző XML konfigurációs fájlokban:

– ADSIEdit -> configuration namespace -> semmi

– LDIFDE -> configuration namespace export -> az export fájlban keresgélve -> semmi

– Előkerestem az IMAP és POP3 szolgáltatás .Net Assembly-jét -> .config fájl -> semmi

– IIS Metabase -> semmi

Kezd a dolog kifogni rajtam. Felhívtam Józsit, hátha van valami ötlete. Sajnos nem volt.

Tovább keresgélve ráakadtam erre a cikkre:

http://www.msexchange.org/articles-tutorials/exchange-server-2007/management-administration/managing-exchange-certificates-part3.html

Itt ezen megakadt a szemem:

By running the cmdlet, Enable-ExchangeCertificate, you will enable a certificate for one or more services by updating the metadata stored with the certificate.

Every service has different metadata requirements, and will have different properties updated:

  • POP3-IMAP4: msExchPopImapX509CertificateName property will be updated;
  • IIS: Default Web Site will be updated;
  • SMTP: the Network Service account will be granted Read access to the appropriate private file key in the directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys;
  • UM: certificate property will be updated to include Unified Messaging.

Hoppá, ezek szerint nem reszelgetünk konfigurációs információkat, hanem a névegyezőségből és a tanúsítvány jogokból adódik, hogy mi látszik a Get-ExchangeCertificate parancs kimenetében.

Ellenőrzésképpen tettem is egy gyors próbát.

Az alapállapot az volt, hogy mind a saját CA-m által kiállított tanúsítvány, mind a NetLock-os hozzá volt rendelve az IMAP szolgáltatáshoz.

Az IMAP szolgáltatáson elrontottam a site nevét.

Láss csodát: Mindkét tanúsítványról eltűnt az IMAP flag. Ezek után persze kérdés, hogy a rendszer mi alapján dönt, ha több lehetséges tanúsítvány van.

A másik része a dolognak az All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys könyvtár tartalma. Itt találhatóak a Local System tanúsítványai. Sajnos a fájlnevek köszönő viszonyban sincsenek a tanúsitvány thumbprintjével, firendly nevével, vagy CN-jével, vagy akár bármi értelmezhető paraméterével. Az itt található tanúsítványok közül az használható SMTP hitelesítésre amilyikre a Network Service usernek olvasási joga van (az az érzésem, hogy ez az olvasási jog ugyanúgy szükséges a POP3-hoz és az IMAP-hoz is de ezt még nem tudtam tesztelni, ha ez igaz és szükséges a tanúsítványok szétválasztása, akkor érdemes elgondolkozni, hogy a Network Service helyett egyedi service accountokat használjuk a szolgáltatásokhoz).

Ha itt állítani akarunk valamit akkor merül fel a kérdés, hogy a fájlok közül vajon melyiket kell piszkálnunk, amikor mi csak a tanúsítvány thumbprintjét ismerjük (jó lenne ezeket a jogokat a certificate mmc-ben állítani, de ott sajnos erre nincs lehetőség).

Vajon hogyan tudjuk a thumbprintet összerendelni a fájlokkal? Újabb keresgélés a neten. A megoldás innen adódik:

http://jorgequestforknowledge.wordpress.com/2012/02/10/managing-certificates-on-a-windows-computer-with-powershell/

Az itt található scripteket kicsit átpofozva írtam egy scriptet ami a thumbprint alapján megadja a fájl nevét és a jogosultságait:

param([string]$ThumbPrint)
$Cert = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq $ThumbPrint}
$MachineKeysLocation = $env:ALLUSERSPROFILE + “\Microsoft\Crypto\RSA\MachineKeys\”
$KeyFileName = $Cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
$KeyFilePath = $MachineKeysLocation + $KeyFileName
Write-Host FriendlyName: $Cert.FriendlyName
Write-Host Subject: $Cert.Subject
Get-Acl $KeyFilePath | fl

EmployeeID vagy EmployeeNumber? Szerinted mindegy?

A válasz: NEM. Ha igen lenne, talán létre se jött volna ez a cikk.

De kezdjük az elején.

Kb. másfél éve építettünk egy elég nagy rendszert (AD/Exchange). Az ügyfél azzal az igénnyel állt elő, hogy az Active Directory-ba későbbi felhasználásra kerüljön bele a HR rendszerben használt egyedi azonosító.

Körülnéztem, hogy mit lehetne erre használni, és arra jutottam, hogy van két attribútum: Az EmployeeID és az EmployeeNumber. Nagyjából pénzfeldobással az elsőre esett a választás.

Az AD feltöltése kapcsán némi PowerShell scriptel ez kitöltésre is került.

Azt nem tudom, hogy az elmúlt időben használták-e ezt valamire, de két napja előjött az igény, hogy az EmployeeID jelenjen meg az Outlookban, a címlistában (GAL/OAB).

Az ügyfél azt is kibogarászta, hogy az Exchange-ben van egy Details Template Editor, amivel a kliens oldalon pl. a GAL-ban tárolt felhasználók tulajdonságlapjának megjelenését lehet beállítani (ez számomra újdonság volt, de mindig tanul az ember). A probléma csak az, hogy itt a választható attributumok között nem találta meg az EmployeeID-t.

Keresgélve ezt találtam:

http://blogs.technet.com/b/exchange/archive/2010/03/10/3409495.aspx

Ebből az derül ki (amit alapból is sejtettem), hogy egy AD attribútum, akkor jelenhet meg a GAL-ban, ha benne van a GC-ben. Tehát fogtam magam és bekapcsoltam, hogy az EmployeeID megjelenjen a GC-ben.

Három órával később az ügyfél jelentkezett, hogy a Details Template Editorban még mindig nem látja az EmployeeID-t.

Ma reggel ránéztem, és tényleg nincs ott. Újabb google. Az eredmény:

http://exchangepedia.com/2008/06/modifying-display-templates-and-additional-attributes.html

http://mostlyexchange.blogspot.hu/2005/03/adding-attributes-to-exchange-details.html

Tehát rövden:

Csak olyan AD attribútum jelenhet meg a Details Template-ben aminek van mAPIID-ja. Az EmployeeID-nak nincs, az EmployeeNumber-nek meg van. Remek.

Két megoldás kínálkozik. Vagy átpakoljuk az összes EmployeeID-t az EmployeeNumber-be, vagy az EmployeeID-nak csinálunk mAPIID-t.

Az első egy rövid PowerShell script, a második pedig egy kőkemény hegesztés, ami ráadásul nem is támogatott…

Exchange patch és egyebek

Nemrég megkérdezték tőlem, miért paráznak az Exchange adminok a hotfixek telepítésétől. Megemlítettem, hogy két olyan esetről is tudok, amikor egy-egy rollup pack hazavágta a rendszert, és a kardjukba dőlt adminokat nem igazán vigasztalta, hogy az MS később visszavonta a csomagokat.

Nos, itt egy újabb csapda. Azt írják az Exchange blogon, hogy habár a Windows Update / WSUS / SCCM mind lelkendezve ajánlja ki az opcionális frissítések között a Windows Management Framework 3.0-t – igen, benne a csábos Powershell 3.0-val – az Exchange 2007/2010-et futtató gépekre inkább ne telepítsük. Ha mégis feltennénk, számíthatunk arra, hogy a rollup packok nem települnek fel, illetve az EMS begolyózik. Szóval óvatosan.

targetAddress avagy spóroljunk a licenszeken

Most következik az az eset, amikor bebizonyítom, hogy nem értek az Exchange-hez.

Mit csinálunk olyankor, amikor van egy email címünk, amiért a saját Exchange szervezetünk a felelős, de az ide érkező leveleket tovább kell küldenünk egy külső címre, és saját rendszerünkön soha egy darab levelet sem kell tárolnunk, ami a megadott címre érkezik?

Én (és az a gyanúm, hogy ezzel nem vagyok egyedül) a következőt tettem a fenti esetben. Létrehoztam a saját címünkhöz egy postaládát, a külső címhez egy kontaktot és a postaládát ráirányítottam a kontaktra. Megbékéltem azzal, hogy ez ronda, sőt minden egyes ilyen akció visz magával egy nem is túl olcsó CAL-t.

Mostanában a több ügyfélnél az Exchange 2003 – Exchange 2010 Cross-Forest migrációval birkózom (ez egyszer még megér egy másik cikket). Ennek kapcsán meglepetten tapasztaltam, hogy a migráció végén a rendszer egy olyan Mail Enabled User-t (ez ugye Exchange szempontból egy kontakt, és mint ilyen nincs postaládája) hagy maga után. Ami viszont képes leveleket továbbítani pontosan úgy, ahogy a fenti kérdésben szerepel.

Némi nyomozás után kiderült, hogy a tettes a targetAddress nevű AD property. Tehát minden levél, ami a kontakt egyik proxyaddress-ére érkezik azt a rendszer tovább küldi a targetAddress property-ben szereplő címre. Ráadásul a rendszer azt a kedvességet is megteszi (mind Exchange 2003 mind 2010 esetén), hogy a targetAddress property-t eleve kitölti a kontakt email címére.

Ebből adódóan az eredeti kérdésre adott válasz így változik:

Felveszünk egy kontaktot a külső címmel, majd a kontakt proxyAddresses listájába felvesszük az átirányítani kívánt saját címet.

Kész vagyunk. Mínusz egy CAL.

AntiSpam Update

Van egy dolog, ami már jó ideje bosszant.

Az Exchange 2007/2010 lehetőséget biztosít arra, hogy a Hub Transport szerveren feltelepísük a Microsoft AntiSpam agent-jeit. Ezzel kapunk egy jól működő, nagy tudású spam szűrő infrastruktúrát.

Ez ugyan nem annyira hatékony, mint a ForeFront for Exchange, továbbá nincs benne vírusirtó, viszont ingyen van.

Amikor ez a lehetőség először megjelent az Exchange 2007-ben, akkor lehetőségünk volt arra, hogy a hozzá tartozó definíciós fájlokat automatikusan frissítsük (Ez a ForeFront nélkül 3 hetente történt). Ez a lehetőség egy adott ponton megszűnt. Pontosabban, ha nincs ForeFrontunk akkor az Exchange maga nem frissít, hanem ezt a Windows Update teszi meg helyette.

Ezzel viszont gond van. Én magam részéről szerveren sosem kapcsolom be a frissítések automatikus telepítését (csak az automatikus letöltést), mert a folyamatos üzem miatt az nem elfogadható, hogy a szerver újrainduljon, amikor az update-nek ehhez van kedve, ráadásul bizonyos környezetekben a biztonsági frissítések csak tesztelés után kerülhetnek az éles rendszerbe. Ebből adódóan nem csak a biztonsági frissítések, hanem az AntiSpam definició sem települ automatikusan, aminek pedig kellene.

A fenti állapotot kezelendő írtam egy kis javascriptet ami feltelepíti az AntiSpam definíciós fájlt. És csak azt. Ha ezt a kis scriptet (cscript.exe SpamUpdate.js) berakjuk a Task Scheduler-be akkor a fenti problémát megoldottuk.

A script innen tölthető le.

Internet Database Availability Group

Amikor elkezdtem olvasni Scott cikkét, egyből elcsöppent a nyálam. Épp mostanában van egy olyan munkám, hogy bár az ügyfélnek nincs túl sok pénze, de szeretne egy olyan HA megoldást két telephelyen, melyek még akkor is működnek, ha a Föld megsemmisül. Üzletpolitikailag meg nem mondhatjuk azt, hogy nem.
Szóval olvastam, olvastam, és bár a működését elsőre még nem láttam át teljes mélységében, de nagyon tetszett a dolog. Végülis nem akárki írta a cikket, aki Scott Schnollnál többet tud az Exchange HA területről, az már festi magát. És pont most jöttek ki vele, pont amikor égető szükségünk lenne rá. Remek.

A lelkesedésem egészen addig tartott, amíg észre nem vettem az írás végén a tag-eket.

ps.
Persze, folyamatosan nyüzsgött agyam hátterében a kisördög: mi is van azzal a kritikus round-trip latency-vel, az adatbázisok rpcclientaccessserver paramétereivel, na meg a CAS proxyzásokkal? De olyan jó lett volna hinni benne, hogy ezt mind-mind megoldották.

Imádom a lehetetlen küldetéseket

Napok óta a Windows 8 bétával foglalkozik a szakmai blogoszférának a Windowsra érzékeny része. Olyannyira benne van a levegőben, hogy már én is elgondolkoztam, hogy feldobok egy szervert és egy klienst a tesztrendszeremre. Ha időm lesz. Ha.

Viszont vannak olyan emberek – és az összes kalapomat megemelem előttük, pedig van pár – akik nem elégszenek meg azzal, hogy felraknak egy Windows 8 szervert, hanem úgy istenigazából nekiszaladnak és megnézik, hol vannak a határai. És mennyire kemény betonból vannak.

Paul Cunningham úgy döntött, hogy Exchange 2010-et telepít a béta Windows 8 szerverre. És nem riasztotta el, hogy ez abszolút nem támogatott. És akkor sem dőlt a kardjába, amikor a telepítő is közölte vele ezt a hírt. Hiszen a registry-t lehet editálni is, és miért ne hazudhatnánk be a Windows 2008-at (6.1) a Windows 8 (6.2) helyett? Ja, hogy a telepítés után nem indul el az Exchange? Kérem, ha már elkezdtünk hekkelni, miért állnánk meg pont itt?

A teljes cikk: Installing Exchange Server 2010 on Windows Server 8 Beta.

Exchange 2010 SP2

Ma az egyik kollégámmal egy rendszer átállásáról beszélgettünk. Felmerült lehetőségként, hogy mi lenne, ha építenénk egy Exchange 2010 hosting környezetet amibe nem csak az ügyfél adatai kerülnének, hanem a sajátjaink is. Természetesen felmerült az alap kérdés: GAL separation. Innen jött a kérdés: Mikor lesz SP2 ami ezt már tudja.

Rákerestem.

Van.

Tegnap óta:

http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx

Letölthető innen:

http://www.microsoft.com/download/en/details.aspx?id=28190

Kosztüm

Adott a feladat, publikáljunk egy Exchange 2010 OWA szolgáltatást TMG-n keresztül. Ez ma már egyáltalán nem pilótavizsgás munka, nosza.

Úgy döntöttünk, saját SAN tanúsítványt használunk, így első lépésben azt gyártjuk le. Certification snap-in, advanced, create a request. Itt kapjuk a következő ablakot.

From Segédlet

Először is pár szívélyes szóval megemlékeznék az UI tervezőjének felmenőági rokonairól. Hogy a szöszbe lehet olyan felületet tervezni, ahol nem látszik, mi kattintható választás és mi egyszerűen csak szöveg? Aki először jár erre, kénytelen az egérrel végigszkennelni az ablakot, figyelve, hol változik meg a kurzor.
Jó, nézzük a lehetőségeket. Aszongya, hogy… az Igazi Rendszergazda mindig a custom opciót választja, így akkor mehetünk is tovább.

From Segédlet

Mondjuk, nem fogunk dúskálni a lehetőségekben, az Igaz Rendszergazda egy kicsit meg is szeppen, mert egy kukkot sem ért a beállításokból, de aztán vállat von, biztosan jó lesz az alapértelmezés, és nyomja tovább bátran a varázslót. Elkészül a tanúsítvány, lecseréli az Exchange alatt, minden rendben, a napocska mosolyog, a madarak trilláznak. A belső hálóról működik az OWA, működik a MAPI, sehol nem jön fel tanúsítványhibára figyelmeztető ablak.

Kiexportáljuk a tanúsítványt, figyelve, hogy benne legyen a privát kulcs, felmásoljuk a TMG szerverre. Elkezdjük összerakni a web listenert. Elérkezünk oda, hogy kiválasszuk hozzá a tanúsítványt… de nincs. Azt mondja, hogy az a tanúsítvány, melybe az összes bizalmunkat helyeztük, az bizony inkorrekt. Hogy a manóba? Hiszen az Excange elfogadta, a kliensek elfogadták, az Active Directory elfogadta, a TMG tartományi tag, tehát a root CA tanúsítványa rajta van, a dátumok jók… akkor miért inkorrekt? Ezért.

Ott, amikor a custom sablont választottuk a tanúsítvány igénylésénél, ott csak V3-as (CNG) tanúsítványt igényelhettünk. Igenám, de ebből a tipusú tanúsítványból a TMG nem tudja kiolvasni a privát kulcsot, azaz úgy érzékeli, hogy nincs benne, azaz a tanúsítvány inkorrekt. Kuka.

Visszamegyünk ahhoz a bizonyos ablakhoz és most azt választjuk, hogy Active Directory Enrollment Policy.

From Segédlet

Itt már a jól ismert legördülő menü fogad, kiválasztjuk a V2-es Web Server sablont, és máris minden kiegyenesedik.

Tömörítsek?

Amióta létezik olyan termék, hogy Exchange, állandóan visszatérő kérdés az adminok körében: kell-e tömöríteni az adatbázis, és ha igen, akkor mikor?

Rövid kitérő, ha valaki esetleg nemrég bújt volna még csak ki a tojáshéjból. Az Exchange-ben – eltekintve a régebbi verziók stm fájljaitól – egy adatbázis egy darab edb fájl. Ezen a fájlon belül vannak adattáblák, ahol az összetartozó adatok között pointerek teremtik meg a kapcsolatot. Amikor törlök egy levelet, akkor az egyik adattáblából törlődik a levél tartalma, és emellett törlődnek a rámutató pointerek is. Értelemszerűen hiába csökkennek az egyes adattáblák méretei, az edb fájl mérete nem csökken. A fájlon belül üres hely (whitespace) szabadul fel, de a sok, apró üres hellyel az Exchange nem tud mit kezdeni. Ekkor jön be a képbe az Online Maintenance folyamaton belül az Online Defragmentation, azaz online tömörítés: ez az edb fájlon belül az üres helyeket kimozgatja a fájl végére, így újra hasznosíthatók lesznek. Az online tömörítés, mint a neve is mutatja, online, azaz működés közben is végezhető. Csak éppen erőforrásigényes, emellett Exchange 2010 előtt szégyenlős is, ha túl nagy aktivitást észlel az adatbázison, akkor megáll. Márpedig az online tömörítés hiányában vészesen dagadni kezd az adatbázis. Sőt, ha valaki végiggondolja a folyamatot, akkor láthatja, hogy az online tömörítés mellett is dagadhat az adatbázis. Például kapunk egy tüskeszerű nagy terhelést. Egy nap alatt felhízik az adatbázis (betör egy spam), a felhasználók ugyan törlik a leveleket, de az online tömörítés csak az üres helyekkel tud játszani, az edb fájl méretével már nem. Ahhoz, hogy az utóbbi is csökkenjen, már más módszerekhez kell nyúlni.

Így jutottunk el az offline tömörítéshez. Ekkor lecsatoljuk az adatbázist és az edb fájlt átadjuk egy erre a célra kifejlesztett adatbázismatyizó programnak (eseutil). Ez nyit egy új, ideiglenes adatbázist, elkezdi átmásolni az értelmes tartalmat (nem, a levelekben már nem kutat értelmet), majd ha végzett, akkor az eredeti adatbázist törli, az ideiglenest pedig átnevezi. Visszacsatoljuk és jó esetben mindenki boldog.

Most jön egy újabb kitérő. Olvasdd el Paul Cunningham írását. Nagyon szépen körbejárja a témát, a végeredménnyel pedig csak egyetérteni lehet: az offline defrag nem az az elem, melyet a rendszeres, szabályozott karbantartási folyamatok során végzel. Mivel az offline defrag offline, és emellett kockázatos is, csak akkor van értelme, ha az adatbázis mérete már problémákat okoz. Pontosan miket is? Egyrészt kezd elfogyni a tárterület a diszken. Ekkor el lehet gondolkozni az offline tömörítésen, de ha nem szeretjük a kockázatot, akkor lehet bővíteni is a tárterületet. Másrészt – saját tapasztalataim szerint – az Online Maintenance időigénye az edb fájl fizikai méretével arányos. A nagy edb fájl hosszú Online Maintenance időt jelent és így már lehet, hogy a folyamat nem fér bele a kijelölt időablakba. Nyilván az időablakot ki lehet húzni, de ekkor összecsúsznak az adatbázisműveletek, neadjisten belecsúsznak a produktív időbe, ez persze újabb terhelés – és egész egyszerűen mire végetér egy online tömörítés, már megint töredezett az adatbázis. Értelemszerűen itt is eljárhatunk úgy, hogy bővítünk – több RAM/proci – de ennyire ne legyünk már nyulak. Ezzel ugyanis csak elodázzuk a probléma megoldását.

Ekkor úgy halványan felmerül az offline tömörítés utáni igény az IT csapatban. De biztos, hogy erre van szükségünk? Mi van, ha az adatbázis tényleg ekkora lett? (Jelzem, ha az adatbázis mérete meg lett tervezve, az összes postafiók mérete korlátos, akkor ez a kérdés érdektelen.) Ilyenkor lenne jó tudni, mennyi is a whitespace. Biztosan vannak szofisztikáltabb módszerek is, én egy közepesen bonyolult powershell parancsot szoktam használni:

get-mailboxdatabase | get-mailboxstatistics | measure-object -property itemcount,totalitemsize -sum

Ez a szerveren lévő összes adatbázisra kiírja, hogy mennyi item-et (levelet, kontaktot, naptárbejegyzést) tartalmaznak, illetve ezeknek mekkora az összesített méretük. Ugyanez létezik konkrét adatbázisra is:

get-mailboxstatistics -database name | measure-object -property itemcount,totalitemsize -sum
get-publicfolderstatistics | measure-object -property itemcount,totalitemsize -sum

Az adatbázisok fizikai méretét megtaláljuk a Windows Explorerben, ebből pedig tudni fogjuk, hogy az adatbázisban mennyi az adat jellegű tartalom adattartalma. Igen, nem véletlenül fogalmaztam ennyire körülményesen. A cikk elején is írtam, hogy az edb fájlban vannak olyan adattáblák is, melyek az adatok strukturálását, gyors elérését segítik. Ez az adatbázis overhead. Tervezéskor én 20%-kal szoktam dolgozni – mégem hidat méretezünk, ekkora pontosság bőven elég – azaz ha ennél jóval nagyobb a különbség, akkor tényleg itt van az ideje az offline tömörítésnek.

Vagy mégsem?

Jó hír azoknak, akik Exchange 2010-et üzemeltetnek, hogy ők már használhatják az offline tömörítést online is. Nem, nem golyóztam be, legalábbis még nem nagyon. Olvassuk vissza, mit csinál az eseutil: nem tudnánk ezt mi is elvégezni, az adatbázis lecsatolása nélkül? Létrehozunk egy új adatbázist, felcsatoljuk, a postafiókokat átmozgatjuk (csak az adattartalom megy át, a whitespace nem), a régi adatbázist lecsatoljuk, letöröljük. Kész. A kliensek nem a Mailbox szerverhez kapcsolódnak, hanem a CAS szerverhez, az meg mindig tudja, melyik adatbázisban van a felhasználó. Ezzel ki is húztuk az offline defrag mindkét méregfogát:
– Nem offline. Régebben könnyű volt az élet, ötkor megszólalt a gyárban a sziréna, a portás hatkor lehúzta a redőnyt, a rendszergazda ekkor kezdett ébredezni, majd éjjel lecsatolta az adatbázisokat és reszelgette. Manapság már nincs holtidő. A legtöbb alkalmazottnak van minimum egy emailképes kütyüje, és valami fura perverzióból éjjel is meg akarják nézni a leveleiket. Offline folyamat? Hogy gondolod.
– Bármennyire okos is az eseutil, egyszerűen nem tudjuk olyan alaposan paraméterezni, mit csináljon az értelmetlen adatokkal, mint ahogy egy postafiókmásolás esetében. Már nem kell rettegni attól, hogy az eseutil után kapunk egy annyira tömör adatbázist, hogy gyakorlatilag üres.

Pecs

Kora reggel jött egy kérdés. Valami nem működik egy Exchange 2010 szerveren. Oké, mindjárt megnézem a tesztrendszeren.
Hát, a mindjárt kicsit elhúzódott, ugyanis szégyen ide vagy oda, de marha régen jártam már erre, tizensok patch várta toporzékolva, hogy feltelepüljön. – Jól van, aranyoskáim, azonnal – nyugtattam meg a virtuális gépeket és rányomtam az install gombra.
Közben elmentem reggelizni. Visszajöttem, restart.

Nosza, nézzük azt a problémát. Elindítottam az outlook-ot a kliensen – erre közölte, hogy nincs Exchange szerver. Hoppá. Megpingettem, látta. Névre is, IP-re is. Mind a kettőt. Biztos az outlook2003 hülyéskedik – gondoltam – és beléptem egy másik tesztgépbe, ahol outlook2010 dolgozott. Ugyanaz. Ő sem látta az Exchange szervereket.
Mi a fenét csinálhattak a patch-ek?

Korán reggel volt, az agyam még nem bootolt be rendesen, pusztán ezzel tudom magyarázni, hogy már első körben ész nélkül nekiálltam guglizni. Lett is egy csomó találat, egyik vadabb dolgot mondott, mint a másik. Mindegyik szálnak utánajártam, de minden rendben volt, ezek nem okozhatták a hibát.
Kimentem a konyhába, főztem egy kávét. Innentől mondhatom azt, hogy nekiálltam módszeresen felgöngyölíteni a problémát. Exchange szerver, eventlog. Minden rendben, viszont másfél órával ezelőtt tömérdek piros felkiáltójel. Hmm, hmm. Nagyon sok. Ezt most mind olvassam át? Eh, ez másfél órával ezelőtt volt, nekem meg most van bajom. Majd visszanézek, ha nincs jobb ötletem.
Nézzük az Exchange szolgáltatásokat. Na, itt köptem vissza kis híján a kávét. Az automatikusan induló Exchange szolgáltatások durván fele csak úgy lógott a levegőben, köztük persze az Exchange RPC is. Mind a két szerveren! Ez azért már tényleg izgalmas. Indítsuk újra. Sorra végignyomkodtam a start gombot és a szervízek elindultak. Ráküldtem még vagy 5 refresh-t, de a szolgáltatások makacsul működtek. Ez egyre rejtélyesebb. Valahogy nyugodtabb lettem volna, ha a szolgáltatások egyszer csak maguktól megálltak volna.

Na, mindegy. Nézzük az outlook mit lát. Mindent. Mind a kettő. Mind a két Exchange szerveren. Fejvakarás.
Gyorsan megnéztem, amit a kora reggeli kérdéssel kapcsolatban akartam, aztán amíg válaszoltam, be is ugrott a megoldás. A kora reggel. A patch.
Idősporolás miatt egyszerre nyomtam rá mindegyik szerveren a Windows Update gombra, aztán reggeli után egyszerre a Reboot gombra. Az öt szerver (két DC, két Exchange, egy TMG) egyszerre állt le és egyszerre indult újra. Csakhogy. Amikor az Exchange szerverek szolgáltatásai keresték volna az AD-t, az még sehol sem volt. Emiatt vésték tele piros felkiáltójellel az eseménynaplót. Később persze meglett az AD, de a szolgáltatások nem indultak el maguktól.

Tanulság? A reggeli kávé előtt soha ne pecseljünk.

Exchange javítások

Két új hotfix jelent meg.

Az egyik az Exchange 2010 SP1 soron következő immár 6-os rollupja. Letölthető innen, további infók róla itt.

A másik egy igen bosszantó, ugyanakkor nem életbevágóan fontos hibát hivatott orvosolni. Ha az Exchange Management Console-t futtató gépen fenn van az IE9 és a Mailbox szerepkör tualjdonságait piszkáljuk akkor nem lehet becsukni a konzolt. Ezt az üzenetet kapjuk és csak a Task Managerből lehet kilőni az MMC-t: “You must close all dialog boxes before you can close Exchange Manaagement Console.”

Bővebben itt.

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

Milyen nehéz is elérni valamit amit a Microsoft nem tervezett bele eredetileg a termékbe. Már két körben írtam a témáról, hogyan helyezzünk el képet az OWA aláírásban. Ez a történet harmadik, de már most biztosan nem utolsó része.

Az előző kettő itt található:

http://www.emaildetektiv.hu/2011/08/18/exchange-2010-owa-signature-image/

http://www.emaildetektiv.hu/2011/10/03/exchange-2010-owa-signature-image-2/

A cikk második részének megírása után, a szükséges elemeket felraktam az ügyfél rendszerébe, majd nyugodtan hátradőltem, hogy nincs több dolgom a témában, csak teríteni az aláírásokat, amint az ügyfél emberei kitöltik a megfelelő adatokat az AD-ban.

Néhány nap múlva kaptam néhány teszt felhasználót, akiknél megvoltak az adatok, legeneráltam az aláírásokat képpel együtt, felhasználók tesztelnek, …

puff nagy pofon, nem működik.

Én tesztelek náluk az ő gépükön vnc-vel. Nekem megy.

Pár nap közdés után valaki rájött (ez nem én voltam), hogy ha új levelet küldök akkor jó, ha egy beérkező levélre válaszolok, akkor már az OWA-ban is egy nagy büdös piros x van a kép helyett. Tesztelés, ez bizony egy bug a rendszerben.

Két dolgot tehetünk:

1. Lejelentjük az MS-nek a hibát és reménykedünk, hogy megoldják.

2. Keresek valami megkerülő megoldást.

Hétfő (2011/10/17):

Mindkettőnek nekiugrottunk. A kollégák lejelentették az MS,nek én pedig elkezdtem Transport Agentet írni.

Estére el is készült az Agent váza, de még nem volt az igazi. Kollégám megfogalmazása erre a teszt levélre:

“az jó. csak mert abban igaz, hogy nem jön meg, de legalább a charcode is szar”

Hazamentem, este lett egy újabb öttletem, de az már nem fért bele a napba.

Kedd (2011/10/18):

Hajnalban nekiláttam, megcsináltam az Agentet, hibátlanul működött a teszt környezetben.

Lejelentettem, hogy jó, kértem a telepítéshez időpontot (Nem mennek a dolgok hű bele balázs módra, mert, ha minimális esélye van némi szolgáltatáskiesésnek, akkor arról mindenkinek tudnia kell. Itt volt ilyen, mert bizonyos struktúraválltás miatt az OWA tanúsítványát is cserélni kellet, ami az SSL Host header miatt okoz egy-két perc fennakadást)

Kaptam időt estére/másnap hajnalra.

Szerda (2011/10/19):

Hajnalban felraktam mindent.

Reggel ügyfél tesztel,…

Eredmény: szar.

Egész nap más dolgom volt, nem tudtam vele foglalkozni.

Este indolklás nélkül jön egy kérés, hogy kapcsoljam ki az OWA-ban a html link szűrést. Nem tudtam vele foglalkozni, majd holnap.

Csütörtök (2011/10/20):

Hajnalban elkezdtem tesztelni, hogy tegnap miért nem megy. Ki is derült, hogy a disclaimer a ludas (mert kérem itt aláírás is van, meg jogi nyilatkozat is). Ugyanis amikor beteszi a levél végére a szöveget akkor kiszedte az általam az aláírás html img tag-jébe becsempészett role=”contetntinfo:embed” attributumot (pedig szerintem ez szabványos, a W3C-től szedtem, modjuk a tag lezáró /> jelből is kiszedte a pert ami pedig az xhtml-ben már kötelező). Tehát a probléma orvosolható, ha az én Agent-em magasabb prioritást kap mint a Transport Rule Agent.

Valahol a tesztelgetés közepén beállítottam a tegnapi kérést. Engedélyeztem a HTML linkeket. Ettől meggyógult az eredeti probléma.

Mi van?????

Valaki akkora ész volt, hogy rájött, a piros x-es gondot az OWA “Web Beacon and HTML Filter” nevű szűrője okozza. Mekkora ász!

Reggel vissza is kérdeztem a kollágától:

– Erre ki jött rá?
– tesztelték.
SAP levélben linkek, nem tudták megbökni
– de arra, hogy ez megoldja az aláírásban kép balhét?
– arra senki.

Most őszintén. Ennek mekkora az esélye?

Agent kukába, a megoldás:

Get-OWAVirtualDirectory | Set-OWAVirtualDirectory -FilterWebBeaconsAndHtmlForms DisableFilter

Ugyan ez csökkenti a rendszer biztonságát, de valamit valamiért.

folyt. köv.

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: http://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.