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 R2\Group Chat Server\Logs, 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