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.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
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
(firstname.lastname@example.org) 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 email@example.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 (firstname.lastname@example.org)
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
10:38:41 AM OCS
"Restored connection to Office Communications Server."
10:38:41 AM OCS
"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
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
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
Initiate connection to OCS: URI=sip:email@example.com,
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, firstname.lastname@example.org,
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 (email@example.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 firstname.lastname@example.org at IP
192.168.1.92. GroupChat2 is at IP 192.168.1.96 and will initiate logon by using
email@example.com. Register events take place on GroupChat1. The other
registered end point (GroupChat2, which is registered using firstname.lastname@example.org)
is signed out, and the following is logged in a SIP stack trace.
Text: Connection was closed because the
limit on number of incoming connections per user was exceeded
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