locked
2 леса и один LCS сервер, возможно ли ? RRS feed

  • Вопрос

  • Есть 2 леса, которые доверяют друг-другу, в первом поднят LCS2005 SP1, все пользователи счастливы.

    Теперь задача, дать пользователям второго леса возможность пользоваться LCS без установки дополнительных сервисисов в их домен, возможно ли ? И если нет, то какие службы необходимо еще установить для этого, с учетом того, что есть только по 1  доступному серверу в каждом лесу?

    18 октября 2006 г. 7:32

Ответы

  • Есть такая статья...

     

    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

    20 октября 2006 г. 14:47

Все ответы

  • Я бы поставил и во втором лесу LCS и связал бы LCS в каждом лесу между собой. Так правильнее, мне кажется.
    18 октября 2006 г. 23:16
  • а возможно их связать, не устанавливая отдельно для каждого access proxy на отдельном сервере ?
    19 октября 2006 г. 6:52
  • Этого я не знаю, т.к. не делал сам. Но точно помню, что Ваш сценарий описан в доках по планированию развертывания LCS. И нужно двигаться строго по докам. Эти доки можно скачать из соотв. раздела сайта Microsoft
    19 октября 2006 г. 8:15
  • Есть такая статья...

     

    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

    20 октября 2006 г. 14:47