The Microsoft Lync Server 2010 communications software, Archiving Server adds the Lync Server 2010 Archiving service to your deployment. This service and its associated database, LcsLog, store and provision compliance—data for instant messaging that you don’t want to lose. One way to help ensure reliable instant messaging archiving is to host the LcsLog database on a dedicated instance of Microsoft SQL Server data management software. This can be done instead of collocating an instance of SQL Server that hosts the LcsLog database with a server that hosts other Lync Server 2010 services, the Lync Server QoE Monitoring service, or the Front End pool databases. Although these collocation scenarios are supported in Lync Server, they aren’t recommended because they create a single point of failure, along with the risk of service and data loss. You can reduce this risk by moving the LcsLog database from a supported collocation scenario to a dedicated instance of SQL Server.

Introduction

The Lync Server 2010 Archiving service is predated by Microsoft Office Communication Server. The instant messaging archiving solution in Lync Server provides a compliance methodology that is both secure and reliable. The Archiving service’s reliability depends on the server network that hosts it. The supported Lync Server hardware load balancing and Domain Name System (DNS) load balancing features provide the needed reliability to host a highly available Windows Server infrastructure for the Archiving service. It relies on the use of the proprietary Microsoft SQL Server-hosted database (LcsLog) to manage the content and metrics of instant messaging conferences. Microsoft fault-tolerant solutions can be used to help ensure the availability of the LcsLog database.

Microsoft SQL Server 2008 Failover Clustering Services and the Windows Server-based Microsoft Cluster Service both provide a fault-tolerant solution for hosting the LcsLog database. However, the Lync Server Archiving service and database are supported on single-server deployments. The supported single-server installations of the Archiving service and archiving database can provide a single point of failure for an organization’s instant messaging compliance infrastructure. An instance SQL Server that hosts the LcsLog database can be collocated as follows:

  • On a computer that is running Windows Server that hosts the Archiving service
  • On a computer that is running Windows Server that hosts the Lync Server Monitoring QoE service
  • On an instance of SQL Server that is hosting the Front End pool databases

This kind of LcsLog database hosting can result in data loss or the loss of the instant messaging service and other Lync Server services because of an archiving database outage. The threat of these types of issues prompts Lync Server administrators to move the LcsLog database either to an instance of SQL Server that is hosted by using a previously mentioned Microsoft Cluster Service (MSCS) server cluster solution or to a dedicated instance of SQL Server to help ensure the availability of dedicated hardware resources. For details about the supported installation for the Archiving service, see Server Collocation in an Enterprise Edition Front End Pool Deployment.

For details about Microsoft Clustering Services, see the following articles:

Prerequisites for Moving the LcsLog Database

Before you move the LcsLog database, you first need the location of the server or servers that host the Archiving service and the Lync Server archiving database:

1. At the console of a Microsoft Lync Server 2010, Front End Server that hosts the Lync Server Management Shell, run the following Windows PowerShell cmdlets:

Get-CsService -ArchivingServer

Get-CsService -ArchivingDatabase

2. Confirm the location of the Archiving service Filestore. This shared information can be hosted on a computer that is running Windows Server that has the role of a file server or on server access network (SAN) device.

3. From a Lync Server 2010, Front End Server that hosts the Shell, run the following Windows PowerShell cmdlet:

Get-CsService -Filestore

Gathering this data produces the fully qualified domain names (FQDNs) of the devices that are hosting the previously described services and resources, and the identifying information for the Archiving service’s Filestore. This information is needed for moving the LcsLog database to its new location.

It’s necessary to confirm the current archiving configuration of Lync Server. This helps determine the effect that disabling the Archiving service has on the Lync Server instant messaging deployment. To review this information, use the Shell to issue the following Windows PowerShell cmdlets:

  • Get-CsArchivingConfiguration   Use with a simple single-site deployment
  • Get-CsArchivingConfiguration -Identity:sitename   Use with a multiple-site deployment

If the BlockOnArchiveFailure parameter for the archiving configuration is set to true, all instant messaging and conferencing is stopped while the Archiving service is malfunctioning or stopped.

Note. Instant messaging will remain functional on a Lync Server network when the BlockOnArchiveFailure parameter is set to true and the instant messaging configuration is disabled or malfunctioning under the following circumstance. When the outgoing Message Queuing (also known as MSMQ) service queue of the Front End Server reaches its capacity, instant messaging will be stopped between peers on the network. When the Lync Server Archiving service is again fully functional, the Message Queuing service will send the queued instant message information to an instance of SQL Server that is hosting LcsLog database where it will be archived.

To help ensure the organization’s instant messaging compliance policy is fully adhered to, the Lync Server Front-End services on each of the Front End pool should be stopped while the Lync Server archiving database is being moved. This stops all instant messaging and stops the Web Conferencing service on the network, ensuring minimal data loss.

This article describes how to move the Lync Server archiving database (LcsLog) to a dedicated instance of SQL Server when the LcsLog database is deployed in the following supported configurations:

  • The Lync Server archiving LcsLog database and Archiving service are installed in a supported server collocation scenario that includes either the Lync Server QoE Monitoring Service or the Archiving service.
  • The Lync Server archiving LcsLog database is installed on the same instance of SQL Server that hosts the Front End pool databases.

Back up the LcsLog Database

By design, Microsoft SQL Server provides point-in-time database backup and restore features (a process). This proprietary database backup and restore process can be used to provide point-in-time database backups for the LcsLog database. To prepare to back up the LcsLog database, check with the organization’s SQL Server administrator for the following information:

  • Is there a SQL Server task that manages differential backups of the LcsLog database
  • Is there a SQL Server task that manages full backups of the LcsLog database
  • Is there a SQL Server task that manages backups of the LcsLog transaction log
  • What is schedule for the SQL Server backup procedures for the LcsLog database
  • Can a full backup of the LcsLog database be scheduled prior to moving the database

Note. If the SQL Server backup and restore feature is being used to back up databases that are local to its instance of SQL Server, those database backups can be restored only to the same instance of SQL Server where they originated from.

Third-party vendors provide an array of software products that can be used to manage enterprise-level system file backup and restore processes. Research the type and the frequency of the system backup procedures that are applied to the LcsLog database’s LcsLog.mdf (data) and LcsLog.ldf (transaction log) files. System backups are usually scheduled to run on a network during non-peak hours to help ensure the efficient use of network bandwidth. System backups can be scheduled to perform both full and differential backups as needed. Make sure that there is a full system backup taken of the LcsLog database files (LcsLog.mdf (data) and lcsLog.ldf (transaction)) just prior to performing the move of the LcsLog database to the new instance of SQL Server.

Windows Server 2008 and Windows Server 2003 also provide file system backup and restore services. For details about SQL Server and Windows Server backup and restore procedures, see the following:

Move the LcsLog Database

Warning. Before using following procedures, make sure that all the information that is listed in the Prerequisites for Moving the LcsLog Database and Back up the LcsLog Database sections of this article have been reviewed and the suggested precautions have been implemented.

The steps that are required to move the LcsLog database are designed to be completed as a process—one procedure right after the other.

The following process for moving LcsLog database from its current location to a dedicated SQL Server resource has several procedures and is in two parts:

Part 1

1. Stop the Archiving Service.

2. Detach LcsLog.

3. Copy the LcsLog Database Files.

4. Attach LcsLog.

Part 2

1. Update the current SQL Store associations.

2. Update the legacy SQL Store associations.

3. Connect the Archiving service with the target instance of SQL Server that is hosting LcsLog.

Part 1

Part 1 of the Lync Server LcsLog archiving database move describes the steps that are needed to move the Archiving service database (LcsLog) from its current location to a dedicated SQL Server resource.

Important. To ensure that the organization's compliance procedures are met, it is important that all instant messaging that requires archiving be halted for the Front End pool prior to stopping the Archiving service.

Stop the Archiving service

The best time to perform the planned backup procedure for the Archiving service database (LcsLog) is immediately after the Archiving service has been stopped and instant messaging has been halted for the Front End pool. This helps ensure minimal data loss for the LcsLog database.

1. On the computer running Windows Server that is hosting the Archiving service, click the Start button, and then click Run.

2. Type services.msc, and then click OK.

3. Locate the Lync Server Archiving service in the list of services, and then right-click it.

4. Click Stop.

5. Ensure that the Lync Server Archiving service is stopped.

Locate the LcsLog Database

Note. The LcsLog database files could be located on the local hard drives of an instance of Microsoft SQL Server or at a shared location on the network. Confirm the absolute location of the LcsLog database files with the SQL Server administrator before you begin this procedure.

1. On the instance of SQL Server that hosts the LcsLog database on the Programs menu, open the Microsoft SQL Server Management Studio Console.

2. Expand the Databases node in the tree view pane.

3. Locate the LcsLog database, and then right-click it. Click Properties.

4. In the Select a page pane, and click Files for the LcsLog database.

5. In the Details dialog box, find the location of the LcsLog database files.

Detach the LcsLog Database

1. On the Tasks menu, click Detach

2. Click OK to detach the LcsLog database from the instance of SQL Server.

3. Locate the LcsLog database files by using Windows Explorer.

  • Their default names are lcslog.mdf and lcslog.ldf.
  • Their default installation location is <LocalDrive:>\CsData\ArchivingStore\(default)\dbpath or CsData\ArchivingStore\(default)\logpath folders.

If the LcsLog database files are stored on a file server that can be accessed by the target computer that is running SQL Server and if this is acceptable, leave them there. The LcsLog database files don’t necessarily need to be copied to a new location.

Copy the LcsLog Database Files

1. In Windows Explorer, right-click the ArchivingStore folder, and then click Copy.

2. In Windows Explorer, locate the destination folder (you’ll paste the file into this folder), and then click it.

3. Right-click the destination folder, and click Paste.

4. On the target (destination) computer that is running SQL Server, open the Microsoft SQL Server Management Studio console.

5. Expand the Databases node, and then right-click it.

6. Click Attach, and then click the Add button in the Attach Databases dialog box.

7. Use the Browse button to locate the ArchivingStore\(default)\dbpath\lcslog.mdf file and select it, and then click OK. The Attach Database dialog box lists the full path to both the lcslog.mdf and the lcslog.ldf files.

8. In the Attach Database dialog box, click OK. This completes the operation.

9. Use the Object Viewer section of the Microsoft SQL Server Management Studio console to expand both the Security node and the Logins node.

10. Locate the SQL Server login for the domainName\RTCComponentUniversalServices, and then double-click it to access its Properties dialog box (see Figure 1).

Part 2

Part 2 of the Lync Server LcsLog archiving database move requires the use the Lync Server 2010 Topology Builder. It’s used to associate the FQDN of the new archiving database servers to the existing Lync Server archiving store.

Update the Current SQL Store Associations

1. On a supported computer running Windows Server or a Windows client computer, click the Start button, click Programs, and then start the Lync Server 2010 Topology Builder.

2. Click download the current topology option from the list of topology choices.

3. Save a copy of the current topology to a local or shared folder.

4. In the tree view pane of the Topology Builder (see Figure 1), locate the Archiving Servers node, and then expand it.

5. Locate and then select the FQDN of the Microsoft Lync Server 2010, Archiving Server that needs to have its SQL Server archiving database association updated to reflect the new location of the target instance of SQL Server that now hosts the LcsLog database.

6. In the Actions dialog box, click Edit Properties, and then update the current SQL Server store associations.

Update the Legacy SQL Server Store Associations

1. In the Lync Server 2010 Topology Builder, click the New button for the legacy SQL Server store associations that need to be updated to reflect the FQDN of the target instanced of SQL Server that now hosts the LcsLog database.

2. Type the FQDN of the target instance of SQL Server that now hosts the LcsLog database.

3. If it’s hosted on Named Instance, be sure to add the name of that instance of SQL Server. Otherwise, keep the Default option that you selected, and then click OK (see Figure 1).

Figure 1. Editing the Archiving Server properties by using Lync Server 2010, Topology Builder

4. In the tree view pane, click Lync Server 2010.

5. On the Action menu, click the Publish Topology link. This starts the Publish Topology wizard.

6. Verify that in the Create Databases page the FQDN of the target instance of SQL Server that now hosts LcsLog is both listed and checked. Click Next.

7. Wait for the Publishing Topology process complete successfully.

8. On the Publishing Wizard Complete page, click Finish.

9. In the tree view pane, locate the Archiving Server node, and then expand it.

10. Select the FQDN of the source Archiving Server. The details pane should show the FQDN of the instance of SQL Server that now hosts the LcsLog database.

Connect the Archiving Service with the Target Instance of SQL Server that is Hosting the LcsLog Database

1. On the computer that is running Windows Server and is hosting the Archiving service, click the Start button, and then click Run.

2. In the box, type services.msc, and then click OK.

3. From the list of services, locate the Archiving service, and then right-click it.

4. Click the Start option.

5. From the same computer, click the Start button, and then click Run.

6. In the box, type eventvwr.msc, and then click OK.

7. In Windows Event Viewer, expand the Applications and Service log node, and then select the Lync Server node.

8. Verify the following event, ensuring that the Lync Server Archiving service has successfully connected with the target instance of SQL Server that is hosting the LcsLog database. Following is an example of a successful connection.

Log Name:      Lync Server

Source:        LS Archiving Server

Date:          12/20/2010 6:06:36 PM

Event ID:      30617

Task Category: (1014)

Level:         Information

Keywords:      Classic

User:          N/A

Computer:      LyncArchivingServer.contoso.com

Description:

The service established connection to the back end SQL Server.

Database connection string : driver={SQL Server Native Client 10.0};Trusted_Connection=yes;AutoTranslate=no;server=LyncArchivingDatabaseServer.contoso.com;database=LcsLog;

Cause: N/A

Database Permissions and Firewall Configurations

After moving the LcsLog database to the target instance of SQL Server, following are a couple of details that need to be taken into consideration to ensure that access to LcsLog database can take place:

  • The SQL Server database-level permissions for the LcsLog database must match those of the legacy installation of the LcsLog database.
  • The Windows Firewall on the computer running Windows Server that hosts the instance of SQL Server must be configured with the correct port exceptions that allow the Front End pool access to the instance of SQL Server.

Database Permissions

After LcsLog is attached to the target instance of SQL Server, the LcsLog database should retain the default SQL Server login that was assigned to it when it was initially created. The original SQL Server login for the LcsLog database is the domainName\RTCComponentUniversalServices security group. Figure 2 shows the properties of the SQL Server login for the domainName\RTCComponentUniversalServices security group.

Figure 2. RTCComponentUniversalServices SQL Server login Properties dialog box

The SQL Server login shown in Figure 2 is required for the Archiving Server and Archiving service to operate correctly.

Firewall Configurations

The target instance of SQL Server has to be accessed by using the service ports that it is designed to use for SQL Server client requests. The following Microsoft documentation explains how to configure the firewall of a computer running Windows Server, allowing access the listening ports of the instance of SQL Server:

Summary

The process of moving the LcsLog database to a new instance of SQL Server could be the first step in an organization’s move to a fault-tolerant Archiving service solution. Moving the LcsLog database may also be a necessary step in a hardware upgrade process for the SQL Server database that hosts the LcsLog database. Either way, in a non-fault–tolerant Archiving service and/or archiving database deployment, this process has to be completed as efficiently as possible to help ensure that the compliance standard for Lync Server Web Conferencing and instant messaging meets an organization’s requirements.