The Microsoft Lync Blog

The Official Microsoft Lync Blog covering Microsoft UC strategy, offerings and market commentary.

Blogs

Configuring LCS 2005 w/ SP1 for Multiple Domains

  • Comments 10
  • Likes

Overview

Automatic configuration allows Communicator to find and connect to the appropriate LCS server without manually entering a server name into its settings. Communicator has special requirements for DNS and certificates to make this work properly.  This bulletin details those requirements.  Manual configuration or using GPOs does not apply to this topic.

 

Why all the fuss?  You might be asking yourself that question.  Basically, it boils down to how Office Communicator locates and connects to an LCS server or pool.  In simplest terms, Office Communicator is designed to make sure it connects to a server in the same domain as its logon ID or SIP URI.  If my logon id is chanb@consolidatedmessenger.com then Communicator expects to be able to logon to a server with a Full Qualified Domain Name (FQDN) in the same domain; ex. Lcspool01.consolidatedmessenger.com. 

 

So, you need to have DNS service records for each domain you are supporting and those service records need to point to FQDNs with matching domains.  This holds true for internal clients and external clients.  Below we take a look at both.

Supporting Internal Clients

To illustrate the requirements we will use a sample customer situation.  Consolidated Messenger is a large organization, requiring an Enterprise Pool.  Notice that the Pool name differs from the computer FQDN.  For an Enterprise Edition deployment we require a hardware load balancer using a Virtual IP (VIP) address for the Pool name. Here are the basic settings:

 

Hosting Domain – na.consolidatedmesssenger.com

LCS Computer FQDN – server1.na.consolidatedmessenger.com

LCS Pool Name - Lcspool.na.consolidatedmessenger.com

LCS Pool IP address – 192.168.1.100

LCS Computer IP address – 192.168.1.101

Supported SIP Domains

Na.consolidatedmessenger.com (default inherited from AD)

Adataum.com

AlpineSkiHouse.com

Contoso.com

Fabrikam.com

Litwareinc.com

WingTipToys.com

NOTE: For this scenario the “hosting” domain (Consolidated Messenger) is not used for IM. This is common as the AD domain is inherited but not used for IM.

DNS Records (Internal)

Split DNS configuration is a requirement for automatic configuration.  Simply put, split DNS means you have two DNS zones for one domain name.  One DNS zone exists on internal DNS servers and provides name resolution only for internal clients.  Another DNS zone exists on external DNS servers to service external clients.

 

Split DNS is required so that users can use the same sign-on name in Communicator and have their correct logon server resolved inside and outside the network.

 

The following SRV records need to be created.  Note that these records must be created in the DNS database of the servers authoritative for the particular zone. 

Service Records (SRV)

Host (A)

IP Address

_sipinternaltls._tcp.Adataum.com

Lcspool.Adataum.com

192.168.1.100

_sipinternaltls._tcp.AlpineSkiHouse.com

Lcspool.AlpineSkiHouse.com

192.168.1.100

_sipinternaltls._tcp.Contoso.com

Lcspool.Contoso.com

192.168.1.100

_sipinternaltls._tcp.Fabrikam.com

Lcspool.Fabrikam.com

192.168.1.100

_sipinternaltls._tcp.Litwareinc.com

Lcspool.Litwareinc.com

192.168.1.100

_sipinternaltls._tcp.WingTipToys.com

Lcspool.WingTipToys.com

192.168.1.100


Certificate Configuration (Enterprise Pool)

To support multiple domains for encrypted communications we require that all front-ends in the Pool be configured with a certificate.  The certificate must match the FQDN returned by any DNS SRV query.  Therefore, the certificate must contain multiple entries.  We call these SANs (Subject Alternate Name) and the certificate must include the FQDN of the pool and one entry for each supported SIP domain.

 

Subject Name

Lcspool.na.consolidatedmessenger.com

 

Subject Alternate Name

Lcspool.na.consolidatedmessenger.com

Lcspool.Adataum.com

Lcspool.AlpineSkiHouse.com

Lcspool.Contoso.com

Lcspool.Fabrikam.com

