We can’t connect to Exchange – Lync 2013 mobile

Bevezetés

A héten megjelent a Lync Mobile 2013. Több sikeres demón is túl vagyok, a céges környezet felhasználásával. Természetesen a saját környezetemben is a családban, a barátok között terítettem a klienst. Ami rögtön egy nem várt hibát dobott is. A hosszúhétvége pedig kiváló ido arra, hogy a hibának a hátterét és a megoldást is megtaláljam.

A hiba: minden indításkor a We can’t connect to Exchange hibaüzenetet dobja a kliens.

Alapvetoen a Lync 2013 mobile kliens azért akar az Exchange szerverhez csatlakozni, mert közvetlenül a kliensben megjelenik a naptár azért, hogy az online megbeszélésekhez egyszeruen és gyorsan csatlakozhassunk. A mobil kliens az Exchange szerverhez EWS (Exchange Web Service) használatával csatlakozik. A hibát akkor kapjuk, ha valamiért az EWS kapcsolódás sikertelen. Azonban a saját környezetemben az EWS hibátlanul muködik, akkor hát miért jön mégis a hiba?

Az EWS végpont elérési útját azaz, hogy hova kell csatlakozzon a kliens, azt szabványos módon az alkalmazások az Autodiscover használatával szerezhetik be. Az Autodiscover az adott postaláda kiszolgálásáért felelos Exchange kiszolgálói környezetben levo Autodiscover URL-t visszaadja.

A Lync 2013 mobile kliens is az Exchange Autodiscover-t használja. Az Exchange Autodiscover folyamat során az adott Autodiscover kliens (esetünkben a Lync 2013 mobile) a felhasználó email címébol próbálja meg kitalálnia az Autodiscover végpontot. Ezt a kliensek úgy végzik általában, hogy az email címbol az SMTP tartományt megállapítják és abból további okoskodás révén megpróbálják kitalálni azt, hogy az Autodiscover szolgáltatás hol értheto el.

Figyelem: ez még csak az autodiscover szolgáltatás elérésének kitalálása, ami ahhoz kell, hogy az EWS végpontot megtudjuk. A teljes Autodiscover folyamatról 2 éve írtam egy részletes cikket, érdemes azt feleleveníteni: Autodiscover

Általában a kliensek a következo sorrendben próbálkoznak:

• https://<smtp Domain>/autodiscover.autodiscover.xml
• https://autodiscover.<smtp Domain>/autodiscover/autodiscover.xml
• https://autodiscover.<smtp Domain>/autodiscover/autodiscover.xml
• SRV Record alapú felderítés

A hiba oka és annak megoldása

Egy-egy szoftver trace csodákra képes. Így hát a hibázó telefonon a Lync 2013 mobile klienst trészeltem, miközben a hibát reprodukáltam. A trace-bol egyértelmuen látszik, hogy a Lync kliens nem találja meg az Autodiscover URL-t. Egyben az is kiolvasható belole, hogy a fent említett négy Autodiscover metódusból csak az elso hármat használja, az SRV rekord alapú felderítést nem. A következo képen bejelöltem, a három metódust mindegyikét, amivel többször is próbálkozik a kliens, majd végül az E_NoAutoDiscoverServersFound hibaüzenettel leáll:

Természetesen a környezetemben SRV record alapú felderítés van beállítva az adott DNS névterben. A megoldás az, hogy az SRV record alapú felderítés helyett valami mást konfiguráljunk be.

A végére egy dupla-csavar

A saját környezetemben a hiba duplán gonosz, ugyanis az érintett felhasználónak a SIP címe nem a primary SMTP névterében van. Tehát:

• a felhasználó elsodleges email címe: valaki@domain1.hu
• a felhasználó másodlagos email címe: valaki@domain2.hu
• a felhasználó SIP címe: valaki@domain2.hu

A Lync 2013 mobil kliens alapértelmezés szerint a felhasználó elsodleges email címéhez keresi az EWS URL-t, majd ahhoz az Autodiscover végpontot. Tehát ha a másodlagos és egyben a SIP címhez nem SRV record alapú felderítés van, alapértelmezés szerint az nem jelent semmit. Azonban a Lync 2013 Mobil kliensben lehetoség van arra, hogy az alapértelmezettol eltéro konfigurációt állítsunk be. Ebben az esetben megadható az, hogy a valaki@domain1.hu helyett a valaki@domain2.hu címet használja az EWS URL és az AutoD folyamat során. Ez okos dolog.

 

Comments

• Anonymous
  January 01, 2003
  Good detail keep it up!