Notes from the field: Lync gebruiken met meerdere SIP domeinen – deel I

In this blog serie we will have a look at the challenges you will have when you are implementing a Lync environment which is responsible for multiple SIP domains.

To understand this process we will first have a look which parts of Lync are affected if you are implementing this scenario. The parts who are affected when hosting multiple SIP domains are:

  • Simple url’s, required to offer Meet, Dial-in and remote administration functionality
  • DNS, required to offer Lync functionality
  • Certificate, required to secure the connections

Let’s look more into detail.

Simple URL’s

The first thing we will have a look at are the simple url’s. In the Topology Builder you can configure three simple url’s:

TypeDescriptionRemark:
Meet urlUsed by client to connect to meetings hosted by Lync. By default the   format of the meet url is like this: meet.domain.com.
Dial-in urlUsed by users to browse to the dial-in page an either lookup dial-in   numbers or modify their personal configuration such as pin etc.Only one per Lync pool
Admin urlUsed by administrators to manage their Lync environmentOnly one per Lync pool

So for example in a Lync environment which hosts a single SIP domain this can be:

  • meet.domain.com
  • dialin.domain.com
  • lyncadmin.domain.com

As you can already see in the table you can configure only one dial-in and admin URL per Lync pool. So if you are going to host multiple domains only the meeting URL can be configured per SIP domain. The dial-in and admin URL are shared between all SIP domains.

But what in case of multiple SIP domains? There are twee options:

  • “Cheap” solution
  • “Expensive” solution

For the following examples we assume our Lync environment offers Lync functionality for two domains:

  • Domain.com
  • Company.com

Let’s discuss how this would affect the simple url’s:

Cheap solution

The reason why we call this a cheap solution is because we are not changing the domain part of the url but only what is behind the domain part. This has as benefit that we don’t have to use any additional SAN entry on our certificate, which is discussed later in this blog.

In this case the format could be either once of the examples below:

  • meet.domain.com/domain/meet and meet.domain.com/company/meet
  • lync.domain.com/domain/meet and lync.domain.com/domain/meet

As you can see in both examples the domain part is kept the same and only the part after the domain part changes. The difference between the two examples is that SAN entries it requires.

The first example uses a separate meeting URL to publish the meet website. This requires an additional SAN entry on your certificate.

The second example uses the same FQDN as the external Lync FQDN and thus will not require an additional SAN entry since lync.domain.com is already part of the certificate.

Expensive solution

This solution requires one additional SAN entry per SIP domain for the meet url. The reason for this is that per domain a domain specific meet url is configured for example:

  • meet.domain.com
  • meet.company.com

Both FQDN’s will need to be part of the certificate else users will get certificate errors when visiting the meet page or trying to join a meeting.

Here ends the first part of this blog. In this part we had a look at the impact on the simple URL’s when hosting multiple SIP domains. In the next part we will have a look at how this influences the amount of DNS records.In deze blog serie kijken we naar de uitdagingen die je hebt wanneer je een Lync omgeving gaat implementeren met meerdere SIP domeinen.

Om dit process beter te begrijpen kijken we naar eerst diverse onderdelen van Lync waar dit van invloed op is. De onderdelen van Lync die beinvloed worden door meerdere SIP domeinen zijn:

  • Simple url’s, benodigd voor Meet, Dial-in and remote beheer functionaliteit
  • DNS, benodigd om Lync functionaliteit aan te bieden
  • Certificate, benodigd om connecties te beveiligen

Laten we eens meer in detail naar deze punten gaan kijken.

Simple URL’s

Het eerste item waar je naar moet kijken zijn de simple url’s. In de Topology Builder kun je drie simple url’s configureren:

TypeOmschrijvingOpmerking:
Meet urlGebruikt door clients om deel te nemen aan meetings die gehost worden door Lync. Het standaard format is als volgt: meet.domain.com.
Dial-in urlGebruikt door clients om te browsen naar de dial-in pagina om dial-in nummers op te zoeken of persoonlijke instellingen te wijzigen zoals pin, etc.Eén per Lync pool
Admin urlGebruikt door beheerders om Lync te beherenEén per Lync pool

Als je een Lync omgeving hebt met één SIP domein dan kunnen deze URL’s bijvoorbeeld als volgt zijn:

  • meet.domain.com
  • dialin.domain.com
  • lyncadmin.domain.com

Zoals je kan zien in de tabel kan er slechts één dial-in URL en één admin URL zijn per Lync pool. Dus wanneer we meerdere SIP domeinen willen hosten kan alleen de meeting url aangepast worden. De dial-in en admin url worden gedeelt tussen alle SIP domeinen.

Maar wat zijn de mogelijkheden met meerdere SIP domainen? Er zijn twee opties:

  • “Goedkope” oplossing
  • “Dure” oplossing

Voor de volgende voorbeelden gaan we er vanuit dat de Lync omgeving Lync diensten aanbiedt aan de volgende twee domeinen:

  • Domain.com
  • Company.com

Laten we kijken wat het effect is op de simple URL’s:

Goedkope oplossing

De reden waarom dit de goedkope oplossing wordt genoemd is omdat er niks aan het domein deel van de url wordt aangepast er wordt alleen maar wat toegevoegd. Dit heft als voordeel dat er geen extra SAN entry benodigd is op het certificaat, dit zal in een volgend deel van deze blog besproken worden.

In dit geval kan de URL één van onderstaande formaten zijn:

  • meet.domain.com/domain/meet and meet.domain.com/company/meet
  • lync.domain.com/domain/meet and lync.domain.com/domain/meet

Zoals je kunt zien is het domein deel van beide voorbeelden hetzelfde gebleven en is er allen wat toegevoegd. Het verschil tussen de twee voorbeelden is het aantal SAN entries wat benodigd is.

Het eerste voorbeeld gebruikt een aparte meeting URL om de website te publiceren. Dit vereist een additionele SAN entry op het certificaat.

Het tweede voorbeeld gebruikt dezelfde FQDN als de externe Lync FQDN en vereist dus geen extra SAN entry omdat lync.domain.com al onderdeel is van het certificaat.

Dure oplossing

Deze oplossing vereist één extra SAN entry per SIP domein voor de meet url. De reden hiervoor is dat per domein een domein specifieke meet url wordt geconfigureerd bijvoorbeeld:

  • meet.domain.com
  • meet.company.com

Beide FQDN’s moeten onderdeel zijn van het certificaat anders zullen gebruikers een foutmelding ontvangen wanneer ze de pagina bezoeken of proberen deel te nemen aan een vergadering.

Hier eindigt het eerste deel van deze blog. In dit deel hebben we gekeken naar de impact op de simple URL’s. In het volgende deel kijken we naar de gevolgen voor de DNS records.

Free subscription



You may also like...

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *