Üzleti kommunikáció a levelezésen túl

Üzleti kommunikáció a levelezésen túl

Tartalom 3

Új igények egy levelező rendszerrel szemben Nagyobb postaládák kisebb költséggel Kiszolgáló-független adatbázis-kezelés

4

Olcsóbb diszk-alrendszerek mellett is magas teljesítmény

5

Optimalizált adatbázis-karbantartás Outlook RPC csatlakozását is a Client Access szerep látja el Rugalmasan kialakítható fürtözés, akár két kiszolgálóval

6

Hatékonyabb, olcsóbb üzemeltetés

7

Olcsóbb mentés új paradigma alapján

8

Hatékonyabb grafikus rendszergazda felület, önkiszolgáló lehetőségek

9

Új lehetőségek az Exchange Management Shellben Finoman beállítható rendszergazda jogosultságok

10

Továbbfejlesztett kézbesítési szabályok Moderált kézbesítés

Könnyebb kezelhetőség Webes hozzáférés többfajta böngészőn és kézi eszközökön

11

Rövid szöveges üzenetek (SMS) is részei a levelezési infrastruktúrának Nagytömegű levél hatékonyabb kezelése: párbeszéd-nézet, mappa- és elemszintű archiválás

12

Nem kézbesíthető, vagy tévesen címzett levelek küldésének megelőzése Szervezetek között megosztható naptárak

13

Egyesített üzenetkezelés

Biztonság, kevesebb leállás Információk védelme, céges és jogi szabályozás betartatása

14

Folyamatos rendelkezésre állás, hibatűrő kézbesítési folyamat

15

Postaláda-mozgatás Levelek archiválása, megőrzése, visszakeresése

16

Egyedi elemek megőrzése, helyreállítása

17

Több postaláda tartalmának egyidejű keresése Technikai és pénzügyi előnyök

Szakértő: Soós Tibor (PowerShell MVP, Microsoft Certified Trainer) Exchange szakértő és oktató az Exchange 4.0 verzió óta

Új igények egy levelező rendszerrel szemben Változik a világ, és vele változnak a levelező rendszerrel szemben támasztott követelmények is. A ’90-es évek elején az volt a fő kérdés, hogyan lehet továbblépni a megosztott fájlrendszer alapú levelezőrendszerekből egy olyan területre, ahol a felhasználó nem okozhat kárt a többiek – mai fogalmaink szerint elenyésző mennyiségű – levelezésében. Napjainkban már jóval összetettebb igényeink vannak. Nem csupán azt várjuk el egy intelligens levelező rendszertől, hogy többfajta eszközről és platformról állandóan elérhető legyen, segítsen a leveleink rendszerezésében, törlésében, hanem a kommunikáció egyéb módjaival is hatékonyan működjön együtt. Ráadásul az egyre több funkció megvalósításához se kelljen költségesebb beruházásba kezdenünk, sőt, az igazi az lenne, ha az új rendszer olcsóbb lenne a korábbinál, és az üzemeltetési költségek is csökkennének. A felhasználók által kapott és küldött e-mailek száma folyamatosan növekszik. A levélszemét hatékony kiszűrését már nem is kell említeni, mint alapkövetelményt. Amire emellett vágyunk, hogy a levelek feldolgozásában is kapjunk egyre több segítséget, és ezzel időt spóroljunk. Természetesen a rendszer működjön biztonságosan: álljon folyamatosan rendelkezésre, még meghibásodás esetén se vesszen el információ. Őrizze az üzletmenet számára fontos leveleket, még akkor is, ha esetleg a felhasználó kitörölte ezeket. A Microsoft Exchange Server 2010 fejlesztésében a fenti szempontok és még sok más egyéb irányelv is szerepet játszott, a következőkben ezekről olvashatnak.

Nagyobb postaládák kisebb költséggel Egy rendszer kialakításának költségeit leginkább az elvárt funkciók és a szolgáltatások által megkövetelt igények határozzák meg. Még ha jól mérjük is fel a kívánalmakat, akkor is dilemmába eshetünk: ami ma elégnek tűnik, az fél év, egy év múlva már esetleg kevésnek bizonyulhat. Mikor járunk jobban? Ha most tervezzük nagyobbra a rendszert, vagy ha később áldozunk arra jelentős költséget, munkát és időt, hogy bővítsük azt? Az Exchange Server 2010 – a korábbi verziókhoz képest – ebben nagy előrelépést jelent, hiszen rugalmasan bővíthető. Indulunk egy egykiszolgálós rendszerrel, majd ha kell, áttérhetünk két kiszolgálóra, és később adatbázis-replikációval biztosíthatjuk a helyreállíthatóságot. Az igények növekedésével pedig egyszerűen kialakíthatjuk – a meglevő kiszolgálók bővítése, újratelepítése nélkül! – a fürtözött hibatűrő rendszerünket. Mikor kinőjük a két kiszolgálónkat, könnyen tehermentesíthetjük azokat a postaláda-adatbázisok részbeni átstrukturálásával egy harmadik Exchange Serverre. Ráadásul most már egy Exchange Server 2010 Enterprise kiszolgálón akár 100 adatbázist is üzemeltethetünk. Nézzük meg részletesebben azokat a technológiai és architekturális újdonságokat, amelyek megengedik ezt a rugalmasságot, és a hatékonyabb hardver-erőforrás felhasználás segítségével lehetővé teszik nagyobb postaládák üzemeltetését kisebb költségek mellett!

Kiszolgáló-független adatbázis-kezelés Amikor megnyitjuk az Exchange Server 2010 Management Console-ját, akkor az egyik legszembeötlőbb változás, hogy az üzenetadatbázisokat nem a kiszolgálók szintjén állíthatjuk be, hanem az Exchange szervezet szintjén. Ez a rendszergazda felületen is azt kívánja szimbolizálni, hogy most már egy adatbázis nem kötődik szorosan ahhoz a kiszolgálóhoz, ahol létrehozták, hanem szabadon átvihető egy másikra, ha az erőforrások optimálisabb felhasználása ezt megkívánja.

Microsoft Exchange Server 2010 3

Olcsóbb diszk-alrendszerek mellett is magas teljesítmény Az Exchange adatbázis-kezelésének mélyén a legfontosabb változtatások azt a célt szolgálják, hogy minél kevesebb írás-olvasási műveletet hajtsunk végre másodpercenként. Ezáltal ugyanannyi postaláda kiszolgálásához egyszerűbb diszk-alrendszer is elég, vagy ha már van egy meglevő diszk-alrendszerünk, akkor ezzel több felhasználót tudunk kiszolgálni, és sokkal nagyobb postaládát biztosíthatunk a felhasználóinknak azonos teljesítmény mellett. Az Exchange Server 2003-hoz képest 90%-kal csökkent az IOPS igény a jelenlegi verzióban! Hogyan lehet csökkenteni az IO műveletek számát? Nagyon egyszerű: használjuk a diszket a leghatékonyabban: szekvenciálisan! A diszkeken történő írás és olvasási műveletek akkor a leggyorsabbak, ha nem kell az író-olvasó fejet állandóan pozícionálni, hanem folyamatosan tudjuk az adatblokkokat beolvasni vagy kiírni. Ezt az ideális módot próbálja megközelíteni az Exchange Server 2010 adatbázis-kezelője: nagyobb adatbázis-lapokat használ, a korábbi 8 KB helyett 32 KB-ot, és az adatbázis szerkezete is úgy módosult, hogy a beolvasandó adatbázis-lapok egymás után következzenek a diszken. Mindezek következtében egy átlagos diszk sebessége is kielégítő, azaz a sebesség miatt nem kell csíkkészletbe kötött meghajtókat alkalmazni. Ez azért jó, mert sokkal egyszerűbbé válik a rendszer tervezése és karbantartása: 1 adatbázis – 1 diszk. Természetesen ez nem hibatűrő, arra majd az Exchange Server 2010 adatbázis-replikációs technológiáját fogjuk felhasználni, tehát nem kell drága RAID megoldást alkalmaznunk, hanem már olcsóbb, könnyen hozzáférhető meghajtót is használhatunk. Ez a megközelítés manapság egyre népszerűbb, az ilyen JBOD (Just a Bunch Of Disks) megoldás költségtakarékosan továbbfejleszthető és karbantartható.

A rendszerkialakítás rugalmassága A teljesítménynövelés miatt a tároló alrendszerek szélesebb köre alkalmazható:

Storage Area Network (SAN)

Közvetlenül csatlakoztatott SAS meghajtók

Közvetlenül csatlakoztatott SATA meghajtók

JBOD SATA (RAID nélkül)

• 90% IOPS csökkentés az Exchange Server 2003-hoz képest • Kiegyenlített IO profil

E2003

• Meghibásodás elleni védelem

E2007 E2010

Read IOPS

4 Microsoft Exchange Server 2010

Write IOPS

Optimalizált adatbázis-karbantartás Korábban fejtörést okozott az Exchange rendszerek tervezésekor, hogyan ütemezzük a különösen diszk-intenzív feladatokat, hogy azok a levelezési szolgáltatást ne zavarják. Ilyen feladat az adatbázis-lapok ellenőrzése, az elévült elemek törlése, az üres adatbázis-lapok összeszervezése és egymásutániságának beállítása. Az Exchange korábbi verziói mindezeket a funkciókat az „Online maintenance”, azaz az online karbantartás alatt végezték, ami így elhúzódhatott. De az is előfordulhatott nagy adatbázisok esetében, hogy az üzemidőn kívüli időszak nem volt elegendő ezen teendők mindegyikének befejezésére, már csak azért sem, mert ebbe az időszakba kellett a mentésnek is beleférnie. Az Exchange Server 2010 a diszk-intenzív feladatokat folyamatosan végzi „ráérő” idejében. Az üzemidőben folyamatosan hasznosítja az üresjáratokat, ami által az online karbantartási időszakra maradó tevékenységek száma lecsökken, hamarabb befejeződnek, azaz nagyobb adatbázisokat és postaládákat tudunk üzemeltetni.

Outlook RPC kiszolgálását is a Client Access szerep látja el Az Exchange Server 2007 verziót is már szerepekre optimalizáltan lehetett telepíteni: Mailbox, Hub Transport, Client Access, Unified Messaging és Edge szerepeket lehetett külön-külön bekapcsolni. Ám még nem volt tökéletes a szétválasztás, mert a postaláda-adatbázisok kezelését végző Mailbox szolgálta ki közvetlenül az Outlook ügyfeleket. Az Exchange Server 2010-ben a szerepek „profiltisztítása” tovább folytatódott, a Client Access funkció fogadja immáron az Outlook RPC kéréseit is. Ennek több előnye van: egyrészt kevesebb terhelés jut így a Mailbox-ra, másrészt, ha átmozgatjuk a felhasználó postaládáját az egyik Exchange Mailbox szerepről egy másikra, akkor az Outlooknak erről igazából nem is kell tudnia, hiszen az továbbra is ugyanahhoz a CAS kiszolgálóhoz csatlakozik. A CAS „okos”, így csak akkor csatlakozik majd az új helyen levő postaládához, ha az már átmásolódott, így lehetővé válik az online postaláda mozgatás, ami szintén megkönnyíti a rendszer rugalmas átalakítását, illetve a nagyméretű postaládák kezelését. Mihelyst a CAS már az új helyről szolgálja ki az átmozgatott postaládát, a régi helyen törölhetővé válik.

Rugalmasan kialakítható fürtözés, akár két kiszolgálóval Az Exchange Server 2003-ban a magas rendelkezésre állást az Exchange kiszolgálók olyan fürtözésével oldották meg, ahol a fürt tagjai közös diszk-alrendszeren lévő adatbázishoz kapcsolódtak. Ennek az architektúrának azonban volt egy gyenge pontja: a közös tároló. Még ha az architektúrát alkotó meghajtókat hibatűrő módon alakították is ki, a közös tároló vezérlőjének meghibásodásával a teljes rendszer leállt. Ráadásul az ilyen fürtképes hardverek meglehetősen borsos áron szerezhetők be. Az Exchange Server 2007-ben jelentek meg az adatbázisok tranzakciós naplójának másolására épülő hibatűrést és/vagy magas rendelkezésre állást biztosító megoldások: Local Continuous Replication (LCC – egy kiszolgálón belüli több adatbázis-példány építése), Standby Continuous Replication (SCR – egy másik kiszolgálóra épített adatbázis-másolat) és Cluster Continuous Replication (CCR – fürtbe kötött kiszolgálók közti adatbázis-másolás). Az LCC és SCR lehetőségnél a meghibásodás után rendszergazdai beavatkozásra volt szükség az ép adatbázis-példányra történő átálláshoz. A CCR megoldásnál az áttérés automatikus volt, viszont ez csak 2 kiszolgáló fürtbe kötését tette lehetővé. Ráadásul itt szükséges volt az Exchange alatt található Windows Servert fürtszolgáltatással ellátni, amihez külön szaktudás kellett. Ez utóbbi megoldást drágította, hogy a CCR tagok csak Mailbox szerepet futtathattak, tehát a 2 fürttag mellett még legalább egy harmadik Exchange kiszolgáló kellett, hogy a kötelező szerepek mindegyike rendelkezésre álljon. Az Exchange Server 2010-ben a szakemberek egyesítették a CCR és az SCR szolgáltatás minden előnyét! Az új, magas rendelkezésre állást biztosító technológiát Adatbázis Rendelkezésre-állási Csoportnak (Database Availability Group – DAG) nevezzük. Ennek következtében nem kell az Exchange kiszolgálók alatt futó Windows Servereknek fürtbe kötve lenniük. A magas rendelkezésre állást biztosító képességet teljes egészében az Exchange Server 2010 oldaláról lehet beállítani (de azért fürtképes Windows Server verziót szükséges használnunk), valamint további Exchange szerepeket is képes ellátni a fürtözött adatbázis-kezelésen kívül.


