Tag: exchange 2010

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

Exchange 2010 SP3 – Végre

Tegnapi napon megjelent az Exchange 2010 SP3. !!!VÉGRE!!!

Ez talán a leginkább várt frissítése az Exchange-nek. A legfontosabb dologok amket tartalmaz:

– Az első Exchange 2010 kiadás ami telepíthető Windows 2012-re

– A minimális SP szint az Exchnage 2013 együttéléshez (ez sajnos még nem az igazi, mert Exchange 2013 oldalon kell hozzá egy CU1 jelű frissítés ami még nincs kész)

– Internet Explorer 10 támogatás

Forrás: http://blogs.technet.com/b/exchange/archive/2013/02/12/released-exchange-server-2010-sp3.aspx

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

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

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

Már megint SP és kompatibilitás

Henrik Walther írt egy nyúlfarknyi cikket, melynek az a lényege, hogy tudja a fene.

De ez egy nagyon fontos információ.

Gondolom, mindenki érzi már a feszültséget a levegőben, hamarosan jönni fog a Windows 7 SP1, illetve a Windows Server 2008 R2 SP1. (Jelenleg az RC verzió érhető el mindkettőből.) Ebből minket az utóbbi érdekel. Együtt fog-e működni ez az operációs rendszer az Exchange Server 2010 SP1 alkalmazással?

Nos, erre válasz az, hogy tudja a fene. Pontosabban, ez a _félhivatalos_ válasz. Mindenesetre a jelenlegi állapotban a fenti kombinációt a Microsoft nem támogatja. Aztán később majd kiadnak egy hivatalos állásfoglalást is. (Bár Walter úgy tippel, hogy majd az Exchange Server 2010 SP2 oldja meg a helyzetet.)

Espéegy a porcelánboltban

Arról, hogy kijött az Exchange2010 SP1, szándékosan nem írtam semmit. Aki nem tudja meg tizenhét forrásból egy napon belül, az vagy traktorbelsőben él, vagy nem is érdekli a dolog. Azt is leírták sokan, sok helyen, hogy mi újdonságokat hozott a rendszerbe.

Foglalkozzunk most azzal, hogy mi mindent nyírt ki? Nem szándékosan persze, de hát így sikerült.

1.
Henrik Walther írt rögtön az elején egy cikket arról, hogy milyen meglepetésekre készüljünk fel.

2.
Aztán nem sokkal később az Exchange blogon jelent meg egy írás arról, hogy milyen problémák derültek ki nem sokkal az SP1 kibocsátása után.

3.
Végül Yuri Diogenes tett ki a blogjára egy cikket arról, hogy ne, hangsúlyozom, ne tegyél olyat, hogy a TMG E-mail Protection rendszeredben lévő Exchange 2010 Edge szerverre ráhúzod az SP1-et. Amennyiben mégis ilyet tettél volna, akkor ne, hangsúlyozom, ne nyúlj semmihez, mert csak tovább rontod a helyzetet. Várd meg a hotfixet, a fiúk a bányában ezerrel dolgoznak. (Hasonló tanáccsal szolgál a hivatalos ISA/TMG blog is.)

Exchange 2010 SP1

Tegnap óta ettől hangos az Exchange blogoszféra, gondoltam, én sem maradok le.

Nem, az SP1 még nem jött ki. Várhatóan hamarosan, de legalábbis idén még ki fog jönni. (És akkor elkezdhetnek végre a magyar döntéshozók is gondolkozni az Exchange 2010 bevezetéseken.)

Most az első publikus infók jelentek meg arról, mi minden lesz benne.

Röviden összefoglalva:

  • A triviális rész: tömérdek patch, beleértve a korábbi Rollup csomagok tartalmát is.
  • A Personal Archive postafiókok külön adatbázisba pakolhatók. Innentől tényleg lesz értelme a koncepciónak. (Eddig ugyanis nem sok volt.)
  • PST import. A szanaszét burjánzó PST-ket akár a felhasználó is képes lesz betolni a személyes archív postafiókjába.
  • Még mindig a régi levelek kezelése: bejött egy segédprogram a Retention Policy tag-ek létrehozásához.
  • Kicsit tuningoltak a discovery funkción is: egyrészt bejött egy search preview lehetőség, másrészt kiszűrték a keresési eredményekből a duplikátumokat. (Emlékszünk, a discovery az az eufemizált neve a full adatbázisos keresésnek.)
  • Reszeltek egy csomót az OWA-n is. Sokkal gyorsabb lett, kiszedték belőle a lassú, bosszantó folyamatokat. Másrészt a felhasználói élményen is javítottak, át lett szabva a kezelői felület. (Hogy a netbook felhasználók is örüljenek.) Ja, és lesznek OWA skinek is.
  • IRM integráció OWA-ba, Activesync-be.
  • Egy csomó új, eddig csak EMS-ből elérhető taszk kapott grafikus felületet az EMC-ben.

Akit bővebben is érdekelnek a részletek:

Mythbuster

Ezt írtam korábban.

Utána egy csajszi Mythbuster stílusban verte a fejünkbe, hogy miket kell mondani, hogyha az Exchange kellemetlen tulajdonságairól faggatnak. Háát… a backup részt továbbra is csak kerülgették, mint macska a forró kását.

Nos, a varázsnak vége, a mítoszrombolás nyilvános lett. Igaz, itt csak éppenhogy érintve (nálunk másfél órás előadás volt), de a lényeg benne van. Pontosabban, a lényeg itt van: Large Mailbox Vision whitepaper.

2010 CAS NLB

Véleményem szerint Exchange 2010 HA témakörben a legforróbb terület jelenleg a CAS NLB: egyszerűen szükség van rá, nem lehet megkerülni – viszont igazán optimális megoldás nem létezik.

Ezt írtam itt. És szemmel láthatóan nem csak engem zavar a dolog. Egy MVP kolléga ki is fakadt a blogján – segítve rajtam, mert így nem nekem kellett megírnom a cikket.

Exchange 2010 – A Practical Approach

Úgy látszik, másnak is megtetszett az ingyenkönyv-modell.

Eddig – tapasztalatom szerint – csak egy-egy fejezeteit szokták kirakni a netre a nagyobb könyveknek… és nemritkán a letöltésekhez meg kellett adnunk egy csomó adatot, emailcím ellenőrzés… ismerjük.

Ehhez képest ennél a könyvnél csak egy emailcímet kérnek, de azt sem ellenőrzik le, szóval mehet akármi. A könyv pedig teljes. Igaz, van a végén vagy tíz oldal reklám, de legfeljebb nem olvassuk el.

Gyorsolvasással átfutottam, nem is rossz. Olyan jó 300-as szint, őrült nagy mélyfúrást ne várjunk tőle, viszont szépen össze lettek szedve a dolgok. És ami külön tetszett, az az 5. fejezet bevezetése. Nagyon szépen, közérthetően írta le a szerző, mi is történik az adott esetekben az adatbázis matyizása közben.

letöltés

Lehet egy node-dal több?

Scott Schnoll Exchange 2010 High Availability (HA) előadása után gondolkodtam el néhány dolgon. Van ugyanis egy olyan HA matek, amellyel eddig egy Exchange mérnök még nemigen találkozott.

Történelmileg volt ugye az SCC, azaz a Single Copy Cluster. Ez viszonylag egyszerűen nézett ki, volt egy közös diszk – rajta a quorummal – aztán voltak a node-ok, ha jól emlékszem, maximum négy. (Nem néztem utána, annyira nem is lényeges most a pontos szám. A gyakorlatban én eddig maximum 3 node-ra épülő clusterrel találkoztam.) Hogyan nézett itt ki a HA?

  • Ha kidőlt a közös diszk, vagy akár csak a közös diszken lévő quorum, akkor összedőlt a cluster is. (Hányszor hallottam már olyanról, hogy valaki megörült, hogy milyen sok hely van a Q: meghajtón és elkezdett fájlokat másolni rá. Aztán amikor megtelt és lehalt a cluster, akkor meg volt csodálkozás.)
  • Ha node dőlt ki, akkor amíg volt másik node, addig nem volt baj. A cluster működéséhez elég a diszk (quorum+adat) és egy node.

A Windows Server 2003 SP1 után kijött egy patch, mellyel a termék már ismerte a File Share Witness technikát. Ez volt az első lépés a demokrácia irányába. A Windows 2008 Server ezt már helyből tudja, sőt ki is bővítette – de erről majd később.

Az Exchange természetesen igyekezett kihasználni az új játékszert. Az FSW megteremtette a lehetőséget a logshipping elven működő clusterezési technikák előtt. Pontosabban, a logshipping lokális és standby módban megy mindenféle clusterezés nélkül, csak a CCR-hez kell az FSW. De ahhoz nagyon.
Igaz, ez azért elég korlátozott rendszer. Például maximálisan két node lehet. Azaz ha van egy FSW és a két node, akkor kapunk egy három komponensből álló rendszert, ahol kettőnek mindig működnie kell, hogy a rendszer egésze is működjön.
Vegyük észre, hogy mekkora különbség ez az SCC-hez képest. Ott ugyanis a qourumnak mindenképpen működnie kellett. Itt már csak egy szavazásra egyszerűsödött le a helyzet: a játékosok felénél többnek (min. 50.000000001%) élnie kell ahhoz, hogy a cluster működjön.

Exchange 2010-et már csak Windows Server 2008-ra telepíthetünk. Csakhogy itt már nem csak egy szimpla FSW van a spájzban, hanem jóval több alapanyagból főzhetünk.

  1. Node Majority
    Csak a node-ok játszanak, más nem. Ha a felénél több él, akkor működik a cluster.
  2. Node and Disk Majority
    Bejön a képbe egy ún. witness disk. Ez az a merevlemez, amelyiken a quorum található. Innentől kezdve a játékosok száma megnő eggyel.
  3. Node and File Share Majority
    Ez a korábbi FSW. A quorum nem diszken lakik, hanem kikerül egy megosztásba és ez a megosztás (witness share) is belép a játékosok közé.
  4. No Majority
    Gyakorlatilag a korábbi SCC modell. A quorum diszk az adu ász, mely mindent visz.

És mindemellett a node-ok száma maximum 16 lehet.

Lássuk, mi jön ki ezekből az alapanyagokból.

Az Exchange 2010-ben a quorum diszket, mint olyat, kidobták. Így a négy lehetőségből rögtön kiesik kettő, marad az 1 és a 3.
Nagy kérdés, hogy ezek közül mikor és melyiket alkalmazzuk? A válasz az, hogy felejtsük el. Egész egyszerűen ezt nem mi fogjuk eldönteni.

Miért?
Elmagyarázom.

Legyünk egy izgága Exchange rendszergazdák. Éppen most döntötte el a cég, hogy a magas rendelkezésreállású Exchange 2007 CCR rendszert lecseréli egy szintén magas – sőt, ha lehet, akkor még magasabb – rendelkezésreállású Exchange 2010 rendszerre. Rutinból elkezdünk rajzolni: akkor lesz egy FSW a Hub Transport szerveren és – mivel itt már lehet – legyen akkor 3 node. Mert minél több node, annál nagyobb a biztonság. Megtervezzük. Megcsináljuk. Üzemel.
Aztán egyik nap kidől az egyik node. A szempillánk sem rebben. Éppen a darabokra szerelt gépben turkálunk, amikor valaki véletlenül kirúgja a másik node 220-as csatlakozóját a falból. Csak kacagunk rajta. Egészen addig, míg egy óra múlva munkakönyvvel a zsebünkben repülünk kifelé az ablakon.

Mi is történt?

Van négy játékos: 3 node és 1 FSW. Kidől egy node. Megvan a többség? 3:1, azaz igen. Kidől még egy. Most megvan? 2:2. Mennyinek kell lennie a többségnek? Min. 50.000000001%-nak. Ez bizony nincs meg.
Azaz vetettünk a céggel még egy plusz vasat súlyos milliókért és egy fikarcnyival sem lett megbízhatóbb a rendszerünk – hiszen ha belegondolunk, a 2 node + 1 FSW rendszer is pont egy node kiesést bírt el. Mindezt wálság idején. Nyilván kirúgtak.

Következő munkahelyünkön egyszer csak azt a feladatot kapjuk, hogy bíráljuk el egy külső konzulens ajánlatát. Átfutjuk és egyből kiszúrjuk, hogy az illető úgy képzelte el a magas rendelkezésre állású Exchange 2010 rendszert, hogy abban 3 node van.
– Hah! – rontunk be Vezérigazgató Bálinthoz – Ez a konzulens egy idióta sarlatán! Abszolút felesleges pazarlás 3 node-ból álló clustert tenni az Exchange 2010 alá!

Ezzel rögtön két hibát követtünk el. Egyrészt nem tudtuk, hogy a konzulens a vezérigazgató unokaöccse. Másrészt szembesítés után a konzulens higgadtan, okosan elmagyarázza, hogy ő úgy képzelte, miszerint az Exchange cluster Node Majority quorum modellt használna, azaz a négy játékos közül az FSW-t hagyná el. A plusz node-nak pedig nem a node szintű redundancianövelés a célja, hanem az adatbázis szintű redundanciáé. Ráadásul ha 3 node-ot használ, akkor nem kell méregdrága (DAS) diszktömb a node-ok mellé, hanem egyszerű, RAID vezérlő nélküli vincseszterek is megteszik, melyeket itt lent a Közértben lehet venni kilóra. Ezzel nem csak ezt érik el, hogy a 3 node olcsóbb lesz, mint a kettő(1), hanem sokkal olcsóbbak lesznek a későbbi bővítési lehetőségek is, feltéve, hogy a Közértben nem fogy el a lemez.

Ezek után Bálint bólint – és már megint repülünk.

Nos, pont azért, hogy ne rúgjanak ki olyan sok Exchange rendszergazdát, a fejlesztők úgy döntöttek, hogy kiveszik a döntést a humanoidok kezéből. Amikor összerakunk egy DAG-ot, akkor páratlan számú node esetén automatikusan Node Majority tipusú cluster jön létre, páros számú node esetén pedig Node and File Share Majority tipusú. Természetesen a váltás dinamikus, ahogy bővítem vagy szűkítem a DAG-ot, úgy változik automatikusan a modell is.

(1) Természetesen ez csak nagy adatbázisok esetében igaz. De mikor nem nagy egy Exchange adatbázis? Különösen akkor, ha az Exchange 2010-ben levették róluk a féket és azt mondták a postafiókoknak, hogy szaporodjatok, sokasodjatok és töltsétek be a Földet?

Az IPv6 és az Exchange 2010 románca

Egy újabb bájos jelenség. Dave Goldmann címlistamágus blogjában olvastam egy aranyos sztorit.

Az Exchange 2010 ugye már csak Windows Server 2008 oprendszerre megy fel. Ez a windows viszont már helyből beépített IPv6 tudással települ fel. Ez az emberek egy részét nem szokta zavarani – de a szerverüzemeltetők között akad rendesen paranoiás alak is, akik úgy vélik, hogy amire nincs szükség, az ne is legyen fent. És kiveszik a pipát az IPv6 checkbox elől.

Nos, ők járnak úgy, mint David. Az Exchange 2010 szerverük harakirit követ el.

Tapétamániákusok, figyelem!

A TechEd-en egy előadáson tette ki az elóadó – Charlie Chung – ezt az ábrát egy ppt slide-ra. Én úriemberként csak diszkréten csikorgattam a fogamat: normális vagy, barátom? Egy ilyen bonyolult ábrát kivetíteni? Hát emellett akár fel is olvashatnád visszafelé az Alice Csodaországban-t (úgy sem lenne több értelme), akkor sem figyelne senki arra, miről is beszélsz. Egy ilyen bonyolult, ellenben roppant fontos ábra láttán mindenki igyekszik pillanatok alatt minél többet felszívni belőle. Dehogyis jut ilyenkor agysejt az előadó szövegének dekódolására.

