Most of the workload of a Group Chat Server is performed by the Channel service. The Channel service accepts incoming messages, registers and lists the online participants within a channel (known as a Chat Room in the user interface), and retransmits messages to the other channel subscribers. The Channel service also implements logic for channel management, chat room invitations, search, and new content notifications.

When the Group Chat feature is provided by an array of Group Chat Servers joined to the same pool, each Channel service communicates with the others to relay new messages to the clients connected to each member of the array, and each ascertains the operational health of the other Group Chat Servers. Because each Channel service gets its configuration information from a common back-end database, all are configured identically.

The Channel service registers as a trusted service in the Active Directory Domain Services (AD DS) when the Group Chat Server is activated. When a deployment includes multiple Group Chat Servers, each instance of the Channel service is assigned a unique Session Initiation Protocol (SIP) Uniform Resource Identifier (URI), which is the Globally Routable User Agent URI (GRUU) setting of the corresponding trusted service. These GRUUs allow the Lookup service to assign users to specific Channel service servers.

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 is represented by a URI that is provisioned to the Group Chat clients before their users sign in. This URI can be the default value ( OCSChat@ <user’s 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 Front End Server, the Front End Server uses this URI to initiate a session with a Lookup service on behalf of the client.

When a deployment includes multiple Group Chat Servers, the servers’ Lookup services 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.

Because files attached to chat messages must be available to multiple users within a channel and from the chat history, peer-to-peer (P2P) file transfer is not sufficient. The Web service provides a mechanism for file exchange within the context of channels.

Group Chat clients must provide specific tokens to upload or download files. These tokens are provided in-band by the Channel service to authorized subscribers.

When a deployment includes multiple Group Chat Servers, all servers use a Universal Naming Convention (UNC) path that points to a common Windows share where the actual files reside. End users are not permitted direct access to this share. They must go through the Web service.

Although Group Chat clients never communicate directly with a Lookup service or Channel service (that is, they are always proxied through one or more Front End Servers), clients connect directly to a Web service instance when they upload and download files to and from a chat room. For the file transfer function to be available to remote users without using a virtual private network (VPN) or to federated users, the Web service URIs must be resolvable and routable from the Internet.

The Compliance service uses Microsoft Message Queuing (also known as MSMQ) to collect Group Chat messages and events from Channel service instances and uploaded files from Web service instances. The Compliance service archives these messages as files formatted according to the type of Compliance adapter you selected during installation. The Compliance service comes with a customizable XSLT transform that generates XML files for pickup and further analysis by a custom program. Compliance adapters are also available from Akonix, Assentor, and Facetime that enable the Compliance service to generate output file formats compatible with archiving solutions from those vendors.

Before archival, messages are staged in a SQL Server database separate from the one used by the Group Chat Server. The two databases can coexist on the same computer, but if the workloads are high enough to degrade performance they should be located on separate SQL Server instances.

Unlike the back-end database for the Office Communications Server 2007 R2 Archiving Server, this database stores the messages for the duration of the archive retention period, the back-end database for the Compliance service stores records only temporarily. The data is extracted according to the Compliance server’s Conversation interval in minutessetting, is written to a file, and then placed in a shared directory, where it can be picked up by the third-party or custom compliance system. After the compliance system has picked up the data, the XML output files and uploaded files can be deleted to prevent loss of available disk space.

You can also use the Compliance service to archive uploaded files.

The Compliance Server does not archive instant messages, even if the instant messaging (IM) session was launched from the Group Chat client. If your organization wants to archive IM sessions, you must deploy the Archiving Server role on a separate server.