Change a Pool Database Instance when the Pool Hosts the Central Management Server

Microsoft Lync Server 2010 communications software introduces the Central Management Server role. By design, this server role does not allow you to alter the back-end database that is used by the Central Management store until you move this role to a new pool. This article explains the steps required to make these changes as well as provides a sample configuration that you can use to model your proposed changes.

Author: Scott Stubberfield

Publication date: December 2010

Product version: Lync Server 2010

Microsoft Lync Server 2010 communications software introduces the Central Management Server role. This role does not allow you to alter the back-end database that is used by the Central Management store until you move this role to a new pool. This article explains the steps required to make these changes and provides a sample configuration that you can use to model your proposed changes.

Pool Overview

Figure 1 provides a visual overview of the various pool and instance components that will be used throughout this article. There is a single pool named POOL01.contoso.com that currently hosts the Central Management Server. The databases for this pool are homed in an instance named SQLOLD.contoso.com\RTC. The purpose of this article is to provide a list of the steps required to move the databases associated with this pool to a Microsoft SQL Server instance named SQLNEW.contoso.com. The pool name and functionality as the Central Management Server will be the same in the end, but in the interim, the Central Management store will be hosted on a Standard Edition server named SE01.contoso.com. It is assumed that the database instance for the Standard Edition server is collocated and is named RTC. It is also assumed that this Standard Edition server already exists in your environment and has been fully deployed. If you do not already have a Standard Edition server defined in your existing topology, complete that task before proceeding. You should also validate that this Standard Edition server is fully functional prior to continuing.

If you are simply interested in moving your Central Management Server to a new host, you can use the Move-CsManagementServer cmdlet.

Figure 1. Overview of pool/instance arrangement

If you try to simply modify the SQL Server instance, you will receive an error that says, "This SQL store cannot be modified because it hosts the Central Management Store."

Note. The procedure documented in this article has been tested in the following scenarios.

	Scenario 1	Scenario 2	Scenario 3	Scenario 4	Scenario 5	Scenario 6
Original Instance	SQLOLD. contoso.com	SQLOLD. contoso.com	SQLOLD. contoso.com	SQLOLD. contoso.com	SQLOLD. contoso.com	SQLOLD. contoso.com
SQL Version	2005	2005	2005	2008	2008	2008 R2
Final Instance	SQLNEW. contoso.com	SQLNEW. contoso.com	SQLNEW. contoso.com	SQLNEW. contoso.com	SQLNEW. contoso.com	SQLNEW. contoso.com
SQL Version	2005	2008	2008 R2	2008	2008 R2	2008 R2

For additional details about how to migrate your instances to SQL 2008, see the sections 3.4.2.1 and 3.4.2.2 in the SQL Server 2008 Upgrade Technical Reference Guide.

For additional details about how to migrate your instances to SQL 2008 R2, see the sections 3.4.2.1 and 3.4.2.2 in the SQL Server 2008 R2 Upgrade Technical Reference Guide

Validate that the Existing Central Management Server Is Functioning Correctly

Before you move to the new Central Management Server host, validate that there are no pre-existing Central Management Server replication issues. To do this, run the Windows PowerShell command-line interface cmdlet shown in Figure 2 on a Front End Server that belongs to POOL01.contoso.com.

Figure 2. 

This cmdlet should produce an output similar to what is shown in Figure 3.

Figure 3. 

Depending on your existing topology, you may see additional replication targets listed in the previous output. Each replica host should show a value of True in the UpToDate column.

Prepare the Standard Edition Server and Move the Central Management Server

The first step is to prepare the Standard Edition server so that it can be used as a Central Management Server host. Run the Prepare first Standard Edition server task from the Deployment Wizard (Figure 4). This task should be run from SE01.contoso.com in our example.

Figure 4. Prepare first Standard Edition server

Next, install the Central Management store databases in the Standard Edition server pool instance. To create the Central Management store databases, run the Windows PowerShell cmdlet shown in Figure 5 on SE01.contoso.com.

Figure 5. 

Note. The previous cmdlet uses the -clean switch. This means that any Central Management store databases that already exist in this instance will be deleted and recreated. If you use the wrong fully qualified domain name (FQDN), this could be a destructive step. Ensure that you are using the correct host and instance name. The use of the -clean switch will bring the deployment to a predictable starting point.

