Category Archives: Group Chat

SQL Database Mirroring with Lync Server 2010 Series – Group Chat

In previous posts in this series on Lync Server 2010 and SQL Mirroring I’ve covered the prerequisites, how to failover your SQL databases and how the backend Lync databases behave once you’ve failed over. In this final post, I’m going to cover how Group Chat behaves when it’s database is mirrored and subsequently failed over.

As with my other posts regarding SQL mirroring and Lync Server 2010, I must stress that this is completely unsupported by Microsoft. I attempted this deployment scenario purely as a “could it be done” exercise only. Do not take this as gospel and do not deploy it in a production environment.

Preparing the DR scenario

So the first thing we need to do is get everything setup to support Group Chat in the DR site. This involves mirroring the Group Chat database between the Principal and Mirror SQL server nodes in each site and ensuring the SQL mirror node is setup to allow a Group Chat server to connect to it.

Mirroring the Group Chat database and preparing the SQL Mirror node

I covered this in the prerequisites post, so we can assume that we’ve followed the steps to mirror the Group Chat database already.

But before we can failover the Group Chat database, we need to make sure the mirror node is setup so the Group Chat Server can connect to it. To do this, we need to make sure security is setup on the SQL server mirror node to support Group Chat. TechNet covers the steps required to do this throughly in this article, so all your need to do is follow the steps listed on your SQL mirror node.

Setting up a standby Group Chat server

The first caveat to throw in the mix here is that to bring up Group Chat in the DR site, you mustn’t actually have the Group Chat server setup already. This is because Group Chat topologies come in either single or multiple server flavours, so if it were already part of the topology it would be used by users. In this scenario, we want to keep this server as a standby and not used when the production site is online.

The server you’ll be using for Group Chat will need to be a cold standby machine in DR that already has a certificate issued to it for its FQDN and the Group Chat prerequisites installed. Once this is setup, it’s ready to have Group Chat installed on it when you need to activate your DR plan.

Activating Group Chat in the DR site

So once you’ve failed over your database and made the SQL mirror node the Principal, it’s time to get Group Chat up and running again in your DR site. To do this, you essentially need to remove the Group Chat server you had in the primary site because a 1:1 to relationship exists between a Group Chat server/pool and a Lync Server 2010 registrar (Standard Edition server or Enterprise Edition pool). Additionally, the server we’ll have prepared in the DR site will have a different server name.

Cleaning the Lync Topology

Firstly we need to remove the old Group Chat server from the Lync topology. This involves running the following cmdlets:

Remove-CsTrustedApplicationPool -identity <FQDN of failed Group Chat server>
Remove-CsTrustedApplication -identity <FQDN of failed Group Chat server> 

These cmdlets will remove references to the failed Group Chat server from your Lync topology, allowing you to spin up a new Group Chat server in the DR site. If we leave the old Group Chat server in the topology, when we try to add a new server in DR it picks up this configuration automatically and we can’t define a new next hop pool.

Making a hosts file change

Next we need to make a local hosts file change so that the FQDN of the principal SQL server resolves to the IP address of the mirror SQL server in the DR site.

We need to do this because although the Group Chat services are somewhat SQL mirroring aware (I witnessed a connection from my Group Chat server to my SQL mirror node on TCP port 1433 after I failed over), the good news doesn’t last and eventually the Lookup and Channel services stop functioning. Modifying the hosts file overcomes this and the services stay started.

Install Group Chat in the DR site

Now that we’ve cleared references from the topology and our hosts file is modified, we can begin the install of Group Chat in the DR site by installing Group Chat using the Installation Wizard as normal:

  1. When prompted to provide a SQL server and instance name, provide the principal SQL server name and the Group Chat database name. Once we commit this configuration, it will write new rows to the tbl.Config table in the Group Chat database to allow this Group Chat Lookup/Channel server to work.
  2. When prompted at the next screen, assign the previously imported certificate to the new Group Chat Server.
  3. Following this screen you will see the next hop address and site. These will all be greyed out because the tbl.Config database has already been populated with them. We’ll fix this in step 5.
  4. Once deployment has completed, ensure all Group Chat services start. If some services fail to start, consult the local Lync Server event log and troubleshoot SQL database access.
  5. Next, using the Server Config Tool, set the next hop Lync pool that Group Chat is configured with to the FQDN of the DR Lync Standard Edition server or Enterprise Edition pool. This will modify the tbl.Config table for us in the SQL database.

Once you’ve got Group Chat installed, you will want to run Get-CsTrustedApplicationPool to ensure the Lync topology has been updated with the new Group Chat server details so your FE pool in DR can talk to it.

Validation and Summary

Once you’ve followed the steps above, you’ll want to fire up your Group Chat client and attempt to sign in. If you can’t sign in straight away, check that your Group Chat services are started ok and that a Trusted Application pool exists in Lync for your DR Group Chat server.

This post (and the series) has really been a “proof of concept” exercise only, but it does show that Group Chat can utilise a mirrored SQL database, with some pretty decent configuration change. As I said, don’t use this blog post as verification when making a design decision around your DR requirements for Lync.

Thanks for following along, I hope this series has helped you understand the challenges around SQL mirroring in Lync in more detail and why Microsoft doesn’t support it.

Doing it Right – Deploying a Lync 2010 Group Chat Multiple Server Environment

Deploying a resilient, highly available Lync Server 2010 environment is high on the list of requirements for most organisations during the design phase of their deployment and for companies deploying Group Chat, that’s no exception.

Each Group Chat server can support 20,000 users and you can deploy up to 3 of them in a pool, meeting all but the world’s largest companies requirements for scale. It’s not like this is an everyday deployment scenario, but it will be commonplace for those organisations requiring resiliency for Group Chat (think financial orgs, trading companies, global teams with “follow the sun” operations).

Unfortunately some of the TechNet documentation is a bit unclear around how to successfully deploy a multiple server Group Chat environment but during a recent Microsoft support case, we discovered the right way to do things. In this post I’ll cover how Group Chat servers interact with the Lync topology and how to correctly get your servers up and running.

Understanding a Multiple Server Topology

If we take a look at the Components and Topologies for Group Chat Server TechNet article, we can quickly get an idea of the two (single and multiple server) Group Chat Server topologies that can be deployed. The multiple server topology, as you can see below, has a lot of moving parts:

Lookup Service + Channel Service = Group Chat Server

Essentially a Group Chat Server is just two services that plug into a SQL database – the Lookup and Channel services – and the Web service.

The Lookup Service is how your Lync Front End pool speaks to each Group Chat Server (via the SIP URI) in the Group Chat pool. Once connected, this service then assigns a Channel Service to the user so they can access their chat rooms.
The Channel Service does most of the heavy lifting of chat room data in Group Chat and also acts as a relay to other Channel Services running on other Group Chat Servers. Finally, the Web Service acts as a front-end for clients to download file attachments in chat rooms.

Just to be clear here, the Lookup Service is able to perform load balancing because it’s just a SIP enabled account, so no need for a hardware load balancer in Group Chat (bonus right?). 🙂

For more in-depth info on how the Group Chat services work, check out this really good scenario article on TechNet (it refers to OCS 2007 R2, but it’s still relevant).

The SQL database is key

As I mentioned in my post about Group Chat migration, the database is the key component in a deployment as it holds all the configuration and critically, the chat room data that your users will create. The Group Chat Configuration Tool connects directly to it and reads/writes configuration to and from the tbl.Config table and the Channel Service connects to it to serve up chat rooms to users. Essentially, each Group Chat server in the topology will connect to this database and become the middle-man between users and the raw chat data stored in SQL.

Making this SQL database highly available (i.e. putting it on a SQL cluster) is important because we don’t want it to be the single point of failure in our topology.

Defining the Group Chat Pool in Topology

