Howdy,
Overview
If you planning to deploy Lync in your infrastructure, you seriously need to consider make it available to remote users, which mean users from our side your network can still access Lync.
To do so you need to have the following:
- Lync Edge Server “a must”
- Some kind of Reverse Proxy “a must”
- Lync Director Server “Optional”
Lync Simple URLs refers to basically three URLs that are hosted by your Lync Front end server/Pool and your Lync Director server, and they are used to provide the Remote users the ability to:
- Download conference Content
- Address book files download
- Address book web queries
- Client / devices updates
- Distribution group expansion
- Dial-in conference information
- Meeting URL
- Auto discover
All those services are provided by Lync IIS website (web services) installed on the server.
They are the following:
Role | Services provided | Subject name syntax |
External web services – FQDN of the front end pool | Conference content
Address book files Client/device updates DG expansion |
Lyncwebext.lyncdude.net |
External Web services – FQDN of the Director pool | Same as above | LyncDirwebext.lyncdude.net |
Dial-in | Dial-in Conference information | Dailin.lyncdude.net |
Meet | Meetings URL | Meet.lyncdude.net |
Lync Discover | Lync auto discovery | Lyncdiscover.lyncdude.net |
Planning for URLs naming
Simple URLs are a way to make the URL used in conferencing easier for the users to understand. Where there is a Director pool in place, the URLs are published on the Director, this doesn’t mean replacing the Web services of your Front end pool with Director, Lync Director web services is published with the Lync Front end web service too.
The idea is if you have a Lync Director deployed to make it the landing hop for all external connections for more security before redirected to the Front end.
Note: for meet URL you will need meet URL for each SIP domain you have in your deployments.
According to Tech Net there are three possible way to plan for your URLs, I will summarize them as following:
Simple URL naming Option 1:
You have a dedicated URL for each site as following, this option require a number of certificates or subject alternative name to support each URL.
&
https://meet.anotherdomain.com
Last URL is if you have another SIP domain in your deployment
Simple URL naming Option 2:
In this option, the URL is a virtual directory under the external web service URL (Called Shared Simple URL)
https://lyncwebext.lyncdude.net/meet/
https://lyncwebext.lyncdude.net/dialin/
&
https://lyncwebext.anotherdomain.com/meet
Last URL if you have another SIP domain in your deployment
If you publishing using Director pool (LyncDirwebext.lyncdude.net), you should use them for the reverse proxy.
https://lyncdirwebext.lyncdude.net/meet/
https://lyncdirwebext.lyncdude.net/dialin/
&
https://lyncdirwebext.anotherdomain.com/meet/
Simple URL naming Option 3:
This is one of the most efficient use of URLs, if you publishing the Front end web services then:
https://lyncwebext.lyncdude.net/lyncdude/meet/
https://lyncwebext.lyncdude.net/anotherdomain/meet/
https://lyncwebext.lyncdude.net/lyncdude/dialin
And if you have deployed Lync Director then use the Director web services to publish the URLs:
https://lyncdirwebext.lyncdude.net/lyncdude/meet
https://lyncdirwebext.lyncdude.net/anotherdomain/meet
https://lyncdirwebext.lyncdude.net/dialin/
So that’s basically all what you need to learn about Lync Simple URLs, hope it gave you an idea about what and how to plan your simple URLs.
Hi
Nice article. How it will look the edge’s certificate for option 3?
Regards,
Dan
Thanks Dan,
For Lync Edge it’s little different as Edge need 2 SAN to be located in the Certificate, sip.yourdomain (or access.yourdomain depend on what you defined in the Topology when deployed the Edge) and webconf.yourdomain.
if you have more sip domains, then the certificate need to have them also, for example sip.yourotherdomain (or access.yourotherdomain) and webconf.yourotherdomain
i find organizations add both “Lync URL” and “Edge services” in one certificate to save money, and it will work as long as you make sure the SN of this certificate is the Edge access service FQDN (Sip.yourdomain, or access.yourdomain), and add the rest as SANs.
check my article about Lync Security http://lyncdude.com/2013/08/07/understanding-lync-security-part-2/