• Move the Lync Server 2010 Archiving Service Database (LcsLog) to a new Instance of SQL Server

    Posted over 3 years ago
    by DrRez_}

    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.

    Author: Mike Adkins

    Publication date: July 2011

    Product versions: Lync Server 2010, 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.

    Keywords: LcsLog, archiving, instant, messaging, compliance, move, database, SQL, server, service, Front End, pool

  • Microsoft Lync Server 2010 Resource Kit: Instant Messaging

    Posted over 3 years ago
    by DrRez_}

    The Instant Messaging chapter of the upcoming Microsoft Lync Server 2010 Resource Kit book provides details about how SIP is used for instant messaging (IM) in a Lync Server 2010 deployment. This chapter is being developed. It describes collaboration scenarios that use IM and details the internal processes that support these scenarios. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

     

      

    Author: Jared Gradle

    Publication date: July 2011

    Product version: Lync Server 2010 and Lync 2010

    The upcoming Microsoft Lync Server 2010 Resource Kit book will provide in-depth technical content about Lync Server 2010. The book will focus on professionals who want to understand more about how the product works internally. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

    Introduction

    If you’re setting up or supporting Lync Server 2010, a good practice is to develop your understanding of how IM works in a Lync Server deployment. This means learning about:

    • What IM communication and collaboration looks like for Lync 2010 users
    • How Lync 2010 signs in, subscribes to users’ Contacts lists, receives server configurations and policy settings, and starts and elaborates on IM sessions by adding people, program sharing, or both

    An understanding in these areas can support you when planning for client sign-on methods (manual or automatic configuration) and when troubleshooting.

    Summary

    This chapter describes how Lync Server supports a Lync 2010 IM session and includes detailed descriptions about the SIP traffic that results from users starting an IM conversation (between two users) and escalating the conversation into an IM conference (with more than two users). Adding in program sharing is also covered.

    Lync Server Resources

    We Want to Hear from You

    Keywords: SIP, Lync IM, program sharing, OCSLogger, Snooper, Network Monitor, SDP, ICE, TURN

     

  • Microsoft Lync Server 2010 Resource Kit: Enhanced Presence

    Posted over 3 years ago
    by DrRez_}

    The Enhanced Presence chapter of the upcoming Microsoft Lync Server 2010 Resource Kit book provides information about the enhanced presence service, which relays presence information between two communication entities in Microsoft Lync Server 2010 communications software. This chapter is being developed. It describes the enhanced presence data model and enhanced presence operations, including publication and subscription. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

     

     

    Author: Kurt De Ding

    Publication date: July 2011

    Product versions: Lync Server 2010 and Lync 2010

    The upcoming Microsoft Lync Server 2010 Resource Kit book will provide in-depth technical content about Lync Server 2010. The book will focus on professionals who want to understand more about how the product works internally. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

    Presence plays an important role in facilitating efficient real-time communications. Presence refers to information used to describe an entity’s availability, willingness, or capability to communicate with other entities. The presence information can help a communicating party determine if, when, and how to contact other parties.

    In a Microsoft Lync Server 2010 deployment, a communication entity can be a user or a trusted application such as a Web service, an interactive bot, or the Lync Server Response Group application. The user corresponds to a security principle represented by an Active Directory Domain Services User object and the trusted application is represented by an Active Directory Contact object. A communication entity that makes its presence available is referred to as a presence entity.

    This chapter describes the enhanced presence data model and enhanced presence service operations, including publication and subscription.

    Summary

    In this chapter, you learn about the enhanced presence service provided by Lync Server 2010 that relays presence information between two communication entities. The process involves SIP-based messaging to enable the presence publication, subscription, and querying. This presence system is versatile and can handle any application-specific presence data. The versatility is supported by a flexible XML-based presence data model as represented by the enhanced presence category.

    Lync Server Resources

    We Want to Hear from You

  • Microsoft Lync Server 2010 Resource Kit: Troubleshooting Specific Workloads

    Posted over 3 years ago
    by DrRez_}

    The Troubleshooting Specific Workloads chapter of the upcoming Microsoft Lync Server 2010 Resource Kit book provides examples of how to troubleshoot workloads in Microsoft Lync Server 2010 communications software. This chapter is being developed. It focuses on the Enterprise Voice workload, describes troubleshooting scenarios, and covers many of the tools that are used to perform root cause analysis. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

     

     

    Author: Brandon Bernier, Kent Tilger

    Publication date: June 2011

    Product version: Lync Server 2010, Lync 2010

    The upcoming Microsoft Lync Server 2010 Resource Kit book will provide in-depth technical content about Lync Server 2010. The book will focus on professionals who want to understand more about how the product works internally. You can download this and other Microsoft Lync Server 2010 Resource Kit chapters from the Download Center.

    Selecting the appropriate tools for troubleshooting is one of the most important steps in performing root cause analysis. There is a wide range of troubleshooting tools available to the Lync Server administrator. Many of those tools are discussed in the Troubleshooting Basics chapter of this book; other tools are beyond the scope of this book. Troubleshooting Specific Workloads provides you, the Lync Server administrator, with the knowledge necessary to determine root cause by taking advantage of the appropriate troubleshooting tools.

    Summary

    This chapter covers examples of how to troubleshoot workloads in Lync Server with particular emphasis on the Enterprise Voice workload. These examples demonstrate an approach to troubleshooting these workloads that you can apply in your own troubleshooting scenarios. The processes, tools, and log files used to effectively troubleshoot Lync Server illustrates resources that every Lync IT Pro should have at their disposal.

    Lync Server Resources

    We Want to Hear from You

    Keywords: Enterprise Voice, UCCAPILOG, presence, service, synthetic, Front End Server, credentials, latency, Performance Monitor, Network Monitor, SQL Server, GAL

  • Moving the Lync Server 2010 Monitoring Databases to a New SQL Server Instance

    Posted over 3 years ago
    by DrRez_}

    The Microsoft Lync Server 2010, Monitoring Server adds the Lync Server QoE Monitoring Service and the Lync Server Call Detail Recording service to your deployment. These services and the associated databases, QoEMetrics and LcsCdr, provide critical data about performance and compliance—data you don’t want to lose. One way to help ensure reliable monitoring is to host the QoEMetrics and LcsCdr databases on a dedicated Microsoft SQL Server data management software instance instead of collocating the SQL Server that hosts them with a server that also hosts the monitoring services, the Lync Server Archiving service, or the Front End pool databases. Although these collocation scenarios are supported in Lync Server 2010, they are not recommended because they create a single point of failure and the risk of service and data loss. You can reduce this risk by moving the QoEMetrics and LcsCdr databases from a supported collocation scenario to a dedicated SQL Server instance.

    Author: Mike Adkins

    Publication date: June 2011

    Product version: Lync Server 2010

    Introduction

    Monitoring in your Microsoft Lync Server 2010 deployment is accomplished by using the Lync Server QoE Monitoring Service and the Lync Server Call Detail Recording service. The Lync Server QoE Monitoring Service monitors and records network connectivity and media information for the peer-to-peer and conferencing modalities that are supported in Lync Server 2010. The Lync Server Call Detail Recording service supports the compliance requirements that are necessitated by an organization’s regulatory policies. The data these services collect is stored in the QoEMetrics and LcsCdr databases and available for viewing in Monitoring Server Reports.

    Note. For details about Monitoring Server Reports, see Monitoring Server Reports at the TechNet Library.

    The reliability of the Lync Server QoE Monitoring Service and the Lync Server Call Detail Recording service depends on the server and network that hosts them. The supported Lync Server hardware load balancing and Domain Name System (DNS) load balancing features offer the reliability that is needed to host a highly available Windows Sever infrastructure for the Lync Server QoE Monitoring Service and the Lync Server Call Detail Recording service. These services rely on the use of two proprietary Microsoft SQL Server-hosted databases, QoEMetrics and LcsCdr. Microsoft SQL Server 2008 R2 failover clustering, Microsoft SQL Server 2008 failover clustering, and the Windows Server Clustering service provide a fault tolerant solution for hosting the QoEMetrics and LcsCdr databases. However, the Lync Server monitoring services (that is, the Lync Server QoE Monitoring Service and the Lync Server Call Detail Recording service) and databases (that is, the QoEMetrics and LcsCdr databases) are also supported in a non-fault tolerant fashion. The SQL Server that hosts the monitoring databases can be collocated with any of the following:

    • A server running Windows Server that hosts the Lync Server monitoring services
    • A server running Windows Server that hosts the Lync Server Archiving service
    • The SQL Server that hosts the Lync Server Front End pool databases

    The supported single-server installations create a single point of failure for an organization’s audio/video (A/V) monitoring infrastructure. These scenarios can result in data loss or the loss of the monitoring services due to hardware failure that causes a database outage. You can help avoid this threat by moving the QoEMetrics and LcsCdr databases to either a SQL Server that is hosted by a Microsoft clustering solution or to a dedicated SQL Server instance on a separate server running Windows Server.

    Note. For details about the supported installations for the Lync Server monitoring services, see Server Collocation in an Enterprise Edition Front End Pool Deployment at the TechNet Library. For details about Microsoft clustering, see the following topics at the TechNet Library:

    Prerequisites for Moving the QoEMetrics and LcsCdr Databases

    Prior to moving the QoEMetrics and LcsCdr databases, it is necessary to do the following:

    • Gather the information you’ll need.
    • Stop the Lync Server A/V Conferencing service and the monitoring services.
    • Make sure the monitoring databases are backed up.

    Gathering Required Information

    To move the databases, you’ll need to know the location of the server(s) that host the monitoring services and their databases. From the Lync Server Management Shell, on a server running Microsoft Lync Server 2010, Front End Server, run the following commands:

    • Get-CsService -MonitoringServer
    • Get-CsService -MonitoringDatabase

    The output provides the fully qualified domain name (FQDN) of the server running Windows Server that hosts the Lync Server QoE Monitoring Service and the Lync Server Call Detail Recording service and the FQDN of the SQL Server that hosts the QoEMetrics and LcsCdr databases. Note this information for the move.

    Stopping Services

    To help ensure full adherence to your organization’s A/V compliance policy, the Lync Server Audio/Video Conferencing service on each of the Front End pools should be stopped while you’re moving the QoEMetrics and LcsCdr databases. This stops all A/V communications on the network to help prevent data loss.

    To stop the Lync Server Audio/Video Conferencing service

    1. On the Windows Server-based server(s) running the Lync Server Audio/Video Conferencing service, click Start, and then click Run.
    2. Type services.msc, and then click OK.
    3. Locate Lync Server Audio/Video Conferencing service, right-click it, and then click Stop.

    In addition, you’ll need to stop the monitoring services to avoid data loss.

    To stop monitoring services

    1. On the Windows Server-based server running the Lync Server QoE Service and the Lync Server Call Detail Recording service, click Start, and then click Run.
    2. Type services.msc, and then click OK.
    3. Locate Lync Server QoE Monitoring Service, right-click it, and then click Stop.
    4. Locate Lync Server Call Detail Recording Service, right-click it, and then click Stop.

    Backing Up the QoEMetrics and LcsCdr Databases

    SQL Server provides point-in-time database backup and restore features. You should be able to use this proprietary feature to provide point-in-time database backups for the QoEMetrics and LcsCdr databases. Contact your SQL Server administrator to get answers to the following questions:

    • Is there a SQL Server task that manages differential backups of the QoEMetrics and LcsCdr databases?
    • Is there a SQL Server task that manages full backups of the QoEMetrics and LcsCdr databases?
    • Is there a SQL Server task that manages backups of the QoEMetrics and LcsCdr transaction logs?
    • What is the schedule for the SQL Server backup process for the QoEMetrics and LcsCdr databases?
    • Can a full backup of the QoEMetrics and LcsCdr databases be scheduled prior to moving both databases?

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

    Third-party vendors provide an array of software products that you can use 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 QoEMetrics database’s qoemetrics.mdf (data) and qoemetrics.ldf (transaction) files and the LcsCdr database’s lcscdr.mdf (data) and lcscdr.ldf (transaction) files. System backups are usually scheduled to run during off-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 a full system backup is taken of the lcscdr.mdf, lcscdr.ldf, qoemetrics.mdf, and qoemetrics.ldf files immediately before moving the QoEMetrics and LcsCdr databases to the new SQL Server instance.

    Note. Microsoft Server 2008 and Microsoft Server 2003 also provide file system backup and restore services.

    Note. For details about the SQL Server and Windows Server backup and restore processes, see the following:

    Moving the QoEMetrics and LcsCdr Databases

    To move the monitoring databases from their current location to a dedicated SQL Server instance, complete all the procedures in this section in order.

    Important. Before completing the following procedures make sure you have completed all the prerequisites described in the preceding section.

    To detach the databases from the server that currently hosts them

    1. On the SQL Server that hosts the QoEMetrics and LcsCdr databases, open the Microsoft SQL Server Management Studio console.

    2. In the tree view, expand Databases.

    3. Right-click the QoEMetrics database, and then click Properties.

    4. In the Select a Page pane, click Files.

    5. In the Details pane, locate the file path for the database file.

    Note. The monitoring database files could be located on the local hard disks of the SQL Server or at a shared location on the network. Contact the SQL Server administrator to confirm the location.

    6. On the Tasks menu, click Detach, and then click OK.

    7. Repeat Steps 3-6 for the LcsCdr database.

    To copy the database files to the new location

    1. On the SQL Server that hosts the QoEMetrics and LcsCdr databases, use Windows Explorer to locate the QoEMetrics and LcsCdr databases files. Their default names are lcscdr.mdf, qoemetrics.mdf, lcscdr.ldf, and qoemetrics.ldf. Their default installation location is either <LocalDrive:>\CsData\MonitoringStore\(default)\dbpath or <LocalDrive:>\CsData\ MonitoringStore\(default)\logpath.

    Important. If the QoEMetrics and LcsCdr database files are stored on a file server that the target SQL Server can access, and if it is acceptable, leave them there. The QoEMetrics and LcsCdr database files do not need to be copied to a new location unless you intend to do so.

    2. On the Windows Server-based server that hosts the QoEMetrics and LcsCdr databases files, in Windows Explorer, right-click the MonitoringStore folder, and then click Copy.

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

    4. On the target SQL Server, open the Microsoft SQL Server Management Studio console.

    5. In the tree view, expand Databases.

    6. Right-click Databases, and then click Attach.

    7. Click Add, and then click Browse.

    8. Navigate to MonitoringStore\(default)\dbpath\lcscdr.mdf, click lcscdr.mdf, and then click OK. The Attach Database dialog box should list the full path to the lcscdr.mdf and the lcscdr.ldf files.

    9. Click OK.

    10. Complete Steps 8-9 for the lcscdr.ldf, qoemetrics.mdf, and qoemetrics.ldf data and log files.

    To associate the FQDN of the new server to the existing archiving file store

    1. On a computer running a supported version of Windows or Windows Server, click Start, click All Programs, click Microsoft Lync Server 2010, and then click Lync Server Topology Builder.

    2. Click Download the Current Topology.

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

    4. In the tree view, expand Monitoring Servers.

    5. Click the FQDN of the Microsoft Lync Server 2010, Monitoring Server that needs to have its SQL Server monitoring database association updated to the location of the SQL Server that now hosts the QoEMetrics and LcsCdr databases.

    6. On the Actions menu, click Edit Properties.

    7. In the Edit Properties dialog box, do one of the following:

    • If the SQL Server that now hosts the QoEMetrics and LcsCdr databases is displayed in SQL store, click New, add the FQDN details, and then click OK.
    • If the SQL Server that now hosts the QoEMetrics and LcsCdr databases is not displayed in SQL store, click New, add details about the new SQL Server instance, and then click OK.

    Figure 1. Editing the Monitoring Server properties by using Topology Builder

    To publish and verify the new deployment

    1. In Topology Builder, click Lync Server 2010.

    2. On the Actions menu, click Publish Topology. The Publish Topology wizard opens.

    3. Make sure the FQDN of the SQL Server that now hosts the QoEMetrics and LcsCdr databases is listed and selected, and then click Next.

    4. After the wizard completes, click Finish.

    5. Expand Archiving Servers.

    6. Click the FQDN of the Lync Server 2010, Monitoring Server. The Details pane should now show the FQDN of the SQL Server that now hosts the QoEMetrics and LcsCdr databases.

    Starting services

    After moving the LcsCdr and QoEMetrics databases, it is time to re-start the Lync Server QoE Monitoring Service, the Lync Server Call Detail Recording service, and the Lync Server Audio/Video Conferencing service in the order that is described in the following procedures.

    To restart the monitoring services

    1. On the Windows Server-based server running the Lync Server QoE Monitoring Service and the Call Detail Recording service, click Start, and then click Run.

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

    3. Locate Lync Server QoE Monitoring Service, right-click it, and then click Start.

    4. Locate Lync Server Call Detail Recording Service, right-click it, and then click Start.

    5. Click Start, and then click Run again.

    6. Type eventvwr.msc, and then click OK.

    7. In the Windows Event Viewer, expand Applications and Service Log, and then expand Lync Server.

    8. Locate the following event to make sure the Lync Server QoE Monitoring Service and the Lync Server Call Detail Recording services have successfully connected with the SQL Server that is now hosting the QoEMetrics and LcsCdr databases.

    Log Name: Lync Server

    Source: LS Call Detail Recording

    Date: 1/18/2011 6:59:46 PM

    Event ID: 26001

    Task Category: (1060)

    Level: Information

    Keywords: Classic

    User: N/A

    Computer: server01.contoso.com

    Description:

    Lync Server Call Detail Recording (CDR) Service started.

    Message Queue: .\LcsCDRQ

    Database: LcsCDR

    Back-end: server02. contoso.com

    Log Name: Lync Server

    Source: LS QoE Monitoring Service

    Date: 1/18/2011 6:59:58 PM

    Event ID: 19111

    Task Category: (1910)

    Level: Information

    Keywords: Classic

    User: N/A

    Computer: server01.contoso.com

    Description:

    A connection was established with the QoE Monitoring Server database.

    Server: 'server02.contoso.com' Database: 'QoEMetrics'

    To start the Lync Server Audio/Video Conferencing service

    1. On the Windows Server-based server(s) that are running the Lync Server Audio/Video Conferencing service, click Start, and then click Run.

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

    3. Locate Lync Server Audio/Video Conferencing Service, right-click it, and then click Start.

    Additional Considerations

    Database Permissions

    After the QoEMetrics and LcsCdr databases are attached to the target SQL Server instance, they should retain the default SQL Server login permissions that were assigned when they were created. The original SQL Server login permissions for the QoEMetrics and LcsCdr databases is the <domain>\RTCComponentUniversalServices security group. Figure 2 shows the properties of the SQL Server login for this security group.

    Figure 2. RTCComponentUniversalServices SQL Server Login Properties dialog box

    Firewall Considerations

    The new target SQL Server instance will have to be accessed by using the service ports that it’s configured to use for SQL Server client requests. For details about how to configure the firewall on a server running Windows Server to allow access to the SQL Server instance’s listening ports, see the following:

    Summary

    Moving the Lync Server QoEMetrics and LcsCdr databases to a new SQL Server instance could be the first step in an organization’s move to a fault tolerant Lync Server monitoring service solution. Implementing a fault tolerant database solution for the Lync Server monitoring services requires careful planning and execution to help ensure that monitoring services downtime is kept to a minimum and that data loss hopefully does not occur.

    Lync Server Resources

    We Want to Hear from You

    Keywords: QoEMetrics, LcsCdr, Lync Server monitoring, Lync monitoring, Monitoring Server, monitoring database, QoE monitoring, Call Detail Recording service