Elsőként a legfontosabb adatbázisok számára kell létrehozni másolati példányokat a DAG-ban résztvevő kiszolgálókra (maximum 16 gép). Idáig ez a korábbi SCR-nek felel meg. Ha nincs szükségünk a teljes kiszolgáló automatikus átállására, akkor itt meg is állhatunk; a másolt adatbázisaink máris hibatűrők lettek, meghibásodás esetén automatikusan megtörténik az átállás. Ha ez nem elég, és a magas rendelkezésre állást a teljes kiszolgálóra is biztosítani szeretnénk, akkor az összes adatbázisról készítünk másolatot a DAG valamely tagjára, és ha bármi probléma adódik bármelyik kiszolgálóval, akkor a rendszer automatikusan aktiválja az összes adatbázis legmegfelelőbb tartalékját. Ez a megoldás azzal az előnnyel is jár, hogy ha csak egy adatbázis hibásodik meg, akkor nem kell az adott fürttagon található összes adatbázist másik tagon aktiválni, mint a korábbi CCR esetében, csak a meghibásodottat kell költöztetni, ami jóval gyorsabb átállást tesz lehetővé. Természetesen ez a megoldás akkor is működik, ha egy teljes kiszolgáló esik ki a fürtből, ekkor az összes adatbázis költözik, méghozzá – ha több maradék fürttagunk is van – az adatbázisok költöztetése egyenletes lehet a tagok között, így mindegyikükre csak kisebb plusz terhelés jut. Még egy nagy könnyebbség, hogy a replikáció nem RPC kommunikációval, hanem egy megadható fix porton történik, így tűzfalon keresztül, telephelyek közt is nagyon egyszerűen beállítható.

Exchange Server 2010 architektúra Telephely Felhasználó

Központ

yfél Min den üg on PC a CASi el keresz tül ér át a postaládáj

Client Access Server

DB 1

Mailbox Server 6

DB 5

nnyen Failover kö hető zt es rj te ki között telephelyek

Mailbox Server 1

Mailbox Server 2

Mailbox Server 3

Mailbox Server 4

Mailbox Server 5

DB 1

DB 4

DB 2

DB 5

DB 3

DB 2

DB 5

DB 3

DB 1

DB 4

DB 3

DB 1

DB 4

DB 2

DB 5


DB 3

intű Kiszolgálósz lése failover keze l Exchan ge-e

szintű Adatbázis failover

Hatékonyabb, olcsóbb üzemeltetés Az eddigiekből már láthattuk, hogy az Exchange Server 2010 technológiai újításainak köszönhetően egyfelől olcsóbb hardver segítségével is kialakítható a kívánt teljesítmény, másfelől a rugalmasabb, az igények változását jobban követni képes architektúra olcsóbb rendszer-átalakítást és bővíthetőséget eredményez. Azonban a beruházási költségekhez képest az üzemeltetési kiadások általában magasabbak, így fontos megnézni, hogy ezen a téren milyen változások vannak.

Olcsóbb mentés új paradigma alapján Elsőként kapcsolódjunk az imént befejezett témához. A hibatűrést biztosító adatbázis-replikáció tulajdonképpen helyettesítheti a mentést is! Akár az adatbázis-, kiszolgáló-, vagy adatközpont meghibásodás ellen védelmet jelent, ha van kellő számú tartalékunk mind adatbázisból, mind kiszolgálóból. Ráadásul ez a „mentés” gyors helyreállítást tesz lehetővé, csak aktiválni kell egy jó adatbázis-példányt. Mentést azonban nemcsak meghibásodásból való helyreállítás céljára készítünk, hanem a felhasználók vagy a rendszergazdák által elkövetett véletlen (vagy rosszindulatú, szándékos) törlések orvoslásánál is. Vajon ezt hogyan oldja meg az adatbázis-replikáció? Több postaládát és sok üzenetet érintő „rontás” elleni védelemként beállíthatunk a replikált adatbázis-példányoknál több napos késleltetést a változások integrálásában. Ilyenkor a „forrás” adatbázis-példány változásai, bár átmásolódnak a kópia kiszolgálókra, de ott nem épülnek be az ottani adatbázis-példányba, csak – akár – hetekkel később. Így lesz egy olyan adatbázis-példányunk, amit elő tudunk venni, és csak addig „építjük fel”, amíg még tartalmazza az elveszett elemeket. Ebből már ki tudjuk szedni az eltűnt elemeket, amelyek ezután egyszerűen betölthetők az „igazi” adatbázisba. Ha csak néhány elem vagy postaláda régebbi állapotát akarjuk visszaállítani, erre a később ismertetésre kerülő törölt és felülírt elemek megőrzését biztosító „Dumpster 2.0” áll rendelkezésünkre. Természetesen ezek a lehetőségek nem teljesen egyenértékűek a hagyományos mentés által nyújtott szolgáltatásokkal, de ha jól megtervezzük az adatbázis-replikációt és az elemek megőrzését, akkor a szükséges SLA-kat teljesíthetjük. Ennek csak a nagyobb diszk-terület (ami lehet egyszerű, olcsó SATA diszk is) az ára, míg megspórolhatjuk a hagyományos mentési rendszerünket: szalagos egységet, média-kezelést, helyreállítás miatti időkiesést, mentési szoftvert és a mentés alatti többlet IO terhelést. A mentési folyamat felügyeletének és a hozzá szükséges szakértelem plusz költségeiről nem is beszélve.

A szakértő véleménye „Végre nem kell előre eldönteni, hogy milyen hibatűrő és magas rendelkezésre állást biztosító módszert választunk, ezt folyamatosan igazíthatjuk az igényekhez, ráadásul egyszerű, olcsó hardverrel.”

Az Exchange Server 2010 mentési stratégiája Adatvédelem beépítve Gyors helyreállítás

Exchange 2010 képesség

HW/SW meghibásodás Adatközpont meghibásodás

Adatmegőrzés

Véletlenül törölt elemek

Adatbázisreplikáció

Előnyök

• Gyors helyreállítás • Adatredundancia

Elemek helyreállíthatósága

• Garantált elemmegőrzés

Postaládasérülés

Késleltetett adatbázis-másolat építés

• Adatbázis korábbi állapota is létezik

Hosszú távú adatmegőrzés

Archiválás és elemmegőrzés

Rendszergazdai hiba

• Alternatív postaláda régi adatok tárolására


Hatékonyabb grafikus rendszergazda felület, önkiszolgáló lehetőségek Egy új levelező rendszernél a sokasodó funkciók mellett biztosítani kell az üzemeltetők számára az egyszerű és hatékony felügyeletet. Az Exchange Server 2010 számos újdonsággal segíti a használót a felügyeleti eszközök terén is. Az Exchange Server 2007 volt az első kiszolgálószoftver, amelynek a kezelése a PowerShell parancssori környezeten alapult. Még a grafikus Exchange Management Console használata mögött is valójában PowerShell utasításokat hajt végre a rendszergazda, ez nem változott azóta sem. Újdonság azonban, hogy a „mögöttes” PowerShell utasítások naplózhatók, így a rendszergazda részletesen dokumentálhatja és visszatekintheti, hogy milyen beállításokat is végzett a rendszeren. A korábbi verzió használatának tapasztalatai alapján a következő beállítási lehetőségek immár a grafikus felületen is elérhetők: • az Exchange titkosított hálózati kommunikációihoz felhasznált tanúsítványok kezelése, • az erőforrás-postaládák működésének, automatizmusainak részletes beállítása, • több objektumon egyszerre végzett művelet elvégzése, • diagnosztikai naplózás beállítása. Ezen kívül új lehetőség, hogy a rendszergazda közvetlenül küldhet levelet bármelyik felhasználónak az Exchange Management Console segítségével. Az Exchange rendszer felhasználói támogatásával foglalkozó szakemberek gyakran olyan kérések megoldásán kénytelenek dolgozni, amelyeket tulajdonképpen a felhasználók maguk is meg tudnának oldani, ha lenne hozzá megfelelő eszközük. Mint például: • egy levél útjának követése, hol tart a kézbesítés, megérkezett-e a levél, • terjesztési listák létrehozása, tagságának módosítása, • személyes adatok módosítása, aktualizálása. Ezen feladatok végrehajtására egy új eszköz, az Exchange Control Panel áll rendelkezésre. Ezen keresztül – jogosultságtól függően – a fenti műveleteken kívül a rendszergazda is hozzáfér az Exchange rendszerrel kapcsolatos beállításokhoz, és a leggyakoribb műveleteket ezen keresztül is el tudják végezni. Ez a felület az Outlook Web Access felülethez hasonlóan egy weboldalon keresztül érhető el, így nagyon egyszerűen, szoftver telepítése nélkül is használható.


Új lehetőségek az Exchange Management Shellben Az Exchange Server 2010 beállításának alapja a PowerShell 2.0, aminek az egyik legfőbb újdonsága a távoli végrehajtás lehetősége. A távoli végrehajtást alkalmazza mind a grafikus rendszergazda felület, mind az Exchange Management Shell. Ez számos előnyt jelent számunkra: • nem kell telepíteni a rendszergazda eszközkészletet a rendszergazda munkaállomására a shell futtatásához, • a távoli futtatás során a https protokoll segítségével kommunikál a munkaállomás a kiszolgálóval, ami „tűzfalbarát”, • lehetőség van a rendszergazda jogosultságainak megfelelő parancskészlet biztosítására. Ezen kívül számos új tevékenységet tudunk automatizálni PowerShell parancsok segítségével: • több mint 20 diagnosztikai parancs, melyekkel a rendszer állapotát tudjuk felmérni, • postaládák mappáinak kezelése, • postaláda-mappák jogosultságának kezelése, • postaládák „Beérkező üzenetek” szabályainak kezelése, • jelentések készítése nyilvános mappák adatairól, • adatbázis másolatok és passzív fürttagok aktiválása, • több postaládán keresztüli keresés, • jelentés készítése a kézbesítés késleltetéséről.

A szakértő véleménye „Az önkiszolgáló tevékenységek lehetőségével a támogatási költségek jelentősen csökkenhetnek. Természetesen ennek ára van: a felhasználók képzése, de ez mindenképpen megtérülő befektetés.”

Finoman beállítható rendszergazda jogosultságok A korábbi Exchange Server verziókban néhány szint állt rendelkezésünkre a különböző rendszergazda csoportok jogosultságainak szabályozására. Ez egy sok kiszolgálós és nagyszámú, különböző szintű hozzáférést igénylő rendszer esetében nem biztos, hogy kellő részletességgel engedte beállítani a jogosultságokat. Az Exchange Server 2010-ben egy új hozzáférési modell alapján állíthatjuk be a rendszergazdai jogosultságokat, a „Szerepalapú hozzáférés-vezérlés” (Role Based Access Control) segítségével. Az Exchange-el kapcsolatos összes beállítási művelet külön építőelemként szerepel egy-egy hozzáférési szint kialakításánál. Ezt – miután végső soron az Exchange beállítását PowerShell parancsok végzik – ezen utasítások és különböző paramétereik hozzáférésének lehetőségével lehet engedélyezni vagy tiltani. Például, ha valakinek olyan jogosultságot akarok adni, hogy csak postaládák beállítására legyen képes, akkor kikeresem azt az előre definiált szerepet, amely tartalmazza az ezzel kapcsolatos PowerShell parancsok futtatásának lehetőségét (ha ez a szerep nem fedi az igényemet pontosan, akkor létrehozhatok testre szabott saját szerepet is), és ezt rendelem hozzá az illetőhöz.

A szakértő véleménye „Az új RBAC modell segítségével most már bármely résztevékenység végzéséhez éppen elegendő jogokat is kioszthatunk, így nem kell túl sok jogosultságot kiosztani vagy nagyjogosultságú rendszergazdára bízni az apróbb feladatokat.”

Ilyen finomhangolt jogosultságok segítségével adhatunk a felhasználók számára is az önkiszolgáló tevékenységek végrehajtásához szükséges jogokat, mint például személyes adataiknak frissítését vagy levelezési beállításaik változtatását, amit az Exchange Control Panel webes felületen végezhetnek el.


