12th of December, 2011 / / 14 Comments

Lync Server 2010 Mobility supports an internal and an external automatic discovery record. As described in this post, the mobile client signs-in by performing a DNS query for lyncdiscoverinternal.<your sip domain>. If this record is not present (does not resolve), the client attempts lyncdiscover.<your sip domain>. This design approach aligns to the Lync 2010 client software for Windows. First an attempt for the SRV record _sipinternaltls._tcp.<your sip domain>, followed by _sipinternal.tcp, followed by _sip._tls, then the A record fallbacks. This approach is great for Windows PCs, and allows Split-DNS configurations to bounce client systems to either the Internal Front-end Pool or the External Access Edge on the Internet. The Windows PCs are managed and Group Policy can add trusted root certificates to the computer certificate store.

But thinking about Mobile clients specifically, they do not have this Group Policy deployment luxury. I’m trying to determine the advantage of ever defining lyncdiscoverinternal.<your sip domain> in the internal DNS namespace. Typically, the Lync Web Services certificate assigned to the Front-end Pool is issued by an internal certificate authority. This Root Certificate Authority certificate is not present on Mobile devices, therefore will be untrusted. The Lync mobile client would not be able to sign-in, unless the internal root certificate was pre-installed on the device.

As you are unable to simply deploy the root certificates to your fleet of mobile devices, bouncing all the devices to lyncdiscover.<your sip domain> looks to be the most appropriate approach. This will typically require routing and access rules to allow internal traffic a connection to the Reverse Proxy server.

Category:
Lync

Join the conversation! 14 Comments

  1. Adam Jacobs

    Great post, my thoughts are that this will become useful for devices on Wi-Fi that can traverse internal to external.

    – Adam

  2. nbctcp

    Hi,

    I try to understand “Permit routing from the internal corporate network to the reverse proxy listener” mean.
    Is it to create access rule in TMG that allow my internal network 10.10.x.x to public ip x.x.14.21 (meet,dialin). If yes what ports (5087?)

    thanks

    SERVER INFO:
    1. TMG
    EXT IP: x.x.14.21 x.x.14.22
    INT IP: 10.10.11.19
    2. LYNC FE
    IP: 10.10.11.8
    3. LYNC EDGE
    EXT IP: x.x.14.22
    INT IP: 10.10.11.22

    DNS Config:
    INTERNAL DNS
    1. domain.local
    lync-01 A 10.10.11.8
    admin A 10.10.11.8
    dialin A 10.10.11.8
    meet A 10.10.11.8
    lyncdiscoverinternal A 10.10.11.8
    lyncdiscover A x.x.14.21 (TMG public ip)
    2. domain.com
    lync-01 A 10.10.11.8
    admin A 10.10.11.8
    dialin A 10.10.11.8
    meet A 10.10.11.8
    lyncdiscoverinternal A 10.10.11.8
    lyncdiscover A x.x.14.21 (TMG public ip)

    EXTERNAL DNS
    1. domain.com
    im A x.x.14.22
    lyncdiscover A x.x.14.21
    meet A x.x.14.21

  3. Mike

    I have configured Lync autodiscover for internal and external. I have both lyncdiscover and lyncdiscoverinternal in the internal DNS. lyncinternal is pointing to the external interface IP of the TMG server listener/rule and the lyncdiscoverinternal is a CNAME pointing to the internal FE pool DNS name. All devices work externally with this configuration. Although, in this configuration Android devices are working on internal Wifi but iPhones and iPads fail with “Can’t verify certificate from the server. Please contact your support team”. It would appear that the devices dont trust the internal certificate which makes sense. I removed lyncdiscoverinternal from the internal DNS. I restarted the Apple devices and still get the same issue. Android still works.

  4. Bobby

    Thanks for this, great post. Happy New Year!

  5. Greg S (@GregSeeber)

    thanks bro. I agree. the lyncdiscoverinternal is getting the AX. I mean, like, in 2 seconds.

  6. moto822

    Hey Mike,

    I had the same problem, I routed lyncdiscoverinternals to my “Internal” network to get around changing internal server certificates. the only way I could get around the cert issue was to create a new listner and assign it only 80. This did require an additional IP on the TMG internal.

  7. Jay A

    I’ve not used Lyncdiscoverinternal. We have split brain dns and so internally I am able to point my lyncdiscover and External Web services FQDNs to an internal VIP on the TMG reverse proxy.
    As TMG handles the request and has a public Cert we have no problems.

  8. dhery

    Hi Mike, just send your certificate from email to your apple device then install it.

  9. Ann

    Hi, thanks for this post. it maked it clear now for me the difference between two. Do you an article how to set the mobility step by step?

Comments are closed.