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.
- The first command we need to run is Get-CsSite. This cmdlet retrieves the list of Lync sites in the topology.
- 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. 🙂
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
Happy to help Ian. 🙂
Great Post Justing – I have a query and hope you can help here. My customer wants to change his SimpleURL’s to http://lync.contoso.com/meet http://lync.fabrikam.com/meet. However he does not want to add multiple SAN in the public certificates. How should i proceed in this case as i understand you need to re request the certs once you change ur Simple url’S.
Hi Abhay, you would need to change the SANs on the public certificate if you change the simple URLs unfortunately.
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
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.
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.
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.
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
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?
Hi Dino,
Yes we did in this situation. It’s really up to your access/HA requirements – you could do either.
Pingback: Lync Wiki: Understanding Simple URLs in Lync - NextHop - Site Home - TechNet Blogs
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
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.
Thanks for your input. It seems these decisions will boil down to specific requirements from customer to customer.
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
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.
Pingback: Understanding Simple URLs In Lync | Blog.Lync2013.org
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
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
Pingback: Update-SfbCertificate.ps1 | greiginsydney.com