Information Store - Exchange Blog

Microsoft Exchange Server ahogy én látom

Exchange ActiveSync–de hol a hiba?

Exchange ActiveSync–de hol a hiba?

  • Comments 7
  • Likes

Egy napon belül kétszer kellett elmesélnem ezt a történetet két kollegámnak. Egy héten belül háromszor mondtam el és két ügyfelemnél is előjött ez a kérdés így ma megfogadtam, hogy a nap addig nem ér véget számomra, amíg ezt nem írom ki magamból. Miért? Azért, hogy hatékonyabb lehessek, elég legyen csak az újabb érdeklődőket a blogomra irányítani. Illetve azért, hogy a telefonok kiválasztásának amúgy sem egyszerű szempontrendszerét további dimenzióval egészíthessem ki.

Egyszer volt, hol nem volt, volt egyszer egy Exchange Server. Az Exchange Server adatbázisában volt sok postaláda. A postaládákban sok elem. A zsebünkben pedig volt egy telefon. Néhány kollegámnak eszébe jutott a ’90-es évek végéhez közeledve, hogy a leveleket, a naptárat a névjegyeket egyaránt szinkronizálhatnánk a postaládánkkal. Ráadásul úgy, hogy ahhoz nem kellene asztali gép, nem kellene Outlook kliens. Interneten keresztül, közvetlenül az Exchange Server-el. Így aztán sok fejlesztés után elkészült, dobozoltuk, majd árultuk a Microsoft Mobile Information Server (MMIS) terméket. Létezett ebből a termékből több verzió is, a történelmét ennek nem írom most le, de egy évtizede már létezett (a Microsoft-ban az első nagyobb munkáim egyike az MMIS-hez kapcsolódik). Az MMIS termékben már az ActiveSync protokollt használtuk arra, hogy a mobil készülék és az Exchange kiszolgáló között szinkronizálni tudjuk az adatokat. Nincs ez másként ma sem. Az ActiveSync protokoll azóta a szokásos evolúción ment keresztül. Fejlődött, bővült, szabványosodott. Ahogy ez lenni szokott. Az MMIS termék megszűnt, de nem jogutód nélkül, bekerült a termék az Exchange kiszolgálóba így lényegesen egyszerűbbé téve a szlogen megvalósítását: „Information Anytime, Anywhere, from any device”. Tehát a protokoll szabvány lett. Adott egy szabványos protokoll, de mire jó ez? Valójában az ActiveSync protokoll arra és csak arra szolgál, hogy a telefonkészüléken futó e-mail kliens és az Exchange kiszolgáló között az adatátvitelt biztosítsa. Hogy egy telefonkészüléken futó levelezést, naptárkezelést, névjegykezelést futtató alkalmazást a protokollon keresztül megkapott adatokkal mit csinál valójában, azokat hogy dolgozza fel, az már nem a protokoll hatókörébe tartozó kérdés. Napjainkban ez sok problémát okoz és az idő előre haladtával egyre többet fog okozni.

Réges-régen ez nem jelentett problémát. Mert az ’ActiveSync = Windows Mobile’ készülék egyenlet igaz volt. Ma azonban ez már nem igaz. A készülékek százai, a gyártók tucatjai, az operációs rendszerek sokaságában ott van az ActiveSync protokoll. De mindegyik készüléken ugyanaz a levelező kliens fut? Mindegyik készüléken ugyanazok a funkciók vannak implementálva? Az összes készüléken a levelező kliens hibátlanul működik? A válasz sajnos az, hogy nem. Problémák tucatjait okozza az, hogy a különböző eszközök másként kezelik a naptár, az email, a névjegy bejegyzéseket a postaládánkban, majd a szabványos és helyesen működő protokollon keresztül az szinkronizálódik a postaládánkba. A protokoll a hibás? Csak annyira, mint amennyire egy képzeletbeli világban a a postás hibáztatható lenne azért, ha egy meggondolatlan pillanatban írt levelet elviszi a postára, majd egy másik postás azt a címzetthez juttatja. Ahogy a postás sem hibáztatható, az ActiveSync protokoll sem vonható felelősségre. Csak teszi a dolgát és továbbítja a tartalmat a készülék és az Exchange Server között.

image

„Technikaibban” megfogalmazva, a „Business Logic Layer” készülékenként eltér. Az elemek kezelésének implementációja ebben a rétegben történik. Így ha ebben a rétegben hiba van, nem konzisztens, akkor annak hatása súlyos és érzékelhető. Minél több „Business Logic Layer” implementáció létezik, annál több problémával szembesülhetünk és sajnos szembesülünk is. A leggyakoribb problémák:

  • Nem szinkronizál a készülék
  • Elvesznek, összekeverednek a névjegyek
  • Naptárbejegyzések területén a legkülönlegesebb hibák tapasztalhatóak (n meghívott után eltűnnek, ismétlődő bejegyzések módosításakor nem konzisztens, hogy melyik bejegyzésen mit állítunk)
  • Levelek újraküldése örökké
  • Nem megy az AutoDiscover
  • Stb.

A biztonságtechnika számomra az örök kedvencek egyike. Így nem állhatom meg, hogy legalább egy gondolat erejéig ne térjek ki ennek a biztonsági vonzatára. A biztonsági beállításokat minden esetben a Business Logic Layer hajtja végre. Az Exchange Server az ActiveSync protokollon keresztül elküldi a biztonsági házirendet (PIN kód kötelező, PIN kód hossza, Local Wipe stb.). A Business Logic Layer azt a protokollon keresztül fogadja, majd:

  • a helyes implementáció a beállításokat alkalmazza és visszajelzi a protokollon keresztül az Exchange kiszolgálónak, hogy sikeresen alkalmazta azt.
  • a helytelen implementáció fittyet hány a házirendre, de visszajelzi a protokollon keresztül az Exchange kiszolgálónak, hogy sikeresen alkalmazta azt.

