Configuring LCS 2005 w/ SP1 for Multiple Domains

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.

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)

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