Tiszta szerencse, hogy a Microsoft elérhetővé tette mindkettő diagramot a neten. Tehát mindenki, akit érint, mindenki, aki éppen nem tud milyen háttérteret a Windows képernyőjére, innen le tudja tölteni az Exchange 2010 Transport Server szerkezeti diagramjait.

Suta konzol visszalő

Ez az utolsó sajtcetli – és ez most tényleg az.

Ha már annyira leírtam a menedzsment konzolt, hadd említsek meg róla egy pozitív dolgot is. Tudtátok, hogy a 2010-es EMC-be már több Exchange organizációt is fel tudunk venni? (Feltéve persze, hogy megvan hozzá a jogosultságunk és fizikailag is elérjük a szervereket.)
Ez persze eddig még nem egy nagy kunszt.

Bravúrszám akkor lesz belőle, amikor kiderül, hogy az így bekonnektált organizációk között grafikusan tudunk postafiókokat mozgatni.

Nem részletezem. Tessék végigondolni.

OWA

Nejem, amikor meglátta a monitoromon az akronimhalmazt, ennél az egynél jelzett be boldog sikkantással, hogy végre egy, melyet ismer. Nem akartam elvenni a kedvét, de a helyzet az, hogy ez az OWA már nem a jól ismert régi OWA.

Kezdjük ott, hogy már a rövidítés sem ugyanazt takarja: Outlook Web App. Oké, tudom, nem ettől szoktunk a nadrágba pisilni.
Az átnevezés mögött viszont egy komoly változtatás van.

Nagyítás

Nagyítás

A felső kép – az URL-ből is látszik – az OWA képernyőjének fejlécét mutatja. Az alsó kép pedig az ECP fejlécét.
Hasonlít? Ja. És akkor ahhoz mit szólsz, hogy az OWA webalkalmazásból az ‘Options’ linkre kattintva átmész az ECP-be, az ECP-ből pedig a ‘My Mail’ link az OWA-ba tesz át? Külön bejelentkezés nélkül? Gyakorlatilag folyamatosan tudod váltogatni, hogy melyik alkalmazásban mit csinálsz – olyan szinten, hogy egy idő után össze is mosódik, hogy most melyikben vagy. Mindegy. Outlook Web App – és ez betakarja mindkettőt. Én például elsőre külön felvettem a kedvencek közé mindkét linket – aztán egy idő után már meg se néztem, melyikre kattintok. Mindegy.

Formulázva ez így nézne ki:

OWA(Outlook Web App) = OWA(Outlook Web Access) + ECP.

A képlet jobb oldalán álló ECP-ről már írtam, most az ugyanazon oldalon álló OWA-ról kellene. Csakhogy a probléma ugyanaz, mint korábban az ECP-nél is. A termék újdonságairól írni nem lehet – csak demózni, elmutogatni azokat. Nem is akarok most ebbe mélyebben belemenni, egyszerűen csak felsorolok néhányat:

Házirendből konfigurálható

Nagyítás

Ez abszolút új. Gyakorlatilag sebészi pontossággal tudjuk szabályozni, hogy weben keresztül mely részeit használhatják a felhasználók a levelezőrendszer szolgáltatásainak. A képen éppen egy olyan házirendet láthatunk, amelyikben letiltottam az autosignature használatát. Lehetőségből pedig van bőven, a gördítősávból látható, hogy nem is fértünk bele egy ablakba. (Azért ilyenkor el tudnék beszélni azzal a GUI-ból felmentett szerencsétlennel, aki szerint a mai képernyőfelbontások mellett is van értelme átméretezhetetlen ablakokat kitenni a képernyőre.)
Természetesen a lehetőségek nemcsak házirend formájában érhetők el, beállítgathatjuk postafiók szinten is.

Böngészőfüggetlen

Erről már volt szó korábban, Ajax (Asynchronous JavaScript and XML) azért kell.

Conversation View

Nagyítás

Ezt már egyszer próbáltam megmutatni, de 800*600-ban nem igazán sikerült. Nagyobb felbontásban azért már jobban látszik. Egész pontosan a kép jobb oldaláról beszélek, ott látható, hogy az a levél, amelyre a középső panelen ráálltam, milyen láncba illeszkedik. Tessék észrevenni, hogy az alsó levelet a ‘Sent Items’-ből vakarta elő, a felette lévő levelet viszont már az ‘Inbox’-ból… azaz tényleg képes mutatni az egész levelezési szálat. Mint a Gmail. 😛

Chat

Igen, tényleg van… de csak akkor, ha van OCS2007 szerverünk és össze van lőve az Exchange rendszerrel is.

Filterek, kibővített helyzetérzékeny menük

Ez úgy ránézésre nem nagy dolog… de praktikus. Egyfelől gyorsan tudunk váltani nézetek között, másfelől gyorsan tudjuk elérni az új rendszer extra szolgáltatásait is.

Közepes bizalom

De jó is lenne néha.

Mit értek ez alatt?

Minden cégnek van holdudvara: partnerek, vendorok, ügyfelek. (Nyuszi barátai és üzletfelei.) Olyan szervezetekről van szó, amelyekkel sűrűn kell kommunikálnunk. Annyira nem bízunk meg bennük, hogy beengedjük őket a saját informatikai hálózatunkba – de borzasztó jó dolog lenne, ha látnánk egymás címlistáit, illetve a megbeszélések szervezéséhez szükséges free/busy adatokat.

Ehhez kellene kitalálni valami korlátozott megbízhatóságot használó modellt.

Először nézzük meg, milyen lehetőségeink vannak most.

  • Inter-Org Replication Tool, a free/busy információk szinkronizálásához: határozottan bonyolult eszköz, ráadásul teljes trustot igényel az AD-k között.
  • GalSync a címlisták szinkronizálására: ez egy MIIS/ILM szerveren alapuló címlista szinkronizáció, mely szintén nem egyszerű és borzasztó drága. Viszont nem igényel trust-ot.

Most pletykálok. Van egy multi ügyfelünk, ahol amerikai kezdeményezésre minden országban elkezdték a fenti két eszköz rendszerbeállítását, nyilván amerikai központtal. Kábé három éve. Kezdtük a Galsync-kel. Már majdnem működik. Az Inter-Org Replication Tool bevezetése pedig még a tervezésnél sem jár.

Nem valami biztató. Ehelyett született meg az ún. Federation Trust kapcsolat.

Nagyítás

Már megint a felhő. Most mondd azt, hogy a Microsoft nem veszi komolyan a cloud computing-et. 🙂

Miről is van szó? Van a felhőben valahol egy Microsoft Federation Gateway szerver. Amikor közepes megbízhatóságú kapcsolatot szeretnék, akkor fogom magam és hozzácsatlakozok ehhez a szerverhez, egy Federation Trust kapcsolattal. Ez a kapcsolat tanúsítvány alapú, maga a cert az Exchange szervert igazolja. (Ennek komoly tanúsítványnak kell lennie, a sajátot nem fogadják el.) Az üzletfeleim szintén kiépítenek ilyen Federation Trust kapcsolatokat. (Sőt, nemcsak ők, hanem számomra vadidegenek is, nyilván.) Majd ha ez kiépült, akkor organizáció szinten hozok létre ún. sharing policy-ket, melyekben megadom, hogy:
a. Kire vonatkozzon?
b. Mit engedek neki.

Gyakorlatilag ennyi. Én még azért elfilózgattam a világ furcsaságán: bizalomról van szó, bizonyos szintű bizalmas kapcsolatok kiépítéséről – és rögtön az első lépésben fogalmam sincs róla, hol van a Microsoft Federation Gateway. Ugyanis ez egy olyan paraméter, amit nem lehet megadni. Az Exchange 2010 beépítetten tudja.