The Complexity of Simple Urls
One of the many new features in Lync Server 2010 is a change to how meeting Urls are formatted. The name of this feature is "Simple Url", but in truth this this elicits a smirk from anyone on our team who has dealt with them, as simple Urls are anything but simple. The goal of this blog will be to shed some light on this rather confusing topic.
What is a Simple Url?
In Offices Communications Server 2007, when you send someone a meeting invite, the Url is formatted similar to the following.
This isn't exactly easy to remember and if you needed to transcribe it to someone it would take a few minutes. One of the goals in Lync Server 2010 was to make these Urls much easier - hence the name "simple" Url. Now, Url's look similar to the following.
https://meet.contoso.com/071200
This is a lot easier, right? The only drawback here is these Urls must now be configured. To configure these Urls, you must create simple Urls.
So how can I create a simple Url?
There are two options for creating simple Urls. You can either use the topology builder or you can use Powershell to create simple Urls. It is also possible to view the existing simple Urls in the Lync Server Control Panel, but simple Urls cannot be changed there. This blog will cover managing simple Urls in Powershell.
The primary cmdlets used for creating simpleUrls are.
Get-CsSimpleUrlConfiguration
New-CsSimpleUrlEntry
New-CsSimpleUrl
The following is an example on creating a new Simple Url.
$newUrlEntry = New-CsSimpleUrlEntry -Url "https://meet.vdomain.com"
$newUrl = New-CsSimpleUrl -Component "meet" -Domain "vdomain.com" -SimpleUrl $newUrlEntry -ActiveUrl "https://meet.vdomain.com"
Set-CsSimpleUrlConfiguration Global -SimpleUrl @{Add=$newUrl}
Each simple Url can contain multiple entries, but only one can be active. The ActiveUrl property determines which Url is active. In order to properly understand the other two parameters, I need to explain a bit more.
Sipdomains and Simple Urls
Within the topology document multiple Sip domains can be specified. Sip domains specify which domain names are valid for users, contacts, and other endpoints. All users must end with a valid Sip domain. For instance, if you have a user, john@contoso.com, a SipDomain for contoso.com must exist in the topology. If you have another user jack@marketing.contoso.com, the Sip domain marketing.contoso.com must also exist in the topology.
To view the existing Sip domains, use Get-CsSipDomain. To create a new Sip domain use New-CsSipDomain. Of all Sip domains, one domain is marked as the default and is used for creating new endpoints.
The domain parameter passed to New-CsSimpleUrl must be an existing SipDomain. Why is this necessary? As it happens, Sip domains and simple Urls are partners in crime. Neither can exist without the other.
When a user creates a conference, Lync Server examines the domain for that user and finds the corresponding simple Url. This is the simple Url where domain = {domain of the user}. The ActiveUrl of this simple Url is then used to create the meeting. Therefore, in order for the user to schedule online meetings a corresponding simple Url must exist.
Types of Simple Urls
There are actually three types of simple Urls. The one we have been discussing here is the "meet" type - specified by the Component parameter in New-CsSimpleUrl. The meet type is used for online meetings. There are also two other types.
Dialin - This is the Url to use for all dialin users. Note that the domain for a dialin simple Url must always be "*".
Admin - This allows one to create an easier Url for the Lync Server Control Panel.
After you have created your simple Urls
After you have created your simple Urls, you are still not finished. You must still create DNS A records for each of these simple Urls and you must run Enable-CsComputer on each machine that runs the web services role.
When Enable-CsComputer is run on each computer, it modifies the IIS service on each machine to contain the appropriate mappings for each Url. This is how simple Urls work.
Simple Urls and wildcards
In Office Communications Server 2007, it was possible to create allowed domains (the equivalent to Lync Server Sip domains) that contained a wildcard or simply specify that all domains are allowed. For instance, instead of creating entries for marketing.contoso.com and sales.contoso.com, one could create a single allowed domain *.contoso.com.
Unfortunately, due to the interdependence of simple Urls and Sip domains in Lync Server 2010 and the fact that simple Urls do not work with these schemes, we had to remove these features in Lync Server. Therefore, you must now specify all domains that are allowed and wildcards will not work. In cases where you have a large number of domains, it is possible to create many simple Urls and Sip domains using Powershell scripting.
SimpleUrlConfiguration and scope
As already stated, Get-CsSimpleUrlConfiguration returns a Central Management Server document that contains all configuration info for simple Urls. This document can be of global or site scope. For the vast majority of cases, you should only use the global scope. This means that this document will apply regardless where the user is homed.
However, there are some cases where users in a wide geographical area may share the same Sip domain, but you would prefer to minimize traffic that goes across. For instance, imagine that you have two sites - one in North Carolina and the other in Latvia. Users in both sites have the same Sip domain - contoso.com. In this case you could create two documents and scope them to each site.
New-CsSimpleUrlConfiguration Site:"North Carolina" -other params
New-CsSimpleUrlConfiguration Site:Latvia -other params
When determining the meeting Url, Lync Server will read the document for the site on which the user is homed. Note that Set-CsSimpleUrlConfiguration Site:Latvia will not work unless New-CsSimpleUrlConfiguration Site:Latvia has already been run.
Requirements of a simple Url
The following are requirements for all simple Urls.
- - Left prefix simple Urls are not allowed. For instance the following two simple Urls would not be allowed because one is a subset of the other.
https://meet.contoso.com/meet/me
- - Must begin with https:// (http is not allowed)
- - Must have a corresponding Sip domain (see above)
- - Cannot be empty
- - Cannot be the same as a computer or pool Fqdn in the topology
- - Cannot contain a query string parameter. A Url of the format https://meet.contoso.com/meet.htm?type=foo is not allowed.
- - Must be a valid fully qualified domain name
Also note that we will automatically add a trailing / to the Url. Therefore if you create a Url https://meet.contoso.com/default.htm we will change this to https://meet.contoso.com/default.htm/.
Interaction between Powershell and the Topology Builder
As already mentioned, it is possible to create simple Urls using either Powershell or the topology builder. However, it is generally unwise to mix these together when creating a single batch of simple Urls. The behavior between the two is slightly different.
When using Powershell, if one creates a Sip domain, Lync Server will not create the corresponding simple Url. This must be accomplished separately. After all, how would the cmdlet know which Url to use?
The Topology Builder, however, will create a simple Url for each Sip domain. These Sip domains can then be edited using the Topology Builder and when you publish the topology, both the simple Urls and Sip domains will take effect at the same time.
One strange side effect though is if one creates the Sip domain using Powershell, then opens the Topology Builder and loads the topology, it will appear that the simple Urls were automatically created. This is sort of the case. The topology builder will notice that Sip domains exist for which no corresponding simple Urls exist and will create new simple Url entries that can be changed in the Topology Builder, but these changes will not take effect until the topology is published.
Conclusion
Simple Urls in practice may be simple for users, but they are far from simple for administrators. Most important is the relationship between simple Urls and Sip domains. Once these concepts are understood managing them is much easier.