Understanding Simple URLs In Lync

Understanding Simple URLs In Lync


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 is required 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 strictly web based.

If you want to deep dive the topic, a good starting point is the TechNet document Planning for External User Access


Simple URLs

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 :

  • Dial-In
    • used to configure the settings for a user that will participate to a meeting using a telephone (dialing in)


  • Admin 
    • used to access to the Lync Server Control Pane


A first reflection : if we do not plan to enable dialin conferencing 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 consequences on our records on the public DNS and on the certificate we are going to use

Sort by: Published Date | Most Recent | Most Useful