If you are setting up Lync Server for the first time or have been running Lync Server, you will notice that Lync depends heavily on DNS records. In many cases, a Lync deployment cannot be setup correctly without using a split-dns setup and using a masked UPN; which can make things even more tricky. Here is a complete listing of DNS records I used to deploy Lync 2013. I have verifed federation works properly, IMs, conferencing, dial-in meetings, mobile and desktop client sign-in, and desk phones. Note, records indicated in Red are records that are required/standard in every lync deployment.
Internal DNS Records
|Record Type||Value||Points to|
|A||lyncdiscoverinternal.mydomain.com||Lync front end server|
|A||lyncdiscover.mydomain.com||Lync reverse proxy
(needed for mobile devices to work interally)
|A||lync.mydomain.com||Lync front end server|
|A||sip.mydomain.com||Lync front end server
(multiple A records if enterprise pool)
|A||dialin.mydomain.com||Lync front end server|
|A||meet.mydomain.com||Lync front end server|
|SRV||_ntp._udp.mydomain.com||Domain Controller/Time Server|
**Note, you should have A records for all of the hosts in your Lync deployment (front end servers, pools, proxies, etc.). Those are not covered in the list as they are 100% user defined when deploying Lync.
External DNS Records
|Record Type||Value||Points to|
|A||webconf.mydomain.com||Edge server IP as specified in setup wizard|
|A||av.mydomain.com||Edge server IP as specified in setup wizard|
|A||sip.mydomain.com||Edge server IP as specified in setup wizard|
|A||meet.mydomain.com||Lync Reverse Proxy IP|
|A||dialin.mydomain.com||Lync Reverse Proxy IP|
|A||lync.mydomain.com||Lync Reverse Proxy IP|
|A||lyncdiscover.mydomain.com||Lync Reverse Proxy IP|
Why do you point sip, meet and dialin to the Reverse Proxy internally?
Shouldn't this end up to the Frontend(pool)?
Sorry about the delay! I believe I did this for support in using Lync mobility features. I could be wrong in that they should point to the frontend pool, but I believe I ran into issues with mobile clients connecting.
Just as a follow up, Greg is correct in that the records should be referencing the front end servers/pool directly. I have updated the page to reflect the changes.
I am sorry, but i think you have made a mistake.
lyncdiscover.sipdomain.suffix should not be available on the internal dns zone, but only externaly. The same for Lyncdiscoverinternal.sipdomain.suffix should only be available on the internal network.
Thanks De Greyt Jurgen! I have updated the Internal DNS records list to reflect the proper settings.
Not true. If you want mobile devices to connect via internal WiFi, the lyncdiscover record should exist, and should point to the external reverse proxy address.
Thank you for the clarification Pat! Exciting to see a comment from a Lync veteran! 🙂
Based on the technet article published above. Reason for this is to your point, is that mobility devices only look for lyncdiscover.domain.suffix and require edge, so in the event a user is on the internal wifi, they route out to the internet, to the edge, and back in BY DESIGN.
lyncdiscover.sipdomain.com and lyncdiscoverinternal.sipdomain.com should both exist in internal DNS while only lyncdiscover.sipdomain.com should exist on external DNS. Also to mention as some of us make the mistake a lot and then have issue with lync mobile connection, lyncdiscover IP should be the reverse proxy IP while lyncdiscoverinternal should be frontend server IP. Another thing is that lyncdiscover.sipdomain.com and lyncdiscoverinternal.sipdomain.com should be on the ssl certificate for the ARR IIS access.
Great site, thanks for your help. I've been struggling with getting Lync set up for several weeks. I've got everything working but Mobile. I'm going back to the beginning and verifying my DNS.
Regarding the SRV records that you have marked for Internal. You point them toward the sip.mydomain.com. That address though then points toward the Reverse Proxy? I thought that they would point toward the Front-End server, especially the sipinternal entry.
Also, am I correct in assuming the DNS entries for sip, meet, & dialin point to the internal address on the Reverse Proxy server?
Thanks so much,
I did a little tweaking in my environment and have updated the DNS settings here to what I have currently deployed. The new settings make much more sense as we are referencing the front end pool/servers directly rather than having the extra hop to the reverse proxy. When referencing the reverse proxy, you are correct in that you can use the internal IP address.
Please let me know how it goes!
Hi Jack, thanks for your quick reply. Those new setting work great for my basic setup. I'm still broken with regards to mobility. I'm fairly certain I've got something broken in regards to my certificate config.
Back to the drawing board!
Are you using a Windows Phone by chance? We have noticed that Windows Phones don't work internally with the DNS configuration above, but all other mobile devices do. What's weird though is the windows phones and all others work externally flawless. The only other thing I can think of is have you trusted your own certificates internally on the mobile devices? You will need to make sure your internal certs have been trusted in the mobile device's trusted CA store.
Last, try going to https://testconnectivity.microsoft.com/ and running the Lync Autodiscover Web Service Remote Connectivity Test on the Lync tab. See if you are getting any certificate errors there.
Right, my team have all three phone types (WP, iPhone, & Android). Though I'm mainly using that testconnectivity site you mentioned for my testing and getting the same error. All attempts result in:
A Web exception occurred because an HTTP 502 - BadGateway response was received from IIS7.
From everything I've read that indicates a certificate error. (to be honest, I am a total rookie when it comes to certs) I've tried all sorts of combinations, with a wildcard cert everywhere I had everything working except mobility. Wildcards are not supported everywhere so I ordered a public cert for my reverse proxy and have tried using internal CA certs on the other servers but get the same error.
So I don't repeat everything, I actually have a thread going on the official Lync forums .
Thanks for your help, I really appreciate it!
I was looking at your external reverse proxy (based on the link in the technet article), and it looks like your external cert is setup correctly. I would narrow this down to internal routing between the reverse proxy and your internal lync front end server/pool. I sent you an email, let me know if you would like to look at the settings together to see if we can narrow down the problem further.
I had issues with corporate wifi and mobility clients not swapping between this and their normal phone provider.
This is because they need to hairpin back to the Reverse Proxy via the lyncdiscover DNS record.
So if your corp wifi is supplying DNS from your internal DNS servers to the mobile clients when they swtich to wifi, you need an entry on your internal DNS pointing to your reverse proxy address for lyncdiscover.
Won't work properly otherwise. 🙂
Appreciate the feedback Hamish! 🙂
I have Lync 2013 STD for internal use but my domain is a .local. Clients can only connect using [email protected] and not [email protected]. What do I need for my user to user [email protected]?
It sounds like when you were deploying your Lync Standard Server in the topology builder, you may have entered your actual domain and not the UPN. I believe the step is called "Define the primary domain" where you want to enter in the UPN suffix (@domain.net) instead of @domain.local. Definitely would agree the wizard is not very clear on that step.
Luckily, you can easily change this through the topology builder on your front end server. Simply open up topology builder, download a copy of the latest configuration from the central management store, and then right click on "Lync Server" and select Properties. On the "Edit Properties" window, you should see a field at the very top called "Default SIP domain". Enter in mydomain.net instead of mydomain.local and hit OK. Publish your topology and the changes should reflect yourdomain.net instead of yourdomain.local
Please let me know how it goes!
I am wondering what the lync.mydomain.com pointing to the reverse proxy is usd for?
Many of the external web services will take advantage of this. When the lync client does an auto discover, it will pull down an XML file that will contain certain information pointing to which addresses the client should communicate to.
You can find more about this from Microsoft here: http://technet.microsoft.com/en-us/library/gg398069.aspx
Or better yet, from here: http://blog.schertz.name/2012/07/lync-edge-server-best-practices/
Hope this helps!
really useful guide, was just wondering if you could explain one thing to me?
I am new with the Lync product (lets say 3 days). Got my head round most of it, however on your guide, you have the internal DNS records, that should be inserted on the internal DNS. Should these be internal DNS name (domain.local etc) rather than external DNS name (domain.com).
If external domain, I dont have a zone for our external domain created in our internal DNS, as this is handled at ISP level.
Thank you again!
Good question! You do not have to use a .local domain name. If your Active Directory domain is mydomain.com, you can still point lync.mydomain.com (for example) to your internal Lync server. Then, have your ISP point lync.mydomain.com to your Lync edge server if you will be allowing external access to Lync. I usually like to deploy Active Directory with a .local domain to help differentiate internal servers from external like this, but it is not required.
Hope this helps!
Thats really helpful information and a very quick responce!!
I owe you one! Thank you
Thank you for your very valuable guidances on Lync they are wonderful and very comprehensive.
We faced an strange problem after Lync 2013 fully implementation, would you give us any issue to solve this problems
1- Whiteboard works about 30 minutes each time after Lync server restarting, for internal and external user both, and after that, it stops and give an error says “An error occurred while presenting”
2- Totally we face “An error occurred while presenting” by PowerPoint sharing
3- The call communication among two users that are both outside of domain is possible but the same call communication among a user inside domain and one outside of domain could be established , we added the user outside of domain the certificate and also in host etc, relevant IPs is added.
We are in desperate need of a solution or guidance for this problem.
1. Do you receive any errors on your front end server.
2. Have you deployed an Office Web Apps server and added it to your topology? (http://technet.microsoft.com/en-us/library/jj219455(v=office.15).aspx)
3. Sounds like you have a firewall issue or your call routes are configured incorrectly.
Hope this helps,
Awesome post, thanks! It got me all the way up to getting mobile devices to work (which is the last piece to my puzzle). Neither iOS or Android can't sign in internally or externally. I'm stuck!
Have you configured a reverse proxy yet? That is needed for the mobile clients to connect properly.
Hope this helps,
Thanks for getting back to me. Yep, I sure have. I have a 2012 R2 machine with IIS ARR running as my RP machine. I have to URL rewrite rules set for lyncdiscover, meet, dial and webext. They're also set for regular experssions (.*) The Lync Connectivity Analyzer comes back clean for lyncdiscover HTTPS external access. UCWA completed successfully as well too.
Hmm not sure. One of the easier tests is to ensure external connectivity works first. I found this was easier to achieve as it uses a publically trusted certificate, rather than internal one issued by my PKI environment, so my devices will communicate without having to manually import/trust my root CA certificate.
Additionally, before technet had released an article to use IIS, I followed this guide using apache as the reverse proxy. Not sure if what you are seeing is a rule or routing issue in your environment, but I do know this guide works: http://www.lynclog.com/2012/09/configuring-apache-as-reverse-proxy-for.html Maybe it will spark some ideas on what else may need to be configured to get things working in the IIS environment.
Hope this helps!
it would have been great if... Port numbers were also mentioned along with it and dummy IP's External and Internal would have been mentioned... creating Records and Rules would have been breeze...
Port numbers and IPs can get dicey. Some organizations require one-off scenarios and then getting support comments from them can be very difficult to help without knowing what they have done. Here I know these DNS records are going to be consistent throughout all Lync deployments.
First of all i would like to appreciate you for this very simple and useful post.
We have deployed Lync 2013 recently and it is working fine. Now we want to implement Edge services.
But my doubt is : Our internal and external domain names are different then it is possible to implement these Edge services.
Internal mail ID is like : [email protected] and
external ID is like : [email protected]
Can i be able to login to Lync using my external mail ID.
Please let me know the process and Thanks in advance.
You can do this. Inside of the topology builder, just make sure your set your SIP domain to be that of your external ID, not your internal. You can deploy resources like your lync front end pool (if enterprise) using the internal SIP domain, while external resources such as meat, dialin, sip can be with your external ID.
Hope this helps,
When I send a lync meeting to an external contact, it send my internal address. For example my internal address is meet.domaincorp.com and my external is meet.domain.com. It sends out the internal, so, obviously, when you click the link, it doesn't work. I tried to manually change it on the external side and just remove the corp at the end, but that doesn't work. Any help you can provide would be great. I do have the edge server setup. It is working if I install the lync client on the external computer. However, this one particular external user has a mac, so I can't install the client. I just want him to be able to use the link to connect.
I have my default sip domain as domaincorp.com, but I setup simple urls for meet.domaincorp.com and meet.domain.com. I also set the "additional supported SIP domains" to have the domain.com. Is that correct?
If you are using an internal PKI environment, make sure that your certificate chain is imported into the Mac's keystore.
Additionally, if you are receiving the incorrect meeting URL, please make sure you configured this properly inside of the topology builder.
Hope this helps,
Hi nice article and very much appreciated. Quick question when you say for example lyncdiscover should be internal dns and reverse proxy I assume the ip for that A record should be the RP internal nic, correct?
Correct, it would not need to be the external IP address.
HI, Jack , can u give me suggestion how to solve this ,
Testing remote connectivity to Microsoft Lync server through the Lync Access Edge server mydomain.com on port 5061 to verify user [email protected] can connect remotely.
Specified remote connectivity test(s) to Microsoft Lync server failed. See details below for specific failure reasons.
Elapsed Time: 8745 ms.
Attempting to resolve the host name mydomain.com in DNS.
The host name resolved successfully.
IP addresses returned: 126.96.36.199
Elapsed Time: 165 ms.
Testing TCP port 5061 on host mydomain.com to ensure it's listening and open.
The port was opened successfully.
Elapsed Time: 1111 ms.
Testing the SSL certificate to make sure it's valid.
The SSL certificate failed one or more certificate validation checks.
Elapsed Time: 7468 ms.
The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server mydomain.com on port 5061.
The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
Remote Certificate Subject: CN=sip.mydomain.com, OU=netlync, O=mgc, L=oman, S=nite, C=OM, Issuer: CN=mydomain-DC-CA, DC=mydomain, DC=com.
Elapsed Time: 7446 ms.
Validating the certificate name.
Certificate name validation failed.
Tell me more about this issue and how to resolve it
Host name mydomain.com doesn't match any name found on the server certificate CN=sip.mydomain.com, OU=netlync, O=mgc, L=oman, S=nite, C=OM.
Elapsed Time: 0 ms.
The SSL Certificate on your external edge server is invalid. I'd recommend replacing the SSL Certificate with one issued from a public certificate authority (GoDaddy, VeriSign, etc.)
Hope this helps,
Regarding internal dns records if you have a disparate dns say dominan.local and external domain.com
I assume you need to create a zone internally for domain.com and create those records pointing to the FE pool/server correct? Records like the dialin and meet. Thanks!
Yes, you will want a split DNS environment.
Awesome Thanks Jack!!!
I have just installed the fresh lync server 2013 and my lync basic client doesnt sign in.Please help
I'd recommend enabling Full logging inside the lync client and checking event viewer for what is wrong. Additionally, you can start troubleshooting external lync connectivity with this tool: https://testconnectivity.microsoft.com/
Pingback: Guide: NGINX Reverse Proxy for Lync 2013 - Mike's Blog
Little confused. What are we referring to when we say "sip.domain.com" is that the actual URL or should I be replacing SIP with something else?
Thanks great post!
Yes, you would replace that with the SIP that you defined in your Lync Topology.
We're having an issue with external clients signing in. Currently, our external DNS records for autodiscover, meet, and dialin all point to the External Web Services FQDN (we do not have a reverse proxy). However, one of my colleagues put an entry in his host file pointing lyncdiscover to the external IP address of our Edge Server. So, my question is, if we do not have a reverse proxy, what should we be pointing our external DNS records to, specifically for autodiscover?
You will want a reverse proxy, it is a key component in the Lync deployment (I have a tutorial on my site on how to configure this, you just need a simple IIS machine). If you are not going to use the reverse proxy (which is not recommended and a security risk), you would point the records to the Front End servers.
pls what does the SIP stands for. is it my front end server or front end server pool and if i do have a director in my domain, will my SIP change or not.
SIP stands for Session Initiation Protocol. Here is the Wikipedia page on it. https://en.wikipedia.org/wiki/Session_Initiation_Protocol
This is something that you would need to request from your telecommunications company (ISP).
Hello Jack, As per your blog Lyncdiscover (internal DNS record) should point to Internal NIC of reverse Proxy
In case we have 2 Revese Proxies within Load balancer (within F5 load balancer), to which Reverse Proxy we will point as there are two, or there should be a VIP on internal interface by combining two RP's
I'd point to the VIP on your F5 load balancer then to ensure you don't have a single point of failure to one proxy.
Are you positive that the _sipfederationtls should be in the Internal DNS?