Originally published on the Microsoft TechNet Wiki
A Lync deployment that has to be available to users outside our internal network / firewall (the generic definition used is “external users”) requires two additional servers :
- a Lync Edge server (for IM and presence, Web conferencing and A/V conferencing)
- a reverse proxy to publish features, such as conferencing meetings, conference join locations, Mobility services, and so on.
Note : a recent version of the document Components Required for External User Access that Alessandro Appiani has signaled to me, states that the reverse proxy isrequired for the external user access, so any configuration that does not include the reverse proxy should rationally be considered not supported.
Anyway an important aspect of the aforementioned configuration is that we have two “groups” of services and one of them (the second one) is stricly web based.
If you want to deep dive the topic, a good starting point is the TechNet document Planning for External User Access
The document we will start from, to talk about simple URLs is the TechNet article Planning for Simple URLs
Back to the “web” services (i.e. services we have to publish from the Front End) we are talking about three URLs (called “Simple URLs) that we have to make available :
- used for conferences, this is the one we see, for a example, if we have an invitation to a Lync meeting, in the form https://meet.domain.com/username/ )
- used to configure the settings for a user that will partecipate to a meeting using a telephone (dialing in)
- used to access to the Lync Server Control Pane
A first reflection : if we do not plan to enable dialin conferencin or Lync administration from outside our internal network, the only important URL is meet
Configuring Simple URLs
The configuration os simple URLs can be done using the Lync Topology Builder or the Lync Server Management Shell cmdlets.
The first time we run the Topology Builder we configure it with a global scope (i.e. for the whole organization) but we can use different simple URLs for each central site in our company.
For an explanation on the site customization of simple URLs I suggest a great post from Justin Morris Configuring Site Level Simple URLs in Lync Server 2010
Back to the configuration of simple URLs we have three basic options :
1. a DNS name for every service, so we have :
2. a single DNS name with a specific URL for every service like
It is easy to understand that the above decision has an impact on the SSL certificates we will need for our Lync deployment.
Option 1 requires three names (dialin, meet and admin) in a SAN certificate, option 2 requires a single name (lync) for the “web” services of Lync.
3. The third option is interesting for organization that are using more than one SIP domain and need to keep the number of names in the SSL certificate as low as possible. If we have sipdomain1.com and sipdomain2.com the solution will look like
In the above configuration the only URL that is related to the different SIP domains is meet and that is due to the kind of service that the different links are related to.
Also in option 3 we have a single DNS name and, so, a single name in the SSL certificate.
Note : you could prefer to use a value different from /sipdomain/ .
That is something you can do because the url string after https://lync.domain.com/ is something you are free to decide with no complication
Configuring Simple URLs Using Lync Server Management Shell
The configuration of simple URLs from the management shell is based on the Set-CsSimpleUrlConfiguration cmdlet (see Technet for more details Set-CsSimpleUrlConfiguration ) and usually requires the use of variables to define the different URLs
To identify the configuration that is running in your Lync deployment use the Get-CsSimpleUrlConfiguration cmdlet ( Get-CsSimpleUrlConfiguration )
Changing Simple URLs
If we have deployed simple URLs using one of the options and we need to change our settings to a different option we are able to use again the Lync Topology Builder or the Lync Server Management Shell followed by an Enable-CsComputer launched on every Director and Front End.
It is really important to understand that the aforementioned operation has conseguences on our records on the public DNS and on the certificate we are going to use