Before you move the Central Management Server to the new server, we recommend that you back up the existing configuration data as a precaution. If the move is successful, these files will likely not be used, but they are a good backup to have.

To back up the configuration data, run the Windows PowerShell cmdlet shown in Figure 6 on SE01.contoso.com.

Figure 6. 

Move the Central Management Server to the Standard Edition server by running the Windows PowerShell cmdlet shown in Figure 7 on SE01.contoso.com.

Figure 7.

Run the Windows PowerShell cmdlet shown in Figure 8 on SE01.contoso.com to ensure that the replication changes have been replicated to all pool servers.

Figure 8.

This cmdlet should produce an output similar to that shown in Figure 9.

Figure 9.

Depending on your existing topology, you may see additional replication targets listed in the previous output. Each replica host should show a value of True in the UpToDate column.

At this point, you should have a functioning Central Management Server running on the server SE01.contoso.com. The next task is to remove the Central Management Server role from your old pool.

Remove the Central Management Server from Your Existing Pool

After the changes to the topology have replicated, you must run the bootstrapper (bootstrapper.exe) process on all servers in the pool that previously hosted the Central Management Server. This will remove the Lync Server Master Replicator Agent and Lync Server File Transfer Agent services from each server.

To complete this step, go to C:\\Program Files\Microsoft Lync Server 2010\Deployment, and then run bootstrapper.exe. Run this task on all Front End Servers that belong to POOL01.contoso.com.

Take Databases Offline and Back Up

To properly back up all databases in the existing pool instance, you have to take them all offline so that they can be backed up together because you will be restoring them to the new pool instance.

At this point, you will take all databases for your user pool offline, so you should prepare your users for limited functionality mode. When you take the databases offline, your users will go into limited functionality mode and your Enterprise Voice features, Call Park application and Response Group application, will not be available. It is expected that the changes to this pool instance will not be long; however, you should be prepared to bring your old instance online should you have issues.

Run the SQL statements shown in Figure 10 in the SQLOLD.contoso.com\RTC instance.

Note. You may notice that you don't have all these databases in the following statements present in your pool instance because some of the databases are installed only if the Enterprise Voice features have been enabled on your pool.

Figure 10.

Your Lync 2010 users will go into limited functionality mode now. They will receive the message shown in Figure 11.

Figure 11. Limited functionality message for Lync 2010 users

Figure 12 shows the Lync 2010 user interface for limited functionality mode.

Figure 12. User in limited functionality mode

The next step is to back up the databases from the old instance to use them on the new instance. To do this, create a folder named C:\Backups on the SQLOLD.contoso.com server, and then run the SQL statements shown in Figure 13 in the SQLOLD.contoso.com\RTC instance.

Figure 13.

Ensure that all seven database backups completed successfully, and then copy C:\Backups from SQLOLD.contoso.com to SQLNEW.contoso.com.

Update Topology Document

Now that you have taken the databases offline and backed them up, you need to make a change to your topology document. You will have to reconfigure the name of the SQL instance used by the POOL01.contoso.com pool in your topology.

To change your topology document, open the Lync Server Topology Builder from any Lync Server in your environment and download the current topology. In the same site as POOL01.contoso.com, right-click the SQL Server stores node, and then choose New SQL Store (Figure 14). In this example, SQLNEW.contoso.com is entered as the SQL Server FQDN and RTC as the Named Instance.

Figure 14. Define New SQL Store

After the new SQL Server store is created, update the SQL Server store that is used by POOL01.contoso.com. Expand Enterprise Edition Front End Pools, right-click POOL01.contoso.com, and then select Edit Properties. Under the Associations section, click the SQL store drop-down menu. Select SQLNEW.contoso.com\RTC.  You will receive a warning message that says, "Warning: User store in use. Database contents must be transferred manually." Restoring the database backups that have already been taken will be discussed later in this article.

When you have finished making this change, publish the topology. Topology Builder will determine that the required databases do not exist in the target database instance and will prompt you to create them.

Note. Topology Builder will also try to create databases on the original SQLOLD.contoso.com server, so make sure that you clear this box.

The step to create these databases in the new instance is required to ensure that the correct permissions are assigned to the instance so that when the databases are restored the permissions are correct.

Next, run the Windows PowerShell cmdlet shown in Figure 15 on SE01.contoso.com to ensure that the Replication changes have been replicated to all pool servers.

Figure 15.

