Megjelent az Exchange 2007 SP1

A megjelenést nem kísérte hangos csinnadratta, pezsgődurrogás és tormbitaszó. Csak szépen csendben megjelent a hír és a letöltési link.

Annak, hogy ez így történt van némi történelmi előzménye. Lehet, hogy egykori történészként nekem kellene megírnom ezt a történetet, de inkább tegye ezt meg valaki, aki "sine irae et studio" tudja ezt megtenni.

Inkább végezzünk egy gyors leltárt, hogy mi minden is került bele végre az újabb változatba (és hogy miért csak most, azt egyelőre fedje jótékony homály).

Az egyes szerepkörökhöz nem köthető változás, hogy az Exchange 2007 SP1 már telepíthető Windows Server 2008-ra, illetve felügyelhető Windows Vistáról. A hírben nincsen semmi meglepő, hiszen a nyakunkon Windows Server 2008 bejelentése (kb. 12 hét van hátra) és a korai bevezetők, tesztelők részéről természetes igény, hogy az új platformon futtathassák levelezési rendszerüket is. A mondat magától értetődően azt is jelenti, hogy teljes (slipstream) telepítő készlettel állunk szemben ebben az esetben. A támogatott platformokból szinte automatikusan következik még az IPv6 kapcsolatok kezelése (hiszen mind a Vistában, mind a Windows Server 2008-ban natív módon benne van és nem is távolítható el), illetve a magas rendelkezésre állású megoldások (lásd geocluster-ek) immár nem korlátozódnak azonos alhálózatra.

A Unified Messaging néhány új protokollt (SIP URI és E.164) kapott, javítottak a hangminőségért felelős kodekeken, illetve megjelent a QoS támogatás, amivel ha megfelelően hosszú ideig járunk hálózatos kollégáink nyakára, akkor garantálhatjuk az UM sávszélességét.

A magas rendelkezésre állást biztosító megoldások között újdonság a Stand-by Continuous Replication. Ez tulajdonképpen Exchange-es log shipping, ahol a tranzakciós logokat egy stand-by kiszolgálóra tükrözhetjük (az adatbázis egy konzisztens példányát természetesen szintén át kell vinnünk a kezdet kezdetén), majd az ott futó Exchange azokat folyamatosan feldolgozza és naprakészen tartja a saját adatbázisát. Az elsődleges kiszolgáló hibája esetén egy Powershell script-tel valamennyi felhasználónkat átirányíthatjuk a készenlétben álló szerverre és nekiláthatunk a másik javításának.

Jogos lehet két kérdés:

1. miért nem áll át automatikusan a szolgáltatás a tartalék gépre?
2. miben különbözik ez az egész egy hagyományos fürttől?

A két kérdésre csaknem ugyan az a válasz: ez a megoldás nem a hagyományos értelemben vett fürt. Nincs közös storage, nincs heartbeat, sőt nincs telepítve a Cluster Services sem. Asszimmetrikusan feldolgozott tranzakció alapú megoldás ez, ami bónuszként viszont nem földrajzi hely függő. Így a tartalék gép lehet pl. egy másik számítóközpontban vagy másik telephelyen. Cserébe viszont a gépek nem nagyon tudnak egymásról, így az automatikus átbillentés is közvetítőt igényel, ami lehet pl. egy System Center Operations Manager. (Vagyis a SCOM figyelheti egy szintetikus tranzakció keretében az elsődleges Exchange elérhetőségét és futtathatja a Powershell scriptet automatikusan, majd értesít bennünket, hogy milyen akciót hajtott végre.)

A transzport szerepkör környékén a használhatóságot javító változások történtek leginkább. Alacsonyabbra kerül például a "back pressure" szintje, vagyis a rendszerünk ezentúl nem 4 GB maradék diszkkapacitásnál húzza meg a vészféket, hanem 500 MB-nál (nekünk viszont ennyivel rövidülhet a reakció időnk, hogy megoldjuk a hibát!). Az üzenetkezelésben javították a prioritások kezelését (vagyis tényleg az kap elsőséget a routing során, aminek magas a prioritása), és finomhangolhatjuk a site linkeket is (mekkora üzeneteket engedjenek át), amivel pl. megakadályozhatjuk, hogy a nagyobb méretű üzenetek egy 64 kbites linken tuszkolják keresztül magukat (így majd kerülő utat fognak keresni, akár több hop árán is).

Közkívánatra visszakerültek a Public Folderek felügyeletét segítő eszközök a konzolra, így a Toolbox-ból kezelhetjük már a nyilvános mappákat is. Ehhez kapcsolódóan megjelent a Public Folder Admin szerepkör, így a mappák kezelését kiadhatjuk más adminisztrátoroknak, anélkül, hogy kockáztatnánk a rendszer biztonságát.

Felhasználóink bizonyára szeretni fogják az Outlook Web Access-ben megjelenő fejlesztéseket (és nem elsősorban az XBox-os vagy Zune-os skin-ekre gondolok). Mostantól pl. szabályozhatják postaládájuk működését kiszolgáló oldali szabályokkal, amiket az OWA felületén keresztül állíthatnak be. Elérhetik a dumpster-t  - a Törölt elemek mögötti tárolót, ahonnét a menthetetlennek hitt üzenetek állíthatók vissza, ha jól konfiguráltuk a rendszerünket. A nyilvános mappák is elérhetők az OWA-ból anélkül, hogy erre a célra 2003-as Exchange-t tartanánk életben. Megjelent az Outlookhoz hasonló keresési funkció és a copy&paste a mappák között. Sőt, akár megosztások vagy Sharepoint site-ok dokumentumait nyithatjuk meg közvetlenül az OWA felületéről (persze csak ha jogosultsággal rendelkezünk).

Adminisztrátorok számára biztosan hasznos lesz a POP3 és IMAP elérés konfigurálására szolgáló konzol, a jogosultságok állítási lehetősége (Full Mailbox Access, Send as jogok beállítása, akár több felhasználóra is egyszerre) és a routing log viewer, amivel nemcsak lekérdezhetjük, hogy az adott kiszolgáló merre küldözgeti az üzeneteket, hanem akár a változásokat is követhetjük.

Régi kedvencünkről az exmerge-ről már régóta tudtuk, hogy támogatás nélkül ugyan, de működik az Exchange 2007 alatt is. Ha támogatott módon szeretnénk exportálni/importálni az egyes postafiókok tartalmát PST-be, akkor mostantól az export-mailbox és az import-mailbox Management Shell funkciók használhatók erre a célra.

Részletes lista a javításokról/újdonságokról: http://technet.microsoft.com/en-us/library/bb676323.aspx

A 32 (!) és 64 bites változat pedig letölthető innét:

http://www.microsoft.com/downloads/details.aspx?FamilyID=44C66AD6-F185-4A1D-A9AB-473C1188954C&displaylang=en&mdc_uxref=sl