The Effect of Multiple Points of Presence on Group Chat in Communications Server 2007 R2


The Lookup service
account plays an important part in the logon process for Group Chat in
Microsoft Office Communications Server 2007 R2. When dealing with Group Chat
and multiple points of presence, this service must be functioning correctly.
This article describes an issue with the Lookup service account and some other
things to keep in mind when configuring MPOP and Group Chat.

Author: Jared Gradle

Publication Date: February 2011

Product Version: Microsoft Office Communications Server 2007 R2

I was recently assisting a customer with a Group Chat
deployment, and we ran into an issue where the Lookup service account
(ocschat@fourthcoffee.com) was repeatedly being disconnected. The Lookup
service account plays a part in the client logon process for Group Chat.

A single Lookup service account (in this example ocschat@fourthcoffee.com)
is shared among all Group Chat Servers in a Group Chat pool. The Lookup service
account facilitates client connectivity to Group Chat.  The Lookup service account must be enabled for
Microsoft Office Communications Server 2007 R2. It is recommended that you use the name OCSChat when choosing a SIP Uniform
Resource Identifier (URI) for the Lookup service.

When the Lookup service starts on each Group Chat Server in
the pool, the associated Lookup service account (ocschat@fourthcoffe.com)
registers a SIP connection with the Enterprise pool. Each Lookup service
account registers as a separate SIP register for each Group Chat Server in the
Group Chat pool. If you have three Group Chat Servers, you will see three
Lookup service account registers.

If the maximum number of multiple points of presence (MPOP)
specified is lower than the number of Group Chat Servers, the Lookup service will
disconnect from the Enterprise pool.

The following events will be repeatedly logged in the
application log:

6/11/2010           
10:38:41 AM       OCS
MGC           
Information        -1096    
5282      
N/A        OCSGC1     
“Restored connection to Office Communications Server.”

6/11/2010           
10:38:41 AM       OCS
MGC           
Warning              
-1096     5283      
N/A        OCSGC2     
“Lost connection to Office Communications Server.”

When you examine the LookupServer.log  file, which is located by default in %ProgramFiles%Microsoft
Office Communications Server 2007 R2Group Chat ServerLogs, you can see that the
Lookup service successfully connects and registers, and then the connection is
lost and  re-connects again as shown in
the following log information.

Note. I have
truncated line header information from the log to format it in a readable
manner.

Connecting LOOKUP SERVER…

Attempting to connect with SSO…

Endpoint state changed to Registering

Endpoint state changed to Registered

************** Lookup Server is connected to OCS ***************

Lookup server started successfully

UcmaTransport restored connection to Communication Server

Endpoint state changed to Unregistered

ConnectionState: <INITIALIZED>

Disconnected from Communication Server

Finished server disconnect.

UcmaTransport lost connection to Communication Server

UcmaTransport is attempting to reconnect to Communication Server

Attempting to reconnect UcmaTransport

Lookup Service is connecting…

Cert <groupchat1.fourthcoffee.com> was Issued by <Certificate
information removed>

Initiate connection to OCS: URI=sip:ocschat@fourthcoffee.com,
OCS=ocsr2poolr2.fourthcoffee.com, Port=0

Connecting LOOKUP SERVER…

Attempting to connect with SSO…

Endpoint state changed to Registering

************** Lookup Server is connected to OCS ***************

Endpoint state changed to Registered

Lookup server started successfully

UcmaTransport restored connection to Communication Server

Endpoint state changed to Unregistered

ConnectionState: <INITIALIZED>

Disconnected from Communication Server

Finished server disconnect.

UcmaTransport lost connection to Communication Server

UcmaTransport is attempting to reconnect to Communication Server

Attempting to reconnect UcmaTransport

The previous log information is repeated in each Lookup service
log on each Group Chat Server.

Fourth Coffee is the name of our test environment. In our
test environment, Fourth Coffee has MPOP set to one. Each Group Chat Server
registers the Lookup service account, in this case, ocschat@fourthcoffee.com,
against the Enterprise pool. Communications Server sees the Lookup serivce
account as a SIP endpoint, and because MPOP is set to one, it will allow only one
Group Chat Server to register the Lookup service account (ocschat@fourthcoffee.com).
This causes the Lookup service to repeatedly disconnect and then reconnect as
it cycles through each Group Chat Front End Server.

The Fourth Coffee topology consists of a single Communications
Server Enterprise pool that contains two Front End Servers and a Group Chat pool
that contains two Group Chat Servers.  

In this example, the IP addresses of the Group Chat Servers
are 192.168.1.92 and 192.168.1.96. The Communications Server IP addresses are
192.168.1.80 and 192.168.1.81.

GroupChat1 is registered under ocschat@fourthcoffee.com at IP
192.168.1.92. GroupChat2 is at IP 192.168.1.96 and will initiate logon by using
ocschat@fourthcoffee.com. Register events take place on GroupChat1. The other
registered end point (GroupChat2, which is registered using ocschat@fourthcoffee.com)
is signed out, and the following is logged in a SIP stack trace.

TL_ERROR(TF_CONNECTION) [0]0914.0A70::06/17/2010-19:39:34.481.0004c5c6
(SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(157))$$begin_record

LogType: connection

Severity: error

Text: Connection was closed because the
limit on number of incoming connections per user was exceeded

Local-IP: 192.168.1.80:5061

Peer-IP: 192.168.1.92:1109

Connection-ID: 0x300

Transport: TLS

User-Uri: ocschat@fourthcoffee.com

$$end_record

What Does the Lookup Service Do and How Does this Affect the Functionality
of Group Chat?

The following from the TechNet
Library
explains in more detail how the Lookup service works.

The Lookup service connects clients to a Channel service. If
there is more than one Group Chat Server in the deployment, the Lookup service
also functions as a load balancer.

The Lookup service account is assigned a URI that is
provisioned to the Group Chat clients before their users sign in. This URI can
be the default value (OCSChat@<SIP domain>), it can be supplied to
the Group Chat clients by Group Policy, or it can be configured manually. After
a user of a Group Chat client successfully signs in to a Lync pool, the pool uses
this URI to initiate a session with the Lookup service on behalf of the client.

When a deployment includes multiple Group Chat Servers, the
servers’ Lookup service can share the same SIP URI. When a Group Chat client
initiates a connection, the Lookup services act as multiple points of presence
(MPOP) for that SIP address, and the last Lookup service to connect with the
client is the one that assigns a Channel service to the client. If a Lookup
service instance fails, the Front End Server automatically routes subsequent
connection requests to another Lookup service. Even if one server is slower
than the others and it is consistently the last one to respond (and thereby
gets all of the Lookup service requests), it is of little concern from a
scalability standpoint because the process of assigning Channel service URIs to
clients is fairly lightweight.

The Lookup service assigns Channel service instances so that
the workload among all instances is balanced. Every 10 seconds, each Channel
service instance communicates its current user load to all Lookup service
instances. The Lookup services route new sessions to the least loaded Channel
service at the time.

If a Channel service fails, existing sessions are cancelled,
and the clients contact the Lookup service to receive the URI of a new Channel
service. After they reconnect, the new Channel service automatically pushes any
missed messages to the clients.

When a Channel service resumes operation, the Lookup services
do not redistribute existing Group Chat sessions, but the resumed Channel
service instance reports itself as available and will get all subsequent new
client connections until its workload is balanced with those of the other
Channel service instances.

Summary 

Keep the following points in mind when configuring MPOP and
Group Chat:

  • The Lookup Service account is integral to Group
    Chat. Each Group Chat Server represents a registered endpoint instance of the
    Lookup service. Group Chat is dependent on a properly functioning Lookup service
    account. There is no way to use different accounts for the Lookup service.
  • The number of allowed points of presence must
    equal the number of Group Chat Servers for Group Chat to properly function.
  • MPOP is a global setting and cannot be configured
    for a single user, single group, or single pool. Modifications to MPOP affect all
    Communications Server 2007 R2 users.

Lync Server Resources

We Want to Hear from You