Outlook profile, szerver név helyett GUID, hiba vagy nem?

Az egyik legnagyobb architektúrális változás az Exchange Server 2013-ban az a Front-End, Back-End kialakítás és az abból következo egyéb lényegi változások. Az egyik ilyen lényegi változás az, hogy az Outlook kliensek számára csak az Outlook Anywhere (leánykori nevéb RPC over HTTP) lesz elérheto. Nincs többi MAPI over TCP.

Az Outlook profilban lényegi változás nem történik. Továbbra is külön konfigurációs elem az Outlook Anywhere végpont beállításai valamint egy külön konfigurációs elem a postaláda szerverre vonatkozó információk. Ez teljesen logikus is. Valójában az Outlook Anywhere egy tunnel. A tunnelen belül érjük el az Exchange Server-t. Ebbol a magasságból nézve ez két külön kapcsolat (valójában sokkal több, de a konfiguráció nézopontjából ketto):

 

 

Exchange Server 2010 óta a postaláda akár 16 adatbázisban lehet. Habár ez nem tipikus, azonban a 2-3-4 másolat manapság itthon sem ritkaság. Ha egy postaláda összesen két adatbázisban van akkor az automatikusan azt jelenti, hogy potenciálisan két postaláda szerver szolgálhatja azt ki. Kérdés: melyik Exchange Server-t írjuk ilyenkor az Outlook Profil-ba? Ennek a feloldására szolgál a ClientAccess Array funkció az Exchange Server 2010-ben. Az egy AD telephelyen levo CAS szervereket egy logikai egységbe foghatjuk. Adhatunk ennek az Array-nek egy FQDN-t és beállíthatjuk azt mint Exchange Server. Ezzel a feladatot, hogy kitaláljuk éppen hol van felcsatolva az adatbázis áttoltuk a CAS szerverre. O azt okosan kitudja olvasni, megtudja állapítani és nem nekünk kell ezen a fejünket törni. Jó tudni, hogy Exchange adatbázisonként más végpontot konfigurálhatunk be. Az adatbázis RPCClientAccessServer tulajdonságával utasíthatjuk az Autodiscover szolgáltatást arra, hogy milyen Exchange Server végpontot küldjön vissza a kliensnek:

Ez az Exchange Server 2013-ban teljesen másként muködik. Kisidore a Client Access Array háttérbe szorul. Az RTM-ben nem fogjuk használni (és nem is fogjuk elrejteni de semmi hatása nem lesz). Nem szabad elfelejteni, hogy az Exchange Server 2013-ban levo CAS szerepkör nem azonos az Exchange Server 2010 CAS-al. Ezért az egész CAS Array funkció átértelmezendo.

Ha nincs CAS Array és a postaláda több Exchange Server-en is lehet akkor adódik a logikus kérdés (újra), hogy Exchange Server végpontként a profilban mi szerepeljen. A megoldás muszakilag tökéletes. Azonban pánik generátornak bizonyul és ezért írom most ezt a jegyzetet. Csak semmi pánik. Az Exchange Server végpont helyére az Outlook profilban a <postaládaGUID>@SMTPNévtér karaktersor kerül:

Csúnyának tunik és ahogy írtam pánik generátor lehet. Hiszen “normál” esetben a felhasználó / admin ha meglát egy GUID-t akkor arra asszociál, hogy itt valami gond van. Pedig nincs. Csak egy példa: ha egy muszaki terméken látunk egy szériaszámot akkor sem kell pánikba esni. Ez csak és kizárólag definíció kérdése! Az Exchange Server 2013 használata esetén a definíció az, hogy a Server helyén egy GUID szerepel az Outlook profilban.

Mit kezd ezzel a GUID-al az Exchange és hogy találja meg az igazi postaládát? Ez a GUID a postaláda ExchangeGUID nevu tulajdonsága:

Ha megvan a postaláda GUID-ja akkor néhány helyes lekérdezéssel eldöntheto, hogy melyik adatbázisban van a postaláda és az a postaláda aktuálisan melyik Exchange Mailbox Serveren van felcsatlakoztatva (mounted). Ezt teszi az Exchange Server 2013 CAS is és továbbítja a kérést a megfelelo szervernek.

Az Outlook Anywhere csatlakozási pont konfigurációja változatlan marad. Ott továbbra is a tunnel felépítéséhez szükséges teljesen egyértelmu konfigurációs elemekkel találkozhatunk:

Egy helyen még találkozhatunk ezzel a karaktersorral. Az Outlook Connection Status ablakban Server névként szintén felbukkan:

Összegezve tehát: ez nem hiba. Érdemes a felhasználókat errol tájékoztatni a mozgatás elott / után / közben. Azt javaslom, hogy a kommunikációs tervben ez feltétlenül szerepeljen.