Továbbfejlesztett kézbesítési szabályok Az Exchange Server 2007-ben jelent meg a kézbesítési szabályok (Transport Rule) létrehozásának lehetősége. Ezen szabályokkal, illetve a megadott feltételeknek megfelelő üzenetekkel automatikusan végrehajtódó tevékenységet tudunk ellátni. Ilyen lehet a levél blokkolása, szöveg hozzáillesztése a levélhez, vagy akár egy további személy beillesztése a címzettek közé. Az Exchange Server 2010-ben továbbfejlesztett kézbesítési szabályokkal találkozunk. többfajta feltételt hozhatunk létre: a címzett vagy a feladó Active Directory-ban tárolt adataira is tudunk feltételt fogalmazni, vagy a csatolmány tartalmában előforduló kifejezésekre és kifejezés-mintákra (regex). Például csak azokra a levelekre legyen érvényes a szabály, amelyek feladójának az osztály (Department) paramétere egy adott érték, illetve a csatolmányban olyan kifejezés szerepeljen, ami három számból, kötőjelből, majd hat számból áll.

A szakértő véleménye „Végre a céges házirendnek megfelelő, központilag beállított aláírást tehetünk minden kimenő levélhez!”

Ugyanígy, a szabály által végrehajtott tevékenységben is hivatkozhatunk Active Directory mezőkre: intelligens, központilag szabályozott aláírást tehetünk minden levél végére, ami például tartalmazza a levél írójának a nevét, beosztását, e-mail címét.

Moderált kézbesítés Fontos lehet, hogy bizonyos címzettek részére ne lehessen bármit küldeni. Új lehetőség az Exchange Server 2010-ben, hogy ezen „védett” címzetteket moderálttá lehet tenni, azaz a részükre küldött levelet egy vagy több moderátor kapja meg, és csak valamelyikük jóváhagyása után továbbítódik a levél az igazi címzett részére. Ez tipikusan nagy terjesztési listáknál jön jól, hogy a tévesen elküldött, vagy a céges levelezés házirendjébe nem illeszkedő, esetleg nagyméretű levelek ne terheljék a rendszerünket.

Könnyebb kezelhetőség Az eddig ismertetésre került újdonságok jórészt a rendszergazdák, a hardver beszerzésével és a rendszer tervezésével foglalkozók életét könnyítik meg. Fontos azonban, hogy egy-egy újabb verzió a végfelhasználók munkáját is elősegítse, és a laikusok is egy-egy verzióváltás mellé álljanak, nehogy úgy tűnjön, a rendszer frissítése csak a szakemberek kedvéért történik. Természetesen az Exchange Server 2010 e tekintetben is hordoz számos újdonságot.

Webes hozzáférés többfajta böngészőn és kézi eszközökön Talán az egyik legszembeötlőbb újdonság, hogy a webes hozzáférést biztosító Outlook Web Access – új nevén Outlook Web App –, immár nemcsak Internet Exploreren, hanem a Firefox és Safari böngészőkön is fut. Ezzel a jelenleg használt böngészők 94%-a számára válik lehetővé a kényelmes levelezés böngésző segítségével. A webes felületen kívül az Exchange kiszolgálókhoz kézi eszközökkel is lehet csatlakozni. Nem csupán Windows Mobile eszközöket használhatunk erre a célra, hanem számos egyéb gyártó megoldását is. A Windows Mobile eszközök használata esetében nézzük, mik a legfontosabb újdonságok: • Over-the-air updates: az Exchange Server 2010 képes a hozzá csatlakozó Windows Mobile 6 eszközök operációs rendszerét frissíteni a mobil adatkapcsolaton keresztül. • A hangposta üzenetek szöveges előnézete olvasható Windows Mobile eszközökön is, és azonnal lejátszható a hangüzenet. • Címzettek nevének kliensprogramok között megosztott gyorsító tárazása, mellyel gyorsabban lehet kiválasztani a címzetteket. • Párbeszéd-nézet és szabályok, melyekkel jobban átláthatók az üzenetek a mobil eszköz kisebb képernyőjén is; teljes párbeszédfolyamokra és az oda tartozó későbbi üzenetekre is beállítható törlés és mappába irányítás.


Rövid szöveges üzenetek (SMS) is részei a levelezési infrastruktúrának Elektronikus kommunikációnkhoz tartozik az SMS küldése is. Ezek megírása a telefonbillentyűzeten, olvasása a kis képernyőn, és tárolása a telefon korlátos memóriájában nem igazán teszi ideális vállalati kommunikációs eszközzé. Az Exchange Server 2010 ezen is segíteni kíván. Ha a felhasználónak Windows Mobile alapú okostelefonja van, és engedélyezett számára az ActiveSync adatszinkronizáció, akkor SMS üzeneteit az Outlook 2010 program vagy az Outlook Web App felület segítségével olvashatja és küldheti el. Ezzel az SMS-ek is részévé válnak az Exchange rendszer kommunikációjának. A rövid üzenetek pedig elmenthetők az Exchange postaládába, később visszakereshetők, vagy hagyományos e-mailbe beidézhetők. Magát az SMS-t tehát a felhasználó okostelefonja küldi és fogadja, a szerkesztésben és megjelenítésben segítenek az Exchange Server 2010 ügyfélprogramjai.

Nagytömegű levél hatékonyabb kezelése: párbeszéd-nézet, mappa- és elemszintű archiválás Az elektronikus levelek forgalma évről évre nő. Nem ritkán annyi levelet kapunk, hogy egy nap nem elég minden levélbe bepillantani, így napról napra növekszik a számunkra jórészt ismeretlen tartalmú levelek száma. Ez semmiképpen sem jó, hiszen jelentős üzleti veszteség érhet bennünket, ha ebben a levéltengerben elsikkad egy fontos üzenet. Hogyan tud ebben segíteni nekünk az Exchange Server 2010, illetve az ügyfélszoftverei: az Outlook 2010 és az Outlook Web App? Az első eszközünk a levéldömping csökkentésére az új párbeszédnézet. Ebben a nézetben a levél egy csoportban jelenik meg a válaszokkal – legyen az akár általam, vagy bármelyik címzett által írt válasz. A korábbi változat csak egy adott mappából szervezte csoportba az összetartozó leveleket, az új nézet viszont minden mappából összeszedi azokat. Ezekkel a párbeszéd-füzérekkel egyetlen mozdulattal különböző tevékenységeket végeztethetünk: kitörölhetjük a leveleket, figyelmen kívül hagyhatjuk innentől kezdve az adott témába érkezőket, átirányíthatjuk a vonatkozó üzeneteket egy mappába. Mindezt akár az új Outlook 2010, a Windows Mobile készülék vagy az Outlook Web App felületén megtehetjük. Nagytömegű levélről beszélve nem feledkezhetünk meg arról sem, hogy mit tehet a felhasználó akkor, ha a postaládája lassanként megtelik. Akármennyire is olcsó a JBOD tároló rendszerünk, valamilyen ésszerű méretkorlátot adnunk kell a felhasználóinknak. Korábban a felhasználók számára a PST (Personal Store – személyes tárhely) fájlokba történő „archiválás” lehetősége állt rendelkezésre, amellyel a régi leveleket ki lehetett vonni a postaládából. Az Exchange Server 2010 erre új megoldást talált, az „igazi” postaláda mellett egy archív postaláda létrehozására is van lehetőség, amelyet a „Levelek archiválása” részben ismertetünk.


