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?

December 21st, 2011 4:41pm

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.

Thanks

  • Proposed as answer by Jean-Michel G Friday, April 26, 2013 6:53 AM
Free Windows Admin Tool Kit Click here and download it now
December 21st, 2011 5:50pm

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.

Thanks

  • Proposed as answer by Jean-Michel G Friday, April 26, 2013 6:53 AM
December 21st, 2011 5:50pm

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?

Free Windows Admin Tool Kit Click here and download it now
December 21st, 2011 6:06pm

Just think of the case where your internal and external domain are same i.e. contoso.com. Because lyncdiscover.contoso.com 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 lyncdiscoverinternal.contoso.com 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 lyncdiscoverinternal.contoso.com DOES NOT return result. The Client then query the (public) DNS for lyncdiscover.contoso.com and receives the IP address of the RP where sign-in occurs.

 

Drago

December 21st, 2011 7:54pm

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.

Regards,

Sharon

Free Windows Admin Tool Kit Click here and download it now
December 22nd, 2011 10:20am

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)

December 22nd, 2011 2:26pm

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.

 

Mike

Free Windows Admin Tool Kit Click here and download it now
December 23rd, 2011 7:09pm

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 lyncweb.domain.com.  The internal web services (no override) is still the default FE pool name.  Externally lyncweb.domain.com pointins to the TMG external interface.  Internally lyncweb.domain.com as a CNAME points to the FE pool name.  So now the Apple devices on the internal Wifi do initially use lyncdiscover.domain.com but receive back lyncweb.domain.com 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 lyncweb.domain.com 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 lyncweb.domain.com and internal point the DNS to the external interface of the TMG box so the devices get the external certificate?

Maybe both...maybe neither...at 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 lyncweb.domain.com to the external TMG interface and now all the Apple devices work.



  • Edited by mniccum Friday, December 23, 2011 4:45 PM
December 23rd, 2011 7:38pm

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 lyncweb.domain.com.  The internal web services (no override) is still the default FE pool name.  Externally lyncweb.domain.com pointins to the TMG external interface.  Internally lyncweb.domain.com as a CNAME points to the FE pool name.  So now the Apple devices on the internal Wifi do initially use lyncdiscover.domain.com but receive back lyncweb.domain.com 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 lyncweb.domain.com 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 lyncweb.domain.com and internal point the DNS to the external interface of the TMG box so the devices get the external certificate?

Maybe both...maybe neither...at 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 lyncweb.domain.com to the external TMG interface and now all the Apple devices work.



  • Edited by mniccum Friday, December 23, 2011 4:45 PM
Free Windows Admin Tool Kit Click here and download it now
December 23rd, 2011 7:38pm

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.

December 27th, 2011 11:22am

the mod answered the question. please click ANSWERED
Free Windows Admin Tool Kit Click here and download it now
January 24th, 2012 9:03pm

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
February 29th, 2012 8:43pm

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?
Free Windows Admin Tool Kit Click here and download it now
March 12th, 2012 11:38pm

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.).
March 12th, 2012 11:40pm

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...
Free Windows Admin Tool Kit Click here and download it now
March 13th, 2012 6:54pm

"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.)."

Yes.

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.

June 20th, 2012 6:34pm

Firstly, I invite ANYONE who is not happy with our docs to provide feedback.  We invite it and encourage it.  Lyncdoc@microsoft.com for Lync Server 2010, Lyncdoc2013@microsoft.com 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.

Cheers!

Free Windows Admin Tool Kit Click here and download it now
January 23rd, 2013 11:37pm

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. 

-Greg

January 24th, 2013 5:43pm

I have both lyncdiscoverinternal.domain.com and lyncdiscover.domain.com pointing to the same IP on my reverse proxy, so ALL users are traversing my external F5 device.  If I remove lyncdiscoverinternal.domain.com 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 lyncdiscover.domain.com, regardless of their location?

Thanks

-Kevin

Free Windows Admin Tool Kit Click here and download it now
August 8th, 2013 10:37pm

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

August 8th, 2013 11:27pm

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.

http://andrewmorpeth.blogspot.co.nz/2014/01/lync-discover-urls-summary.html

Free Windows Admin Tool Kit Click here and download it now
January 13th, 2014 2:07am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics