Configuring Site Level Simple URLs in Lync Server 2010

Last month I deployed a new Lync 2010 environment with many regions/ pools globally coupled with multiple SIP domains of which we had to design a Meeting Join solution with simple URLs to accomodate the geographically dispersed nature. Let me set the scene.

The Problem

If we just had say, https://meet.contoso.com as our global meeting join URL (defined in the Lync Topology Builder) and pointed this to say, the EMEA Lync Front End pool, it would mean all users worldwide would be hitting that pool when they click the link in Outlook to join the meeting. Not ideal and not scalable.

The Solution

To ensure only EMEA users connect to the EMEA pool (and not the APAC users as well, for example), we need to create site level simple URLs to ensure users only connect to the pool in their region and that these URLs take precedence over the default global level simple URLs.

For this scenario, I selected Simple URL Naming Option 2 from the Planning for Simple URLs article on TechNet, which gives me a bit of flexibility and means my simple URLs for EMEA for this scenario look like this:

https://lyncemea.contoso.com/meet
https://lyncemea.fabrikam.com/meet
https://lyncemea.contoso.com/dialin

and my APAC URLs for example, would look like this:

https://lyncapac.contoso.com/meet
https://lyncapac.fabrikam.com/meet
https://lyncapac.contoso.com/dialin

and so on per global region. Note that you can only have one dialin simple URL per site – you can’t have a different dialin simple URL for each SIP domain.

For this article, I’ll only be covering the meet and dialin URLs, not the admin URL for LSCP access.

Creating a new Simple URL Configuration

First we need to create a new simple URL configuration that we will end up applying new simple URLs to.

  1. The first command we need to run is Get-CsSite. This cmdlet retrieves the list of Lync sites in the topology.
  2. After we’ve identified the site name (EMEA), we run the New-CsSimpleUrlConfiguration cmdlet against the site e.g.
    New-CsSimpleUrlConfiguration -Identity site:EMEA

Creating new Simple URLs

After we’ve created the new Simple URL configuration, we need to first create simple URL entries bound to a variable in our current PowerShell session and then simple URLs bound to a different variable.

Simple URL Entries

We run the following cmdlets to create a new simple URL entry for each URL required and then bind it to the variable specified at the start of the cmdlet.

$urlEntryContosoMeet = New-CsSimpleUrlEntry -url “https://lyncemea.contoso.com/meet

$urlEntryFabrikamMeet = New-CsSimpleUrlEntry -url “https://lyncemea.fabrikam.com/meet

$urlEntryAllDialIn = New-CsSimpleUrlEntry -url “https://lyncemea.contoso.com/dialin

Simple URLs

Next, we need to actually create the new simple URL in Lync, set which component (meet or dialin) it will apply to, which SIP domain it’s set for, which simple URL entry it will use and then (phew!) bind it to the variable we specify at the start of the cmdlet. Run each cmdlet per simple URL you need to create:

$simpleURLContosoMeet = New-CsSimpleUrl -Component meet -Domain contoso.com -ActiveUrl https://lyncemea.contoso.com/meet -simpleurl $urlEntryContosoMeet

$simpleURLFabrikamMeet = New-CsSimpleUrl -Component meet -Domain fabrikam.com –ActiveUrl https://lyncemea.fabrikam.com/meet -simpleurl $urlEntryFabrikamMeet

$simpleURLAllDialIn = New-CsSimpleUrl -Component dialin -Domain * -ActiveUrl https://lyncemea.contoso.com/dialin -simpleurl $urlEntryAllDialIn

Bringing it all together

So now we have a bunch of variables floating around in our current PowerShell session, we need to apply them to something. To make it real, we need to add the variables of all our simple URLs from the previous step to the new site level simple URL configuration we created earlier by running this cmdlet:

Set-CsSimpleUrlConfiguration -Identity “site:EMEA” -SimpleUrl @{Add=$simpleURLContosoMeet,$simpleURLFabrikamMeet,$simpleURLAllDialIn}

Once that’s applied successfully, we need to run Enable-CsComputer to apply the configuration to IIS on the Front End server/s in the pool.

To review the changes committed, run the cmdlet Get-CsSimpleUrlConfiguration to retrieve the Global Simple URL configuration and the new Site level Simple URL configuration, each with the individual URLs we created.

Last Words

Make sure you take note of the difference between a Simple URL entry and a Simple URL, as they are different things in Lync Server Management Shell that are brought together to create a configuration.

To reiterate, note that you can only have one dialin simple URL per site – you can’t have a different dialin simple URL for each SIP domain.

Hope this makes it (a bit) clear on how to setup site specific simple URLs in Lync. As Lync grows in maturity and market share, we will see larger, more widespread organisations adopting it which means you’ll need to know how to get this kind of configuration going. 🙂

21 thoughts on “Configuring Site Level Simple URLs in Lync Server 2010

  1. Ian

    Great post – I found your post in my first search, read it, thought Yuck this looks messy, there must be an easier way. As I discovered there isn’t an easier way and your procedure works brilliantly. Thanks

    Reply
    1. Justin Morris

      Hi Abhay, you would need to change the SANs on the public certificate if you change the simple URLs unfortunately.

      Reply
  2. Jason

    Great Article, Just wondering do I need to create the site level URLS for both EMEA and APAC or does the APAC one use the global URL;s

    Reply
    1. Justin Morris

      Hi Jason, thanks for the feedback. 🙂 If you don’t create site level URLs for a site, they will use the global simple URLs. The new simple URLs you define will only apply to the site they’re configured against.

      Reply
  3. Guru

    Hi Justin, thanks for showing to use simple urls in multi site environment. We are using global simple urls for meet and dialin. And at site level we have also mentioned External web services URLs per site. What happens with it? Could you please let me know. – Rgds, Guru.

    Reply
    1. Justin Morris

      Hi Guru,

      External web services URLs are specific to pools only, not sites. You set these per pool during a regular deployment. If you are using remote access you should then publish these using a reverse proxy.

      Reply
  4. James

    Hey Justin,

    To get round this internally, we had to work with three seperate regional domains with three seperate lync servers (legacy setup of europe/asia/americas) yet we needed to use our external domain name for all meeting joins so we created a zone in internal dns for each regional domain (europe.company.net) of meet.externaldomain.com, three of them, and additional zones for dialin.externaldomain.com, then people in their home region connected to their nearest lync server for meetings without setting up multiple simple urls.

    However – this does not help from outside and people connecting over edges, where everyone defaults to the default external site for meeting join. For this i will look at implementing what you suggest. We manually specify edge servers in gpo’s so people connect to their nearest but ALL web clients go through a single site regardless of home domain due to single external meet.externaldomain.com addresses.

    Not sure if this is a terrible solution but is working ok for us.

    Jim

    Reply
  5. Dino

    Thanks Justin. Nice Post. Did you also deploy multiple Reverse Proxies (and Edge Servers) at each of the EMEA and APAC sites to handle external participants joining meetings or are all external participants driven through one default site and then redirected to the apprpriate pool internally?

    Reply
    1. Justin Morris

      Hi Dino,

      Yes we did in this situation. It’s really up to your access/HA requirements – you could do either.

      Reply
  6. Pingback: Lync Wiki: Understanding Simple URLs in Lync - NextHop - Site Home - TechNet Blogs

  7. Dino

    Hi Justin, my understanding of the meeting sign on process (thanks to Kevin Peters) is that even if clients hit the wrong pool for a meeting (baseds on using a single Global simple URL) they are always redirected to the correct pool via the external web services URL for the pool. Given this and assuming that you have deployed an Edge and Reverse Proxy for each site, would having one pool handle these requests really be cause for scalability issues? I’m trying to understand if the extra complexity of having unique simple URLs per site is warranted in a smaller multi-site deployment.
    Best Regards,
    Dino

    Reply
    1. Justin Morris

      In this particular scenario, scalability wasn’t really the challenge. The customer primarily didn’t want to expose URLs or domains to the end user that weren’t within their business. So if the user was john@contoso.com, all URLs had to point to meet.contoso.com.

      The other was that they wanted to localise web services ingress points to each global region. For example, they wanted US users coming in via the US DMZ and not via the EMEA DMZ.

      Hope that clarifies the particular requirements of this configuration.

      Reply
  8. Loic

    Hi Justin,
    I just deployed a second edge in a second central site (US) and configured the simple urls based on your raccomandations.
    Everything works as expected.

    Now I moved the user to the new pool (US).
    If a schedule a new meeting everything works with the new url, but previuous meetings are not accessible anymore.
    It is normal? Is there any way to update meeting urls from meet.example.com to meetus.example.com?

    Thank and congrats for your fantastic blog

    Reply
    1. Justin Morris Post author

      Hi Loic,

      To change the meeting join URL to be the new URL, I believe the user would have to reopen old meeting invites and regenerate the Lync meeting details.

      Reply
  9. Pingback: Understanding Simple URLs In Lync | Blog.Lync2013.org

  10. John Miller

    Again, great post Justin. Another advantage of this approach is it’s positive impact on some disaster recovery scenarios. Let’s say as in your example you have a North America, EMEA and APAC site setup with site specific Simple URLs. If the pool in the America site fails or the America Reverse Proxy fails this approach would leave the meet and dialin functioning for both internal and external users (and meetings) homed in the EMEA and APAC sites. Even if you have your Autodiscovers pointed at the America site, with weighted SRV records the loss of the America site wouldn’t even adversely impact the ability for the EMEA and APAC users to authenticate. The only major function that can’t, without GSLB or similar, that can’t be rigged to failover automatically or continue to function in the loss of the America pool is Lync Autodiscovery service, and as we know this would adversely impact the Lync mobile clients. Hopefully Microsoft will provide, other than GSLB or similar, a plan B solution for the mobile clients. Technically, yes, a down mobile client could manually put the server addresses in their device in a pinch…..some people that is!

    Best Regards,

    –John

    Reply
  11. Hany

    want to send meeting request and this was the link I got from Lync client https://meet.contoso.com/lync.test/T5Y941JJ
    after sending I got this url error 404 – File or directory not found.

    The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
    and as my external URL is https://connect.contoso.com when I tried to access this url https://connect.contoso.com/meet I got the lync pag.
    is that mean I have to change the URL from Lync topology to be https://connect.contoso.com/meet
    and if I did, that mean I have to change in SAN certificate which already has connect.contoso.com and meet.contoso.com as SANs

    Reply
  12. Pingback: Update-SfbCertificate.ps1 | greiginsydney.com

Leave a Reply to Justin Morris Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.