Lcspool.Litwareinc.com

Lcspool.WingTipToys.com

NOTE: When Subject Alternate Name is used, include the Subject Name in the list of SANs.

Supporting External Clients

The key thing to remember about supporting external clients is that the same rules apply.  You must account for every domain that a user might be logging on to and you must have certificate configuration to match.

Certificate Configuration (Access Proxy)

An Access Proxy defines two interfaces; a private interface connecting to the internal LCS environment and a public interface that is used by remote clients and Federation partners.  Each interface must be configured with a certificate.  In our example we are assuming the Access Proxy will use a unique certificate for each interface.

 

Private Interface Certificate

- Subject Name  - lcsAP01.na.consolidatedmessenger.com

To match a common configuration seen by Microsoft Support, make this match the computer FQDN.  Note: the access proxy is installed in a workgroup configuration and as such may not be configured with a complete FQDN.

 

Private Interface Subject Alternate Name

- Not needed

Any internal server connecting to the AP will be connecting directly to the FQDN associated with the Private interface and there are no client to AP connections therefore no SANs will be used.

 

Public Interface Subject Name

- Match the Enhanced Federation Domain(sip.adataum.com)*

 

Public Interface Subject Alternate Name

   sip.Adataum.com

   sip.AlpineSkiHouse.com

   sip.Contoso.com

   sip.Fabrikam.com

   sip.Litwareinc.com  

   sip.WingTipToys.com

 

Because Communicator clients will be connecting to the AP directly on the Public interface, the certificate must include a SAN entry matching any domain a user might be using for logon.

* Enhanced Federation does NOT support multiple domains. Customers with multiple domains will have to choose the 1 domain they want for Enhanced Federation.  In our example we use Adatum.com.

DNS Records (External)

Service Records (SRV)

Host (A)

IP Address

_sip._tls.Adataum.com

sip.Adataum.com

10.0.0.100

_sip._tls.AlpineSkiHouse.com

sip.AlpineSkiHouse.com

10.0.0.100

_sip._tls.Contoso.com

sip.Contoso.com

10.0.0.100

_sip._tls.Fabrikam.com

sip.Fabrikam.com

10.0.0.100

_sip._tls.Litwareinc.com

sip.Litwareinc.com

10.0.0.100

_sip._tls.WingTipToys.com

sip.WingTipToys.com

10.0.0.100

Additional Reading

Rather than provide an extensive list of documentation, we are keeping the documentation to a minimum set of docs relevant to this topic.

 

Live Communications Server 2005 Document: Planning Guide

 

Live Communications Server 2005 Document: Configuring Certificates

 

Live Communications Server 2005 Document: Deploying Access Proxy and Director

 

Office Communicator 2005: Microsoft Office Communicator 2005 Planning and Deployment Guide

 

- Thomas Laciano

Support Escalation Engineer

- Chandler Bootchk

Sr. Technology Solution Professional

Comments
  • LinkBack/TrackBack

  • In the scenario you describe above, are Director Servers required for this solution to work?  For example, can you apply certs to all the servers in a front-end pool that contain all the SANs that you require and simply use the VIP of Pool to direct internal MOC clients (in AutoConfiguration mode) to an FE server from the Load Balancer?  Many documents refer to the use of Director servers to do this however, it does not appear to be a hard requirement for internal communications only.

  • No the director is not mandatory.

  • PingBack from http://www.markfujie.com/?p=7

  • PingBack from http://lcsguide.com/?p=14

  • I have a question on the multiple domain DNS config. You mentioned that an SRV record needs to be created in every domain. How about an "A" record, does that need to be created in every domain. Assuming you have one server as your pool?

    Thanks

  • Nick,

    Note the tables with the SRV record, you will see the associated A record that should be created. As you will have different domains, you will end up with SRV and A records in these different domains or DNS Zones.

    Tom

  • Work at home legimitate. Work at home http. Work at home. Work from home jobs.

  • PingBack from http://www.keyongtech.com/1289637-between-two-organisations

  • A lot has been written about the way that Microsoft Office Communicator uses DNS to automatically discover

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment