[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready]

Topic Last Modified: 2010-04-27

This section describes what is required to enable Call Detail Record (CDR) and Quality of Experience (QoE) data collection and reporting in a Microsoft Communications Server 2010 deployment, including components, supported topologies, recommended deployment sequence, prerequisites for deployment, and the deployment process.

Feature Components

To enable CDR and QoE data collection and reporting, deploy Monitoring Server, which is a server role in Communications Server 2010. To do so, define the deployment using Topology Builder, and then run the Communications Server deployment tool using the configuration information defined by Topology Builder.

Monitoring Server also requires Monitoring Server databases that use Microsoft SQL Server. The databases can be collocated on the same computer as Monitoring Server, or on a different computer. For more information about deploying Monitoring Server, including requirements, see Deploying Monitoring.

Supported Topologies

The Monitoring Server feature includes the following components:

  • The Monitoring Server, which is the server role that captures usage data and media quality data. This includes two parts: The CDR service for capturing CDRs (usage data), and the QoE service for capturing media quality data

  • The Monitoring Server databases, which run on SQL Server and store the captured data. There are separate databases for CDR and QoE information, but both always run on the same server in the same instance.

  • The Data Collection Agents, which are installed automatically on every Front End Server. The CDR agent intercepts SIP messages and uses them to send data to the destination queue on the Monitoring Server. The QoE agent receives QoE data reports from endpoints through SIP SERVICE requests, and sends the data to the destination queue on the Monitoring Server and/or to third-party consumers using HTTP POST.

  • Microsoft Message Queuing, which must run on each Monitoring Server and on each Front End Server that reports data to Monitoring Server.

  • The Systems Center Operation Management (SCOM) pack is an optional component. This component can perform server monitoring for your entire deployment, and it can use Monitoring Server data to generate near real-time alerts showing the health of the A/V Conferencing Server component on your Front End Servers, as well as the health of Mediation Servers and network locations.

  • The Monitoring Server Reports are out-of-the-box reports providing usage and media quality information, based on CDR and QoE data stored in the CDR and QoE databases. The reports are generated with the SQL Server Reporting Services.

For details, including a list of hardware and software requirements for Monitoring Server and the server running the Monitoring Server database, see Components Required for Enterprise Voice.

Each Monitoring Server can capture data from one or more Standard or Enterprise Edition pools, Standard Edition servers, and Mediation Servers. When you deploy a Monitoring Server, you associate it with the pools or servers that it is to monitor. The following figure illustrates two possible Monitoring Server topologies.

Monitoring Server topologies

You can associate multiple Monitoring Servers with a single Monitoring database that runs on a different computer. In this topology, it is important to configure the purge time for the Monitoring Servers to avoid potential database lockouts that can occur when purges run simultaneously.

Supported Collocation

Communications Server 2010 supports a variety of collocation scenarios, allowing you flexibility to save hardware costs by running multiple components on one physical server, if you have a small organization, or to separate components onto different servers, if you have a larger organization that needs scalability and performance. Scalability factors should certainly be considered before you decide to collocate Monitoring Server or its databases with other server roles or databases.

Monitoring Server can be collocated with a Standard Edition server. If your deployment is a single Standard Edition Server, collocating Monitoring Server with it can save you from needing a separate computer for Monitoring Server.

Monitoring Server can also be collocated with other Communications Server roles, such as Archiving Server. If Monitoring Server and Archiving Server are collocated, their databases can be hosted on that same server as well, or located together on another server, or separated onto different database servers.

If you collocate Monitoring Server with a Standard Edition server, you must install a full edition of SQL Server on the server, instead of using the SQL Server Express Edition normally used with a Standard Edition server.

The Monitoring Server and the Monitoring Server databases can be collocated on the same server or installed on separate servers, as illustrated in the following figure.

Monitoring Server database collocation

The server hosting the Monitoring Server databases can also host other databases. The following scenarios are supported:

  • Monitoring Server databases collocated with one or more other Communications Server databases, (including the back-end database, Archiving database, and Response Group application database, for example).

  • Monitoring Server databases collocated with databases of third-party products.


When you deploy Monitoring Server, you associate it with one or more Front End pools, and/or Mediation Servers. Monitoring Server then collects data from the pools you have associated it with. It is recommended, but not required, to have all Front End pools in the same Enterprise pool associated with a single Monitoring Server.

For best scalability, do not collocate the Monitoring Server with another server role or collocate the Monitoring Server databases with any other databases. Hosting the Monitoring Server databases on a separate computer from the Monitoring Server itself does not significantly improve performance.

A single Monitoring Server can serve up to 300,000 users. If you have multiple pools that total less than 300,000 users, we recommend that you associate all these pools with a single Monitoring Server, to simplify administration. Alternatively, if you have pools at different physical locations, it may make more sense to deploy a Monitoring Server at each location.

Monitoring Database Performance

For optimal performance, we recommend putting these files on four physical disks:

  • System file and Message Queuing (MSMQ) file on the same physical disk

  • QoE database data file and CDR database data file on the same physical disk

  • QoE database log file

  • CDR database log file

If you collocate the Monitoring Server databases with other databases on the same server, you should run the Monitoring Server databases in a separate instance from other databases. Additionally, you should put the Monitoring Server database data files and log files on separate physical disks, for optimal performance. You should carefully evaluate performance impacts before deciding to collocate the Monitoring Server databases with other databases.

Monitoring Database Size

Based on the Communications Server user model, the CDR database grows 8.8 KB per user per day, and the QoE database grows 16.8 KB per user per day. To get an estimate of your database size, use this formula:

Database size = (DB growth per user per day) * (Number of users) * (Number of days)

For example, 60 days of data in the CDR database for 50,000 users would be 8.8*50000*60 for a total of 25 GB. If your organization’s Communications Server differs significantly from the user model, adjust the daily database growth estimate.

You can use this formula, along with the knowledge of your available database disk space, to help decide how many days of data to keep on your database (the default is 60 days).

Report Performance

Reporting is another factor affected by performance. The provided standard set of reports are designed to work in most scenarios, but if you need reports on very large data, such as a QoE report on 10 million calls, an offline reporting solution may be more appropriate. The reports use the tempdb database in SQL Server as an internal cache, so we recommend that you put tempbd on a separate physical disk, with at least 10 GB available space. One additional thing to consider is that if your Monitoring database size is larger than the database server’s physical memory, Monitoring Server report performance can be affected.

Monitoring Server Prerequisites

Before deploying Monitoring Server, you must install the following software:

  • Message Queuing on the server running Monitoring Server

  • Microsoft SQL Server and SQL Server Reporting Services

Load Balancer Port Requirement

To collect CDR or QoE data, you must open port 5069 on the Front End servers. The port is used for message queuing RCP operations.

Deployment Sequence

Deploy Monitoring Server after you have deployed at least one Enterprise Edition or Standard pool. Be sure to associate a pool with a deployed Monitoring Server when you enable QoE and CDR data collection on that pool, so that the data will be collected and stored.Deploying Monitoring Server relatively early in your deployment process can be useful so that you can collect CDR and QoE data and see the usage and media quality of your network during your planning and predeployment phases.

Deploying Monitoring Server relatively early in your deployment process can be useful so that you can collect QoE data and see the media quality of your network during your planning and predeployment phases.

Monitoring Server Deployment Process

Before you deploy Monitoring Server, you need to verify that your system infrastructure and the server on which you will install Monitoring Server meet the hardware and software requirements previously described in this section. When the environment is ready, you install the Monitoring Server files and associate the Monitoring Server with the pools that it will monitor. For details see Deploying Monitoring.

See Also

Other Resources

Deploying Monitoring