Kell-e ezt tovább magyarázni? A különbség a két metódus között nem csak látszat.

A megoldás önmagát kínálja. Ráadásul több is létezik. A leggyorsabb és legegyszerűbb megoldás az, hogy készítsünk egy a megfelelőséget tanúsító nyílt programot. Normalizáljuk a készülékeken futó alkalmazásokat és tudjuk biztosítani azt, hogy az egyes implementációk, bár eltérőek, mégis egy közös funkciókészletet biztosítanak és azt ráadásul helyesen teszik. Mi, a Microsoft ezt a programot létrehoztuk. A program neve: Exchange ActiveSync Logo Program. A komplikáltabb elméleti megoldásról egy későbbi bejegyzésben majd írok.

Így biztosak lehetünk abban, hogy a logo program alatt működő készülékek nem fognak problémát okozni a rendszereinkben, a postaládáinkban, az értékes információinkban. Minden más lutri. Nem szeretnék kitérni a gyártókra és azok megoldásaira. Beszéljenek a tények a program oldalán. Eszközválasztásnál vegyük fel ezt is a szempontrendszereink közé.

Zárszóként csak annyit, hogy ha furcsa jelenségeket látunk a postaládánkban, vagy furcsa jelenségeket jelentenek be hozzánk, akkor gyanakodjunk, és ne hagyjuk ki a számításból a telefonkészülékek vizsgálatát sem. A következtetést mindenki vonja le maga. A gyártók pedig javítsák ki a termékeiket!

Comments
  • Igen, ez egyértelműen a gyártók sara, és amíg az IT nem tud oda hatni, hogy legalább a szolgálati mobil eszközök beszerzésénél korlátokat állítson, addíg az Exchange rendszergazdáknak ezzel sok baja van. Különösen, ha a felhasználó "messze" van, és tulajdonképpen vajmi keveset tud a telefonjáról. Ilyen esetekben (Zolin kívül) ez a cikk sokat segített: technet.microsoft.com/.../bb232162.aspx

  • Ezt a linket érdemes még megnézni: social.technet.microsoft.com/.../exchange-activesync-client-comparison-table.aspx

    Kiváló összefoglaló arról, hogy melyik funkciót melyik eszközben implementálták. A Product Group frissíti, így elég hiteles!

  • Illetve még egy adalékot hozzátennék Cérna. A cikkben elvan rejtve egy gondolat. Egy gondolat arról, hogy a jövőben ez másként is mehet majd...

    Az a trend, hogy az IT a végfelhasználók eszközére nem tud "oda hatni" egy teljesen valós trend. Úgy hívják, hogy IT Consumerization (klikk: letmebingthatforyou.com)

    Ez a trend azt mutatja, hogy a dolgozók egyre inkább a saját eszközeikkel szeretnék elérni az információkat, szélsőséges esetekben a cég már nem is vásárol eszközt, rábízza azt a felhasználóra. Ha alaposan végig gondoljuk akkor ez akár egy költségcsökkentő tényező is lehet a cégek életében.

  • Nem t'om. Tudni kéne, hogy mennyit kell majd az IT - nek invesztálnia ahhoz, hogy felkészítse vállalatát arra, hogy mindeféle ketyerével egyformán elérjék a felhasználók, mondjuk a postafiókjukat. (Tudom, vigyük be inkább a felhőbe ...). A gyártók persze gondolom már véresre dörzsölték a tenyerüket ...

  • Nem azert mondom, de szerintem hatekonyabb lenne a biztonsagi rendszer, ha nem biznank azt a kliensszoftverre, hanem az exchange szerver tartatna be. Ugyanis minden programozo, es minden rendszergazda tudja azt az oroktol fogva kozismert tenyt, hogy a felhasznaloban megbizni nem szabad. Nem kicsit nem szabad megbizni, hanem egyaltalan nem. Igenis kovetelje vissza a szerver az authorizacios hash-t, hagyja jova, es csak akkor szolgalja ki a klienst, ha tenylegesen megtortent az authentikacio. Ez kutya kotelessege lenne, es nem az ugyfeloldalra bizni, hogy hat akkor most ugye te authentikaltal? Messzirol jott ember azt mon, amit akar.

    Ja, es a kommentboznal nem jelenik meg a scrllbar, ezzel kene valamit csinalni... :)

  • hron84: köszi az értékes hozzászólást. Szóval ami azt illeti egyet kell hogy értsek veled. Igaz ami igaz, valóban lehetne itt szigorú a szerver oldal. De a jelenlegi kliens oldali alkamazások implementációjáz figyelembe véve nem hiszem, hogy reális elvárás volna. Számos és számtalan EAS protokoll funkciót ma sem implementálnak helyesen a gyártók. A ki nem mondott robotos implementációnak ma is komoly problémái akadnak a 2010 SP1-es szerverekkel. Hmmm. Akkor majd pont ezt az új szigort fogják helyesen implementálni? Szóval osztom, igazad van. De bízz bennünk és várjuk ki a végét. Fogok erről én itt még beszélni és nem is olyan sokára.

    Ami a gördítősávot illeti, szintén helyes az észrevétel. Jelzem bent.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment