Mittwoch, 21. Dezember 2011 13:41
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 14:50
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 15:06
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 16:54
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.
- Als Antwort vorgeschlagen Sharon.ShenMicrosoft Contingent Staff, Moderator Donnerstag, 22. Dezember 2011 07:20
Donnerstag, 22. Dezember 2011 07:20Moderator
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.
TechNet Community Support
Donnerstag, 22. Dezember 2011 11:26
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]
Freitag, 23. Dezember 2011 16:09
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:38
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.
- Bearbeitet mniccum Freitag, 23. Dezember 2011 16:45
Dienstag, 27. Dezember 2011 08:22
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]
Dienstag, 24. Januar 2012 18:03the mod answered the question. please click ANSWERED
Mittwoch, 29. Februar 2012 17:43Let 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
Montag, 12. März 2012 20:38First, 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:40there 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.).
Dienstag, 13. März 2012 15:54So... 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...
Mittwoch, 20. Juni 2012 15:34
"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, 23. Januar 2013 20:37
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
Donnerstag, 24. Januar 2013 14:43
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) :)