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 email@example.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)
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)
Certificate Configuration (
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 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.
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
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.
Service Records (SRV)
Rather than provide an extensive list of documentation, we are keeping the documentation to a minimum set of docs relevant to this topic.
Support Escalation Engineer
Sr. Technology Solution Professional