Configuring LCS 2005 w/ SP1 for Multiple Domains


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 then Communicator expects to be able to logon to a server with a Full Qualified Domain Name (FQDN) in the same domain; ex. 


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 –

LCS Computer FQDN –

LCS Pool Name –

LCS Pool IP address –

LCS Computer IP address –

Supported SIP Domains (default inherited from AD)

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

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


Subject Alternate Name

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  –

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(*


Public Interface Subject Alternate Name


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

DNS Records (External)

Service Records (SRV)

Host (A)

IP Address

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 (10)

  1. Anonymous says:

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

  2. Anonymous says:


    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.


  3. Anonymous says:

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

  4. Dennis Lundtoft Thomsen says:


  5. Dino Caputo says:

    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.

  6. Toml LCSKid says:

    No the director is not mandatory.

  7. Nick Matahen says:

    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?