Dec 12

Lync Mobile clients; how to implement

Now that Lync Mobile is out for Phone 7(.5), it is time to help you all with implementing the updates and getting the correct certificates etc….

Microsoft Lync 2010 mobile applications enable mobile clients to function as UC endpoints, providing instant messaging (IM), contacts, presence, and Enterprise Voice features to create a familiar experience for users of Microsoft Lync 2010. For a matrix that lists the features and capabilities of mobile devices and compares them to the Lync desktop client, see

Microsoft has released multiple Lync clients for mobile devices. This chapter will provide:

  • Which clients are supported with which requirements;
  • Which infrastructure components are involved for the mobile devices and which certificates are required.

Mobile clients

An overview of the Operating System requirements are documented here:


Operating System

Additional comments

Phone 7


+Latest updates






3GS, 4




Nokia E7


SR1.1, web browser 7.4

Sources: Phone7, Android, Apple devices:, Nokia:

Backend infrastructure

To support the Microsoft Mobile Lync clients, several backend infrastructure components require changes. To understand these changes, I’ll explain the discovery process, which user scenarios are valid with which certificates and the required steps on the back-end infrastructure.

Discovery process, scenario’s and certificates

The Microsoft Lync mobile client uses an auto discover service based on DNS names. This is based on the user sign-in address, but is in general:

  • lyncdiscoverinternal.<sipdomain>;
  • lyncdiscover.<sipdomain>.


From a functional perspective, the following scenarios are valid:

  1. Remote Internet connected mobile client using data or Wi-Fi;

    A Lync mobile client connects to the Reverse proxy using Lyncdiscover.<sipdomain> as shown below.

    This results in a new web listener or expansion of the current web listener that was used in the previous situation.

    Depending on the mobile devices and the management, I would recommend using Public Certificates. A single Certificate can be used with multiple SAN entries on certificate #1.

    Certificate #2 is mentioned in scenario number 2, but could be left unchanged if the Reverse Proxy solution is capable of rewriting URL’s from Lyncdiscover.

  2. Internal Wi-Fi connected mobile client.

    In this scenario, a user is connected to the internal Wi-Fi network and can be considered as an internal user. If this statement is true, there are two options…

    1. Redirect them to the External Reverse proxy using the valid DNS records;
    2. Redirect them to the correct Front-end Pool that have the mobility service running.

    Option B requires renewal of the certificate on the Front-end Pool to include the SAN entries for Lyncdiscoverinternal.<sipdomain>. And again, if the mobile devices are managed and you are able to include the Internal CA on to the mobile device, you can use internal certificates. Otherwise it is required to use Public Certificates.

Backend steps

First, download the following application and update:

  1. Autodiscover & Mobility service:
  2. Lync CU4:

Implement them using:

  1. this blog to implement CU4:
    1. Remark 1; Page 26 regarding adding ASP.NET in IIS is done when installing the Autodiscover & Mobility service.

Hope this helps you all, if not, please contact me!!

Permanent link to this article:


1 ping

Skip to comment form

  1. Hi Jeroen,

    I have an idea about the reverse proxy hairpinning issue with internal wifi cliënts:

    If you select on your reverse proxy web listener an internal interface / network and point the internal A record lyncdiscover.sipdomain you can prevent hairpinning and have no certificate issues.

    What is you opinion with that?



    • Jeroen on 16/12/2011 at 17:37

    Hi Sebastiaan,
    It sounds like a reasonable implementation and should be valid as long as you have a Split-Brain DNS set up. Because the has two different answers:
    1) Internal  Reverse proxy “internal” IP.
    2) External/Public  Public IP of the Reverse Proxy.
    Thanks for the feedback!

    • Vineet Chawla on 16/05/2012 at 06:24

    Hi Jeroen
    I have been trying to implement mobility for test lab since two weeks but still unlucky. Could you please help me out. (I am a complete novice to this field)

    This is my setup: lync mobile–> internal wi-fi–> TMG–> Front end server

    The clients on PC are fine but the mobile just says cant connect, check your server network connection and all.
    My autodiscover URL’s are also correct I suppose because they do make me download that root file with correct URL. The certificate is by internal CA but its installed as the root certificate of server as well as my WP7. I dont use public IP or edge server.
    here’s the config:
    he TMG is working on one NIC config.

    *Local domain->lync.local
    *Standard Front end server fqdn-> load2.lync.local
    *Primary SIP domain->
    all the simple URL’s resolve from TMG too, and the SSL listener is listening on internal IP. Plus the test-csp2pim gives failure.

    • Ben Cornelius on 07/09/2012 at 11:48

    I have a similar set up to Vineet, but i am using an edge server. As far as i can see i have entered all the DNS and TMG settings correctly but am getting the error about server being unavailable. However if i point the DNS record for Lyncdiscover to the edge server i get a certificate error.

    • Jeroen on 11/09/2012 at 13:24

    Hi Ben,

    If you have internal clients, make sure the lyncdiscoverinternal points towards your Front-end or Hardware load balancer. The mobile clients will connect the internal record and be redirected to the external webservices of their pool. This might result in hairpinning from internal clients to your TMG. Do not set the record to the Edge server as this is indeed incorrect.
    Feel free to contact me on jeroen at reijling . nl to have a short conversation, as we are federated with HP.

  1. […] Continue reading here: Lync Mobile clients; how to implement | Jeroen Reijling Blog […]

Leave a Reply

Your email address will not be published.