The previous cmdlet should produce an output similar to that shown in Figure 16.

Figure 16.

Restore Databases and Restart Pool Services

Now that you have published the new topology document and have created new databases in your new SQL instance, you need to restore the backups that you made earlier in this process.

In this step, you will switch to the new server and set the databases into single-user mode. Single-user mode is required to restore the backups.

Run the SQL statements shown in Figure 17 in the SQLNEW.contoso.com\RTC instance and on the SQLNEW.contoso.com server. These statements will put the new databases into single-user mode.

Figure 17.

Run the statements shown in Figure 18 to restore the SQL backups that you created earlier and copied to this server.

Note. The following SQL statements assume that you installed all databases to the root of a single drive, which is likely not the case in most circumstances. The paths specified below by the Move parameter are the new locations of the databases on the target server. You should also take note that the instance name is used in the path.

Figure 18.

The statements shown in Figure 19 enable database chaining on the Rtc and Rtcdyn databases.

Figure 19.

The statements shown in Figure 20 enable multi-user access to all databases.

Figure 20.

You now need to restart Lync Server services one server at a time to pick up the new instance name. You should do this in a staged approach to ensure that you do not put all of your users offline at the same time.

Run the Windows PowerShell cmdlets shown in Figure 21 on all Front End Servers that belong to POOL01.contoso.com.

 Figure 21.

Your databases should be online and available for the pool to use now.

Move Central Management Server Back to Pool Host

Now that you have repointed the database instance, you need to move the Central Management Server back to your pool host.

Run the Windows PowerShell cmdlet shown in Figure 22 on a Front End Server that belongs to POOL01.contoso.com.

Figure 22.

Again, as a precaution, back up the existing configuration to zip files. To back up the configuration, run the Windows PowerShell cmdlets shown in Figure 23 on a Front End Server that belongs to POOL01.contoso.com.

Figure 23.

Next, move the Central Management Server back to the original pool by running the Windows PowerShell cmdlet shown in Figure 24 on a Front End Server that belongs to POOL01.contoso.com.

Figure 24.

Run the Windows PowerShell cmdlet shown in Figure 25 on POOL01.contoso.com to ensure that the replication changes have been replicated to all pool servers.

 Figure 25.

This cmdlet will produce an output similar to what is shown in Figure 26.

Figure 26.

Depending on your existing topology you may see additional replication targets listed in the previous output. Each replica host should show a value of True in the UpToDate column.

After the changes to the topology have replicated, run bootstrapper.exe on SE01.contoso.com. This will remove the Lync Server Master Replicator Agent and Lync Server File Transfer Agent services from the server. To do this, go to C:\Program Files\Microsoft Lync Server 2010\Deployment and run bootstrapper.exe.

If this Standard Edition server was temporary and used only for switching your Central Management Server host, remove it from the topology and follow the standard uninstall procedures for a Standard Edition server.

You must also run the bootstrapper process on all Front End Servers in the POOL01.contoso.com pool to install the Lync Server Master Replicator Agent and Lync Server File Transfer Agent services on the server. This is automatically done on the Front End Server on which you ran the move-csmanagementserver cmdlet, so you do not need to run this task on that server. Run this task on all front end servers that belong to POOL01.contoso.com.

You will also need to start the Lync Server Master Replicator Agent and Lync Server File Transfer Agent services. To start the Lync Server Master Replicator Agent and Lync Server File Transfer Agent services on all Front End Servers that belong to POOL01.contoso.com, run the cmdlet shown in Figure 27.

Figure 27.

Note. You should plan to decommission the old SQL Server instance after you have validated that you were able to restore and reconnect to all pool databases.

Run the SQL statements shown in Figure 28 only on SQLOLD.contoso.com. If you run these statements on the wrong SQL Server instance, you could accidentally disconnect the wrong databases.

Figure 28.

Note: Prior to running the previous statements, ensure that any open connections you have to Microsoft Lync Server 2010 Control Panel or Lync Server Management Shell. If you don't close these connections, you will not be able to disconnect the Xds database.

Summary

This article has explained the steps required to make changes to your topology when you want to change the database instance that is used by a pool that is hosting the Central Management Server role.

Lync Server Resources

• Lync Server 2010 documentation in the TechNet Library
• DrRez blog
• Lync Server and Communications Server resources

We Want to Hear from You

• Fan us on Facebook
• Follow us on Twitter
• Send us e-mail