When we run the Group Chat Deployment Wizard for the first time, pointing it to a new, empty database, we have to define the Group Chat Pool FQDN. In doing this, the Deployment Wizard creates a new Trusted Application Pool in the Lync topology with this name. Within this trusted application pool in our topology, it creates a trusted application for the first Group Chat server that is a member of the Group Chat pool. As we run the Deployment Wizard on subsequent Group Chat servers, it creates additional trusted applications underneath out Group Chat pool.

So basically within Topology Builder, the Group Chat pool looks like a Lync Front End pool (with servers sitting inside a pool), but it is represented as a trusted application pool because Group Chat isn’t a dedicated, topology aware server role.

Now it gets interesting, because you might think “I just set up DNS and certificate the same way I would a Lync Front End pool”, but that’s not strictly true..

Certificates and DNS for a Group Chat Pool

DNS records should be created the same way you would for a DNS load balancing Front End pool i.e. two A records for the pool FQDN pointing to the IP addresses of the two servers (e.g. and an A record for each server’s FQDN. Pretty straightforward, but certificates are where it deviates.

You should get your certificates for Group Chat as per the TechNet article Obtaining certificates but the gotcha here is that you mustn’t have any SANs (subject alternate name) listed on the certificate assigned to your Group Chat servers. If you do, it will cause a divergence in chat rooms and you will hear reports of users only seeing some users in their chat rooms, let me set the scene:

  • User A will be in Chat Room 1 and see users B, C and D.
  • User E will be in the same chat room (Chat Room 1) but will perhaps see users B, F and H.

Basically, the Group Chat Channel Services don’t talk to each other properly and the member list of a chat room isn’t consistent. The only common name on the certificate assigned to each Group Chat server should be the pool FQDN e.g. No SANs. 🙂


Group Chat is a great tool for a lot of businesses and ensuring it is available 24/7 is critical for organisations that rely on getting the same persistent message out to their teams. Making sure it’s resilient and supports your user base is key to providing a good service to the business.

There is a lot involved with getting a multiple server Group Chat topology up and running (especially after you’ve probably had some dramas just getting one server going) but hopefully this post has given you more of an insight into how Group Chat works in Lync Server 2010 and how to get a nice resilient, load balanced environment.

Cumulative Update 5 (CU5) for Lync Server 2010 Released

CU5 for Lync Server 2010 has arrived! This update fixes the “no video in RCC” behaviour (whereby an RCC cannot make a video call at all), as verified by Jamie Stark here on twitter.

Here are the download links:

  • Updates for Server. You just need the LyncServerUpdateInstaller.exe to update each server. Download here and view the corresponding KB article explaining what’s fixed.
  • Update for Client (64-bit) download here.
  • Update for Client (32-bit) download here.
  • Update for Group Chat Client download here.

Happy patching!

RCC gets video

Update – Fri 02 Mar 8:30am GMT

I wanted to touch on this a bit more in light of Jamie Stark’s post on NextHop overnight. Some important caveats are raised and I want to highlight a few here:

“For RCC-enabled users to make peer-to-peer video calls and join video conference calls, they need a webcam and a headset, handset, or speakerphone for their workstation or laptop.”

“The update does not support the scenario known as Split AV, where audio is delivered through the desk phone and video comes through the Lync client. The Split AV scenario provides an inconsistent and oftentimes suboptimal end-user experience, because the audio and video use different network paths and frequently lose sync. This means when a user starts an audio call using a PBX phone, they cannot add video to that call. If a call is started using the Lync client as the audio endpoint, it can be escalated to include video.”

“The February 2012 update is all client-side with Lync 2010.”

So if you run RCC today, you’re getting video back. Happy days!

Migrating Group Chat to Lync Server 2010

Group Chat is a bit of tricky beast in OCS 2007 R2/Lync Server 2010. It can take a bit of caressing to get it operating properly and I regularly see folks with problems on the TechNet forums that need a bit of a hand, so you’re not alone if you have problems deploying it.

Migration Pains

So when it comes to actually migrating your existing Group Chat environment from OCS 2007 R2 to Lync Server 2010, the whole process can be fraught with danger. The Microsoft TechNet library article does a decent job of explaining how to do this, but when it comes to running a SQL query to replace the necessary table entries it can become a bit of confusing.

The Process

In this post, I’ll show you a quick and easy way to get your data across and your GC up and running on Lync.

Moving the database

When you approach this, you might think “ok, let’s deploy a new Group Chat environment and then migrate the data over”, but this is where I stumbled first time also. Contrary to judgement, you don’t provision any new Lync Server 2010 Group Chat servers or databases at all. The first thing you need to do is move the database from OCS 2007 R2 before you do anything on the Lync side by following this process:

  1. Open Group Chat Server Configuration on the old Group Chat server/s and stop the Channel and Lookup services on all servers. This will stop any changes being made to the database like new chats in chatrooms.
  2. Log onto the old SQL server and open the instance that contains the Group Chat database.
  3. Backup the Group Chat database to file and move it to the new SQL server.
  4. Open SQL Server Management Studio on the new SQL server and restore the backup into the new instance you’re using.

Preparing SQL and modifying the database

Next, you need to make sure your new SQL server is setup for the Group Chat database and that your Lookup and Channel service accounts have the necessary access. Following that, you need to manually edit a table to allow a new configuration to be made:

  1. Assign your Group Chat Lookup, Channel and Web service accounts to the instance using this process and make sure they have dbowner rights on the database.
  2. Make your Group Chat Lookup, Channel and Web service accounts a member of the local Administrators group on your Group Chat server.
  3. Find the table called tbl.Config and remove all the rows that reference both your old OCS Group Chat servers and your OCS Front End pool or Standard Edition servers.

This will allow you to populate the table with new data when you install Lync Server 2010 Group Chat. Once you’ve removed all these rows, the fields in the Group Chat Server Configuration Wizard are free to be edited (and are no longer greyed out if you just point the wizard at the database without modifying these rows).

Installing Group Chat

Now that we’ve prepped our database, we can log onto the new Lync Server 2010 Group Chat server and begin a new installation as documented here. When prompted to specify a server and database name, you’ll put in the FQDN and database name of the server and database you just worked with i.e. the new one. The GC Server Config Wizard will pick up some config (from the tbl.Config table), but it will mostly be blank so you can config new settings like your Lync 2010 Front End pool as the next hop.

Once the wizard is complete and you start your services for the first time, you’ll be prompted to upgrade the database from OCS 2007 R2 to Lync Server 2010. Press OK on this and let the wizard do it’s thing. Following this, your services should (hopefully) start (and stay started) OK. If they don’t, check the event log for database access or certificate related issues.

In Summary

As always, make sure you backup and make a copy of your database before you do this, just in case. If you have the resources, test this in a non-production environment beforehand so you don’t incur unnecessary downtime.

Hope this helps you understand Group Chat migration a bit better. I know it was a steep learning curve for me when I first attempted it.

Lync Server 2010 Group Chat now supported on SQL Server 2008 R2

Just a quick one to spread the word that Lync Server 2010 Group Chat is now supported by Microsoft on SQL Server 2008 R2. Official word is on NextHop over here.

This is great news after the original announcement in April that SQL Server 2008 R2 was supported for all what I call “first class” Lync Server database requirements e.g. Front End pool, Archiving, Monitoring databases.

To extrapolate from this, here is what it means for everyone using or planning to use Lync Server 2010 Group Chat:

  • No longer are two different versions of SQL Server required to be deployed (e.g. 2008 and 2008 R2) in your environment to be in a Microsoft supported scenario.
  • Those organisations planning Lync Server deployments today that include Group Chat can design their deployments on a consistent SQL Server 2008 R2 platform and be safe in the fact that they will be supported by Microsoft in production.

Time to go plan your SQL consolidation projects. 🙂