Lync Mobility, lyncdiscoverinternal or lyncdiscover


  • Can someone make points, how does lyncdiscoverinternal make different?

    In situation, where lyncdiscover (external) is working, what would I get to setup lyncdiscoverinternal?
    Does ANYTHING changes?

    - Meitzi [MCITP]
    Mittwoch, 21. Dezember 2011 13:41

Alle Antworten

  • Hi ,

    When you implement automatic discovery , mobile devices first attempt to connect to Lyncdiscoverinternal record by default . If that fails, it will try lyncdiscover (ext) record and get it connected .

    So any mobile devices connected to internal network (Enterprise WI-FI) can resolve the Lyncdiscoverinternal record and it will hit on internal McX website (If you setup a A record) .

    However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Microsoft Lync Server 2010 Mobility Service externally through the reverse proxy.


    • Als Antwort vorgeschlagen Jean-Michel G Freitag, 26. April 2013 06:53
    Mittwoch, 21. Dezember 2011 14:50
  • Sorry if my english is not clear.

    So why on earth would anybody want use internal name if it does not make any different in any situation?

    - Meitzi [MCITP]
    Mittwoch, 21. Dezember 2011 15:06
  • Just think of the case where your internal and external domain are same i.e. Because must not be resolvable when queried from domain network, we need a way to direct the client to the internal service.

    1. Clent is on internal WiFi. A (internal) DNS query for returns internal IP Address of the server. Client attempt to signin and it is re-directed to the External Web Service (published via Reverse Proxy). Client query the (internal) DNS for the IP address of the External Web Service (this the requirement to have A-record for your External Web Services with IP Address - the public IP address of the RP) and signin there.

    2. Client is on Public Internet. A DNS query for DOES NOT return result. The Client then query the (public) DNS for and receives the IP address of the RP where sign-in occurs.


    Mittwoch, 21. Dezember 2011 16:54
  • Hi,Meitzi,

    As I know,Lyncdiscoverinternal is used for the users inside firewall who only allow Lync mobile connect server via internal access .

    Technical speaking, if there is no internal WIFI,you can only use Lyncdiscover but it's recommended to add lyncdiscoverinternal . Here is a good blog posted by Brendan Carius talking about Lyncdiscoverinternal for your reference.



    Sharon Shen

    TechNet Community Support

    ******************************************************************************************************************************************************* Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community memb
    • Als Antwort markiert Meitzi Donnerstag, 22. Dezember 2011 11:13
    • Tag als Antwort aufgehoben Meitzi Dienstag, 27. Dezember 2011 08:22
    • Als Antwort vorgeschlagen Greg Seeber Dienstag, 24. Januar 2012 18:02
    Donnerstag, 22. Dezember 2011 07:20
  • I'm kind of satisfied. But

    If we speak full lync client, we dont want use external (edge server) address because of:
    - we want save external traffic, lets say Voice / Video / sharing
    - we want use "direct" connections, video etc when ever possible. (saves internal servers traffic too)
    So its makes lot of sens have internal / external.

    In mobility, none of these matters. So internal traffic is not ANY BETTER (?) than external.

    I can understand, if someones want ONLY use internal for somereason, Now he/she can do that. But if external works, I DONT SEE ANY reason to setup internal. (you did not give me any single reason, just how setup and how hard it will be)

    - Meitzi [MCITP]
    Donnerstag, 22. Dezember 2011 11:26
  • 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 at logon 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.



    Freitag, 23. Dezember 2011 16:09
  • I think I have found the issue and not exactly sure what to do.

    In the Topology Builder I have defined an external web services FQDN of  The internal web services (no override) is still the default FE pool name.  Externally pointins to the TMG external interface.  Internally as a CNAME points to the FE pool name.  So now the Apple devices on the internal Wifi do initially use but receive back in the XML from the autodiscover service.  I verified this by sending the logs from one of the devices to my email.  The log shows the XML sent to the device.  Since this internally resolves back to the FE, the devices do not trust the certificate and you get "Can’t verify certificate from the server. Please contact your support team".

    On the internal DNS, should point to the external interface of the TMG server so the devices get the external certificate? 

    Or, should I define an override for the Internal web service of and internal point the DNS to the external interface of the TMG box so the devices get the external certificate?

    Maybe both...maybe this point I am not sure what the ramifications of pointing internal web services to the external TMG interface would do.

    I just need to spend more time with this on the whiteboard as my head is spinning.


    Another question:  Why does the Android device continue to work regardless?


     Update:  As a test I pointed the internal DNS record of to the external TMG interface and now all the Apple devices work.

    • Bearbeitet mniccum Freitag, 23. Dezember 2011 16:45
    Freitag, 23. Dezember 2011 16:38
  • Just forget internal. (so mniccum just remove lyncdiscoverinternal, result will be same right?)

    Thats was my opinion and it still is.

    Why Microsoft recommendation setting internal dns? I dont get it.

    - Meitzi [MCITP]
    • Als Antwort markiert Meitzi Dienstag, 27. Dezember 2011 08:22
    • Tag als Antwort aufgehoben Meitzi Dienstag, 27. Dezember 2011 08:23
    Dienstag, 27. Dezember 2011 08:22
  • the mod answered the question. please click ANSWERED
    Dienstag, 24. Januar 2012 18:03
  • Let me see if we are on the same page here 1- lyncdiscoveinternal was deleted and does not exist anymore? 2- lyncdiscover is pointing to external 3- when you log from internal wifi lyncweb record is returned. 4 - lyncweb is internal fe server and has internal ip address 5. Lyncweb is also external fe and has public dns name resolvable externally

    Regards Herbert Zimbizi

    Mittwoch, 29. Februar 2012 17:43
  • First, why would the lyncdiscoverinternal fail? I kind of agree with Meitzi on this, I just don't see the point of lyncdiscoverinternal based on all the descriptions of how mobile devices connect external or internal. If the point is to get all mobile devices to connect through one ingress point, then what is the point of having a lyncdiscoverinternal DNS record pointing to the internal FE or Director to have internally connected mobile devices to try to connect internally, when it will get redirected (hairpinned) out the firewall and back in anyway?


    Montag, 12. März 2012 20:38
  • there is no point of using it.  that's what many of us don't use it. IMO it's only useful for testing after initial config to make sure that your Lync server is working prior to adding additional variables such as reverse proxy and firewall (etc.).
    Montag, 12. März 2012 20:40
  • So... for hairpinning internal wifi users, do I need an Internal DNS record of external webservices defined for the front end pointing to external IP of TMG or the external web services defined for the director server pointing to external IP of TMG? I'm a bit confused because the front end properties show a different External Web Services FQDN than the director server properties in the deployment I'm working with...


    Dienstag, 13. März 2012 15:54
  • "IMO it's only useful for testing after initial config to make sure that your Lync server is working prior to adding additional variables such as reverse proxy and firewall (etc.)."


    The main (and only?) reason you have to force internal clients to connect through the reverse proxy rather than directly to the pool, is so that when users roam from inside network to outside network and back, they keep the same connection via the proxy and Lync client is not disrupted.

    Believe it or not, Microsoft is actually giving you some options about how you configure your network to support Lync Mobile.  Giving you the option to use lyncdiscoverinternal and/or lyncdiscover is part of that.  The only problem is their documentation is not good enough to explain it well.

    Mittwoch, 20. Juni 2012 15:34
  • Firstly, I invite ANYONE who is not happy with our docs to provide feedback.  We invite it and encourage it. for Lync Server 2010, for Lync Server 2013.

    Secondly, We intentionally don't go into gory details in the Planning and Deployment docs - not any more than is absolutely necessary.  The reason simply is we have a diverse audience and our goal with the Planning and Deployment docs is to help people PLAN and DEPLOY.  Technical depth is available by a number of means:  We have the Lync Server 2010 Resource Kit, the NextHop blog (multitudes of articles on in-depth Mobility is there) and a Troubleshooting Lync Mobility Issues white paper, among a whole bunch of MVPs.

    Now, the direct question:  Why NOT just avoid the whole lyncdiscoverinternal.<domain> record and just go to the Lyncdiscover.<domain> record for all internal and external users?  Three reasons:

    A) We have more information in the Autodiscover response than just "Hey! You're inside.  Go outside!"  "Hey, You're outside! It's all good!"  Check the traces....

    B) Newer clients that have been released since Cumulative Update for Lync Server 2010 : November 2011 (known affectionately to everyone else and their puppy as CU4) make use of BOTH records to know where they are and to use the correct internal or external Web services for their purposes.  Unless you want ALL clients to be hairpinning at your reverse proxy.....  Both records are really needed.

    C) We state that we only support DNS where BOTH lyncdiscover and lyncdiscoverinternal are implemented. Why? Refer to B)  

    Anyone that is questioning IF we want feedback - Drago Totev and Mr. Seeber can both tell you - we're serious when we say we want your feedback on our docs.


    Rick Lync Server UA

    Mittwoch, 23. Januar 2013 20:37
  • Good to see ya back Rick!

    Thanks for the info ... good to know that there is a method to 'why' this is the way that it is. 

    My thoughts about the whole thing:  I dont' have any way of knowing what the phone is doing, it's a black box - . So, I dont' know why it wouldn't work if something wasn't working.  So, having a single way of connecting would potentially simplify troubleshooting.   That's my train of thought, BUT - I never actually used the lyncdiscoverinternal so I wouldn't know if it's even problematic at all.   I do know this, I'm doing the hairpinning back through RP and it works 'as good as expected' both internal/external.   I went with simplicity in architecture.   Oh, not to mention that sometimes internal certificates get into the mix and ... in the words of Sweet Brown, "Aint nobody got time fo dat."

    Remembering back - the internal certificate thing was the biggest driver of going external back in. 


    if my post is helpful - please click on the green arrow. (please excuse, in advance, any perceived sarcasm/humor - as I often forget it does not translate through text) :)

    Donnerstag, 24. Januar 2013 14:43
  • I have both and pointing to the same IP on my reverse proxy, so ALL users are traversing my external F5 device.  If I remove from internal DNS, wont ALL clients continue to query for it 1st in the list anyway?  Would I gain anything from removing the DNS entry?  Can you set clients to ONLY query for, regardless of their location?



    Donnerstag, 8. August 2013 19:37
  • referring back to Ricks info - knowing that there is additional information in the communication aside from "am I internal or external?"  I would absolutely NOT have lyncdiscoverinternal populated ESPECIALLY if you're not using it for its intended purpose.   That would be very confusing if you started having problems.

    My thoughts, from supporting this for a while - it will query the candidate list - and it will find lyncdiscover - and it will connect as expected.   And, you don't want to be in the mobile device certificate management department - so, don't point lyncdiscoverinternal to your FE pool either (internal certs).

    If you want simple, and you want proven - just use lyncdiscover and forget the rest of it.  

    There's no value in having them both if you're simply pointing them both to your external resources - just make the lyncdiscover record viewable in your internal DNS zone

    if my post is helpful - please click on the green arrow. (please excuse, in advance, any perceived sarcasm/humor - as I often forget it does not translate through text) :)

    • Bearbeitet Greg Seeber Donnerstag, 8. August 2013 20:28
    Donnerstag, 8. August 2013 20:27
  • Cheers for the debate and resulting valuable information!! It inspired me to research this further and write a blog to summarise my findings (without going in to too much detail). I would love to hear everyone's feedback to ensure I haven't misunderstood anything.

    Andrew Morpeth
    Lync Server Specialist - Auckland, NZ
    Check out my blog

    Montag, 13. Januar 2014 07:02