Lync Mobile is available a while for Windows Phone 7, Android and IOS, On the internet several tutorials can be found how to make this features available. One of the best tutorials is the one from Lync MVP Jeff Schertz.
But what if it doesn’t work? On the TecNet fora several issues are reported. One of the issues reportedis problems with succesfully log-in.
In a lot of cases this is caused by an incorrect DNS configuration. Lync Mobile uses two dns records lyncdiscover.domein.com and lyncdiscoverinternal.domein.com for retrieving the correct configuration.
Lyncdiscover is used when connecting from external. Lyncdiscoverinternal will be used when connecting via the lan.
To see which information is send back to the client by the discover service you can use Internet Explorer:
https://lyncdiscover.domein.com/autodiscover/autodiscoverservice.aspx/root/sipuri=user@domein.com
The browser will ask you where to store the file. Save the file in a temporary place for example your desktop. One saved you can use Notepad to view the content of the file:
{“AccessLocation”:”External”,”Root”:{“Links”:[{"href":"https:\/\/lync.domein.com\/Autodiscover\/AutodiscoverService.svc\/root\/domain","token":"Domain"},{"href":"https:\/\/lync.domein.com\/Autodiscover\/AutodiscoverService.svc\/root\/user","token":"User"}]}}
Here you will see the url which the client will need to connect to. If you look at the fqdn you will see it’s the external url of the Lync environment. This url is published via a reverse proxy.
By following this steps you can verify if the autodiscover mechanism works OK.
But this doesn’t guarantee that you can signin succesfully. In the example below you can see the client has some issues with getting a valid WebTicket. Each client will try to gather a WebTicket if no ticket is available in the cache:
2011-12-22 20:39:04.404 Lync[242:8323] INFO TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpConnection.cpp/548:Response status = 401 for request WebTicketRequest
2011-12-22 20:39:04.405 Lync[242:8323] INFO TRANSPORT /Users/comobuildadmin/se_wave1_idx/src/dev/CoMo/transport/_buildIos/../requestProcessor/privateIos/CHttpStreamPool.cpp/124:Setting url – https://lync.domain.com/webticket/webticketservice.svc persistent id as 11
2011-12-22 20:39:04.604 Lync[242:8323] INFO TRANSPORT
In the example above a 401 error can be seen whichis caused by an authentication issue. But in the example above this wasn’t the issue.
One of the next steps is capture the network traffic using a networkcaptue tool, for example WireShark. In this case incoming traffic could be seen but nothing was send back. To be more specific no traffic was send back using the Front End nic. The server contained another nic which had an IP address was not disabled but wasn’t used anymore. When the networkcapture was used to view traffic on this interface the traffic which needed to be send back to Lync Mobile was send via this nic. But since the nic wasn’t configured with a default gateway the traffic wouldn’t arrive.
In this case disabling the nic solved the issue. After some searching on the internet more people had this issue
On the site of Ståle Hansen the issue is described as follows:
If you have a multi-homed Front End server the Mobility Service (Mcx) may sometimes fail
- Reason: When calculating routing for a Mobility request the service makes a call to read DNS settings of the registered adapter. In some instances it is possible for the non-registered adapter to be returned.
- This causes routing of the request to fail This is regardless subnet configuration on the second NIC
- There should be a forthcoming Release Note or KB Article on this topic
So it looks like Microsoft is aware of this issue an will publish a KB article about this issue.