Nem kézbesíthető, vagy tévesen címzett levelek küldésének megelőzése A levelek mennyiségének csökkenését segíti, hogy nem küldünk olyan levelet, amelynek címzettje valamilyen oknál fogva nem elérhető, vagy pedig valószínűsíthető, hogy tévedésből küldenénk el a levelet. Ezen esetekben az Exchange Server 2010 megpróbálja figyelmeztetni a felhasználót a levél elküldése előtt. Ez a figyelmeztetési rendszer a MailTips nevet kapta, és a következő esetekben ad riasztást: • túl sok a címzett, • a címzett házon kívül van, • a címzett moderált, • túl nagy a levél, • a címzett postaládája tele van, • olyan üzenetre akarunk „Válasz mindenkinek” módon válaszolni, ahol mi rejtett címzettek voltunk,

A szakértő véleménye „Kíváncsian várjuk, hogy a MailTips mennyiben fogja megváltoztatni a felhasználók levelezési szokásait, vajon kevesebb tévesen elküldött levél lesz-e?”

• egyedi MailTip lett beállítva az adott címzetthez. Ezeket a figyelmeztetéseket az Outlook 2010 és az Outlook Web App is megjeleníti és segít elkerülni a kézbesíthetetlen jelentések elküldését.

Szervezetek között megosztható naptárak Az Exchange Server 2010-ben lehetőség van különböző Exchange szervezetek közti rendelkezésre-állási információk megosztására anélkül, hogy ezeket a szervezeteket Active Directory szinten bizalmi kapcsolatba kelljen vonni. Ehhez szükséges a Microsoft Federation Gateway, mint „bizalom-közvetítő”, amely tanúsítványok segítségével teremt bizalmi viszonyt különálló szervezetek között. Kiválaszthatjuk, hogy a „bizalmi felhőbe” lépett szervezetek közül melyekkel szeretnénk naptárinformációkat cserélni, ezeket engedélyezhetjük az Exchange rendszerünkben. Azt is beállíthatjuk, hogy milyen mértékű információ-megosztást engedélyezünk, illetve mely munkatársaink rendelkezésre-állási adatait osztjuk meg. Ennek az új eljárásnak nagy előnye, hogy nincs szükség címtár-információk cseréjére a két szervezet között, ha a Microsoft Federation Gateway felé sikeresen azonosította magát az Exchange kiszolgálónk. Ezután közvetlenül felvesszük a másik Exchange rendszer kiszolgálójával a kapcsolatot és lekérjük az ottani felhasználó elfoglaltsági adatait. Ezeket végül az Outlook vagy az Outlook Web App képes megjeleníteni a felhasználónk számára, így a találkozók szervezése sokkal könnyebb és eredményesebb lesz.


Egyesített üzenetkezelés Az Exchange Server 2010 egyik funkciója a Unified Communication, azaz az egyesített üzenetkezelés, amely a bejövő üzeneteink körébe vonja a hangposta üzeneteket is. Le kell mondanunk az Exchange Server 2007-ben alkalmazott faxkezelésről, viszont a következő újdonságok jelentek meg: • Hívásfogadási szabályok: az egyesített üzenetkezelésbe bevont felhasználók saját hangmenü-struktúrát építhetnek fel, amellyel a hívó felet elirányítják a hangpostához, másik személyhez vagy valamilyen egyéb telefonszámra. • Voice Mail Preview: értelmezi a hangüzenetet, szöveges formában beilleszti abba a levélbe, amelyben a hangfájlt kézbesíti. Ez leegyszerűsíti a hangüzenetek feldolgozását. Sajnos ez a funkció még magyar nyelven nem érhető el. • Message Waiting Indicator: külön jelzést kapunk, ha új hangüzenet érkezett. • Értesítést kérhetünk SMS-ben, ha nem fogadott hívásunk vagy hangüzenetünk volt. • RMS szabályokkal védhetőek a hangüzenetek is. • Hangvezérléssel küldött e-mail küldhető több címzettnek (ez a funkció magyarul jelenleg még nem érhető el).

Biztonság, kevesebb leállás A levelezőrendszerek kialakításának további fontos pillérei a biztonság és megbízhatóság, az Exchange Server 2010 számos új megoldást kínál ebben a körben is.

Információk védelme, céges és jogi szabályozás betartatása Az Exchange Server 2007 nagy újdonsága volt, hogy a rendszergazdák kezébe adott több eszközt, amelyekkel szabályozni lehetett, mi történjen levelezőrendszerünk belsejében: ki mit küldhessen kinek. Ez az Exchange Server 2010-ben a további lehetőségekkel egészült ki: • Finomabban hangolható kézbesítési szabályok: már nem csak közvetlenül a feladóra lehet alkalmazni azokat, hanem a feladó különböző Active Directory-ban tárolt paramétereire is, mint például az osztályára vagy főnökére, illetve a csatolmányban található valamilyen szövegmintára. • A kézbesítési szabályokkal Active Directory Rights Management Serverben megfogalmazott jogosultság-sémákat az üzenetekhez lehet rendelni, amelyekkel ekképpen biztosítható a levelek titkosítása, valamint megvonható a levelek továbbításának vagy kinyomtatásának joga. • AD RMS sémák üzenethez rendelése már az Outlookban, a levél elküldése előtt, Outlook Protection Rule-ok segítségével is megtörténhet, például „titkos” fejlesztésen dolgozó munkatársak mindegyikének levele automatikusan RMS védelemmel lesz ellátva.


Folyamatos rendelkezésre állás, hibatűrő kézbesítési folyamat Számos technológiai újítás biztosítja az Exchange levelező rendszer folyamatos rendelkezésre állását. Az új Database Availability Group alapú fürtözött adatbázis-replikáció adja a rendelkezésre-állás alapját. A meghibásodott adatbázisról való gyors átállást szolgálja a passzív példányokon folyamatosan készenlétben tartott gyorsító-tár (warm cache), ami azt eredményezi, hogy amikor a pas�szív kópia aktivizálódik, akkor nem üres memóriatartalommal – „álmosan” – kezdi el kiszolgálni a kéréseket, hanem rögtön úgy tesz, mintha eddig is aktív lett volna. Az adatbázis-példányok közti átváltás viszont erőforrás-igényes feladat és lehetőség szerint kerülni kell. Ezt szolgálja az adatbázisok önjavító funkciója. Az adatbázis-lapok hibajavító kóddal rendelkeznek. Ha netán akkora mértékű a hiba, amelyet a kóddal nem lehet kijavítani, az Exchange Server 2010 képes a passzív adatbázis-példány megfelelő lapját az aktívra átmásolni, vagy fordítva, az aktív példánnyal is kijavíthat passzív példányt. Amennyiben a javítás sikerül, nem kell átállni másik adatbázis-példányra. Ha mégis átállásra kényszerülünk, annak hatékonyságát növeli a tény, hogy fejlettebb lett az ún. „Transport Dumpster” algoritmusa. Az adatbázis átálláskor információveszteség léphet fel, mivel az aktuálisan kezelt tranzakciós naplófájl esetleg meghibásodhat. Ilyenkor a kieső információkat az Exchange a kézbesítés folyamatába beillesztett átmeneti tárolókból nyeri vissza, ezek a Hub Transportban található Transport Dumpsterek. Az Exchange Server 2010-ben ezek kezelése hatékonyabb, csak azok az üzenetek maradnak benne, amelyek még nem épültek adatbázisba, ezért átálláskor sokkal kisebb mennyiségű üzenetet kell megvizsgálni és újraküldeni, azaz gyorsabb lesz a javítási folyamat. De nem csak a postaláda-adatbázisok profitálnak az adattárolás technológiai újdonságaiból. Hasonló újításokat alkalmaz a Hub Transport kézbesítési adatbázisa is. Ez szintén kevesebb IO művelettel oldja meg a feladatát, ezért nagyobb terhelést képes elviselni, ami által kisebb az esélye az ún. terheléses támadások elleni védelmi mechanizmusok beindulásának, amelyek szolgáltatás-kiesést eredményezhetnek. A levelek biztonságos célba érésének érdekében egy új várakozási sor, a „Shadow Redundancy”, azaz árnyék-redundancia került bevezetésre. Ebben a Hub Transport a sikeres levéltovábbítás után is megőrzi a levelet, majd rendszeresen megkérdezi a kézbesítési lánc következő pontján található kiszolgálótól, vajon sikerült-e továbbítani a levelet, vagy sem. Ha a válasz igen, akkor kitörli a levelet a várakozási sorból. Amennyiben nem érkezik válasz a következő pont meghibásodása miatt, a levelet újraküldi egy alternatív kézbesítési pont felé (ha van), vagy vár addig, míg ez a kézbesítési pont ismét működik, és akkor újraküldi a levelet. Ha a Hub Transport kiszolgálók adatbázisa megsérül, akkor az automatikusan új adatbázist hoz létre. Ennek az előnye, hogy nem kell a rendszergazdának beavatkozni a Hub Transport felélesztésébe, és a „Shadow Redundancy” képességgel együtt hibatűrő kézbesítési folyamat áll a rendelkezésünkre.


Postaláda-mozgatás Az egyik szempont, amely a postaládák és a hozzájuk kapcsolódó adatbázisok maximális méretét befolyásolja, hogy mennyi ideig tart a postaládák mozgatása. Manapság – éppen a megnövekedett levélmennyiség miatt – elvárható, hogy a postaládák mérete legalább 300-500MB legyen. Ám ha nem akarjuk felhasználóinkat személyes üzenettár-fájlok (PST) használatára kárhoztatni, akkor ennél is nagyobb, 2-10GB mérettel kell számolni. Korábban a postaládák mozgatása offline művelet volt, azaz a felhasználó automatikusan lecsatlakozott a postaládájáról a mozgatás idejére. Bár lehetett a mozgatást üzemidőn kívülre ütemezni, nem volt arra lehetőség, hogy megtudjuk, például a mozgatott 200 postaláda közül Kovács Béla postaládája mikor kerül sorra. Az Exchange Server 2010-ben a postaládák mozgatása online műveletté vált. Addig, amíg az utolsó bájt át nem kerül az új adatbázisba, a „régi” postaláda van használatban. Ha elkészült a másolat, az automatikusan átirányítódik az új felhasználó postaládájába, és a régit törölni lehet. Ezáltal tetszőlegesen mozgathatókká válnak a postaládák, nem kell részletes terveket készíteni, a felhasználók nem esnek ki a munkájukból. A nagyobb postaládák mozgatása sem jelent gondot, így egyszerűbbé és olcsóbbá válik az üzemeltetésük.

Levelek archiválása, megőrzése, visszakeresése Az elektronikus levelek manapság már hasonló jogi nyilatkozatnak számíthatnak, mint a papír alapú szerződések, ugyanazokkal a jogi következményekkel, ezért fontos, hogy egyenértékű védelmet és kezelést biztosítsunk számukra. Jó lenne minimum 5 évig megőrizni az e-mailjeinket, és védelemmel ellátni véletlen törlés ellen. Ennek a levelek által elfoglalt tárterület szab csupán határt. Amennyiben elfogadható árú háttértárakkal tudjuk bővíteni az Exchange kiszolgálóinkat, akkor ez kevesebbe kerül, mint az esetlegesen elveszített levelek által okozott kár, vagy az ügyfélgépeken tárolt PST fájlokban való keresgélés költsége. Milyen hátránnyal jár, ha 5-10 évnyi levelet őriz a felhasználók postaládája? Elsősorban ennyi levél rendezése és a köztük való keresgélés gondot okozhat. A korábban használatos PST-be történő archiválásnak az volt az egyik előnye, hogy leválasztotta a régi leveleinket a „frissekről”. Másik előnye, hogy a gyorsító tárral (OST fájl) üzemeltetett Outlook-oknak a PST archívumban tárolt üzeneteket nem kellett az OST-ben is tartaniuk, így kisebb volt az OST fájl, ami a kliens-oldali műveletek sebességét felgyorsította. A PST fájlok viszont sérülékenyek, egyetlen kliensgépről és csak Outlookkal voltak elérhetők. Bár az Exchange Server 2010-ben az adatbázis-kezelés hatékonyságának növekedésével és az olcsó adattárolás miatt nagyméretű postaládákat is üzemeltethetünk, mégis az ideális az lenne, ha a felhasználók képesek lennének megkülönböztetni az „aktuális” leveleket az „archiválttól”. Ebben a verzióban meg van az a lehetőség, hogy minden postaládához hozzárendelhetünk egy másodlagos, archív postaládát is – külön kvótával –, amit mind az Outlook 2010-ből, mind az Outlook Web App felületről elérhetünk. Ide mozgathatjuk a régi üzeneteket, kereshetünk benne, válaszolhatunk az itt tárolt üzenetekre. gyakorlatilag majdnem ugyanúgy viselkedik, mint az igazi postaláda. Ami lényeges különbség a kettő között: ide nem érkeznek új levelek és nem szinkronizálódik le a tartalma az Outlook gyorsító tárába (OST fájl). Sőt, ez az archívum is hibatűrő módon tárolódik, hiszen ez is az Exchange adatbázisban található, és az elsődleges postaládával együtt mozgatható. Az üzenetek archiválását a felhasználó manuálisan vagy automatikusan végezheti, a mappákhoz és egyedi üzenetekhez rendelhető archiváló szabályok alapján.


Egyedi elemek megőrzése, helyreállítása Az előbbiekben láthattuk, milyen előnyei vannak az archív postaládáknak, de azt tudnunk kell, hogy az ide került üzenetek nem élveznek különös védettséget, hiszen innen is ki lehet törölni azokat – bár nincs erre kényszerítve a felhasználó, mivel nem kell aggódnia a postaláda-kvóta miatt. Az információk megőrzését a „journaling” – azaz naplózás –, a korábban már említett „Dumpster 2.0”, a kézbesítési szabályok és az ún. „legal hold”, azaz a zárolás technológiája biztosítja az Exchange Server 2010-ben. • A naplózás (journaling) a korábbi verzióhoz képest annyit változott, hogy a rendszerben Rights Management Server segítségével titkosított, védett tartalmak titkosítás nélkül is eltárolódnak. Ennek köszönhetően a keresések és felderítések könnyebben végrehajthatók lesznek.

A szakértő véleménye „Az Exchange Server 2010 által kezelt személyes archívum lehetősége sok bosszúságtól és nehézségtől kíméli meg mind a felhasználókat, mind az üzemeltetőket.”

• A „Dumpster 2.0” biztosítja, hogy olyan helyre kerülhessenek a törölt és (újdonság!) módosított üzenetek, amihez a rendszergazda még hozzáfér, viszont a felhasználó már nem érhet el. Ráadásul a tárhelynek már külön kvóta is beállítható, így nem kell attól tartani, hogy a törölt elemek esetleg felemésztik azt. • A kézbesítési szabályok (Transport Rule) segítségével bizonyos személyek vagy bizonyos kulcsszavakat tartalmazó üzenetek átirányíthatók egy hosszú távú megőrzést biztosító postaládába.

A szakértő véleménye

• A zárolás (Legal Hold) egy új lehetőség. Bizonyos postafiókok zárolás alá vonhatók, amellyel az automatikus archiválás felfüggeszthető, és a felhasználó a zárolás tényéről értesítést kap. A törölt, módosított bejegyzései a „Dumpster 2.0”-n keresztül elérhetők a rendszergazdák számára, és a zárolás ideje alatt onnan nem törlődnek.

„A Dumpster 2.0 számos olyan lehetőséget nyújt, amire már régóta vártunk: kvótázhatóság, verziómegőrzés, felhasználó előli elrejtés.”

Bármelyik megőrzési technológiát választjuk, az mind felhasználható a véletlen törlés utáni helyreállításra is.

Elemek törlésének és helyreállíthatóságának architektúrája Exchange 2003/2007 ➊ A z üzenet kézbesítése

Postaláda

Exchange 2010 ➊ A z üzenet kézbesítése

Beérkezett üzenetek ➋ A z üzenetet törli a felhasználó

...

Beérkezett üzenetek ➋ A z üzenetet törli a felhasználó

Törölt üzenetek ➌ A z üzenet bekerül a „Dumpster”-be

Dumpster 1.0

Helyreállítható elemek

➍ A z üzenet kikerül az adatbázisból


Postaláda

... Törölt üzenetek

➌ A z üzenet bekerül a „Dumpster 2.0”-ba ➍ A z üzenet a felhasználó elől nem látható módon átkerül a rendszergazda által kezelhető „Törlések” tárolóba

Dumpster 2.0 Tartás 30 napig

Felhasználó által helyreállítható elemek Verziók Törlések ➎ A z üzenet kikerül az adatbázisból 30 nap után

Több postaláda tartalmának egyidejű keresése Ha a szervezet szintjén akarunk elektronikus levelezéssel folyatott kommunikációt felderíteni, akkor azt számos helyen kell keresni: több ember postaládájában, személyes archívumokban, törölt elemek között. Ha minden ilyen lehetséges hely az Exchange kiszolgálónkon van, akkor az jelentősen leegyszerűsíti a helyzetet. Ráadásul ilyen jellegű feladatokra az Exchange Server 2010-ben a laikusok számára is használható webes keresési felület áll rendelkezésre az Exchange Control Panel részeként, természetesen csak a megfelelő jogosultságok megadása után. Ez az ún. „Multimailbox Search” felület alkalmas számos keresőfeltétel megadására: ki a feladó és címzett, mely időintervallumban történt a kézbesítés, mely postaládában keresünk, milyen csatolmányokban. Ezen felül a keresés megadására használhatjuk az „Advanced Query Syntax” formátumot is, amit a Windows Desktop Searchben már megszokhattunk.

Technikai és pénzügyi előnyök Az Exchange Server 2010 üzleti előnyei Várható éves megtakarítás

Rugalmas és megbízható

Hozzáférés bárhonnan

Védelem és megfelelőség

• Nagyobb postaláda méret alacsonyabb költséggel • Alacsonyabb üzemeltetési és támogatási költségek • Rugalmas magas rendelkezésre állás és helyreállíthatóság

23%

• Funkciógazdagabb mobil hozzáférés • Levelek rendezésére fordított kevesebb idő • Önkiszolgáló és rendszergazda műveletek távolról

78%

• Alacsonyabb megfelelőségi and felderítési költségek • Információ-védelem alacsonyabb költségei • Egyszerűsített archiválás és megtartás

27%

TCO csökkenés akár 40%-kal Exchange 2003-hoz képest* *Forrás: nemzetközi felmérés 10.000 felhasználóval rendelkező szervezetek körében


A DVD tartalma • dokumentumok • screencast előadások • segédprogramok

© 2009 Microsoft Corporation. Minden jog fenntartva. Ez a dokumentum kizárólag tájékoztatási célokat szolgál. A Microsoft semmilyen kifejezett vagy vélelmezett garanciát nem vállal a jelen összefoglalóban szereplő információval kapcsolatban. A Microsoft, az Active Directory, a Microsoft Exchange Server 2010, a Microsoft Office, a Microsoft Outlook, a Unified Communication és a Windows Mobile a Microsoft vállalatcsoport védjegye.

Üzleti kommunikáció a levelezésen túl

Recommend Documents