Lync Server Support Home
Top Lync Solutions RSS Feed
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
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
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
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.
Keep the following points in mind when configuring MPOP and Group Chat: