There are many reasons you should monitor the performance of Office Communications Server. For example, on a fundamental level, you need to know whether Office Communications Server is still running and whether the various server components are still functioning. In addition, it is also useful to know if Office Communications Server is running optimally. In other words, are you—and your users—getting the best possible service? Do you have enough front-end servers to handle the typical morning rush when users first sign on? Do you have sufficient network bandwidth to allow for high-quality video and audio conferencing? Just how many users are using IM? To answer these questions, you don’t necessarily need performance data; instead, you need detailed statistical information on how Unified Communications (UC) is used in your organization. How do you get that kind of detailed statistical information? By using the Archiving Server or the Monitoring Server.
The Archiving Server was introduced in Office Communications Server 2007 as a way to: (1) archive the actual contents of instant message conversations and group conferences; and (2) capture usage information (in the form of Call Detail Records, or CDRs) related to Office Communications Server activities such as file transfers, A/V conversations, application sharing, remote assistance, and so on. Prior to the R2 release, if you were interested in capturing usage information, you needed to install the Archiving Server.
Note
Is it really necessary to archive the contents of all your users’ IM sessions? As it turns out, it might be very important. A number of industries (including banking and financial services) are required, by law, to keep records of all their electronic communications, including IM.
With the R2 release of Office Communications Server, most of the CDR capabilities originally found in the Archiving Server have been moved to the Monitoring Server. The Archiving Server is now used exclusively for monitoring (and archiving) instant message conversations. If that’s the only type of communication you’re interested in tracking, then the Archiving Server is probably all you need. However, if you need to track usage information for other media—such as conferences, file transfers, or Enterprise Voice calls—you will also need to install the Monitoring Server.
Note
The Archiving Server enables you to store the actual contents of instant messages. However, the Monitoring Server does not record and store actual phone calls or conferences. Instead, it simply records information about those calls (for example, who placed the call, what device they used when placing the call, the date and time of the call, and so on).
As noted earlier, many of the CDR capabilities originally included in the Archiving Server have been moved to the Monitoring Server. This has resulted in changes being made to the Archiving Server database. That’s important if you are upgrading from Office Communications Server 2007 to Office Communications Server 2007 R2. For example, the following tables have been removed from the database:
MediaList
Roles
Gateways
Multipoint Control Units (MCUs)
Phones
FocusJoinsAndLeaves
McuJoinsAndLeaves
ConferenceMessageCount
FileTransfers
Media
VoIPDetails
These tables can now be found in the Monitoring Server CDR database (LcsCDR). If you have scripts that access these tables, you will need to modify those scripts so that they connect to the LcsCDR database. If you are upgrading from the original release of Office Communications Server to the R2 release, be aware that your previous Archiving Server data will not be migrated when you make the switch. Instead, the old database will be overwritten by the new one.
If you decide to deploy the Archiving Server, keep in mind that simply installing the component does not mean that all your instant message information will be archived. Archiving does not take place by default; instead, you must explicitly configure archiving within the organization. To configure archiving, do the following.
Open the Administrative Tool, right-click the forest node, point to Properties, and then click Global Properties. You do this on the forest node because archiving properties are configured at the forest level and then enabled at the pool level.
In the Office Communications Server Global Properties dialog box, on the Archiving Tab, select the desired setting for both internal and federated communications. Three mutually exclusive options are available: Archive For All Users, Do Not Archive For Any Users, and Archive According To User Settings.
If you selected Archive According To User Settings, you will then need to access the user accounts for each pool (found in the Users node) and specify whether archiving should be enabled for each individual user. If you chose Archive For All Users or Do Not Archive For Any Users, you do not have to modify the archive settings for an individual account. (In fact, this option will be unavailable to you.) In these two cases, the forest-level settings take precedence.
Finally, access each pool, right-click the pool name, point to Properties, and then click Front End Properties. In the Properties dialog box, on the Archiving tab, select Activate IM Content Archiving. After that’s done, click the Associate button and then select the Archiving Server that should be used for this particular pool.
If you ask people to rate the voice quality of a phone call or A/V conference, you will likely get back answers similar to the following:
The speakers sounded funny, like they were under water or something.
I kept hearing an echo over and over.
Everyone was talking too quietly.
Is that useful information? Well, it might be. On the other hand, answers like these are highly subjective and are difficult to correlate and compare. Because of this, voice quality researchers typically don’t ask open-ended questions such as, "How did the voice quality sound to you?" Instead, they employ an absolute categorization rating (ACR) scale. With an ACR scale, users are asked a set of questions about the listening experience and are asked to rate the quality of their experience on a scale of 1–5 (with 1 representing a bad experience and 5 representing an excellent experience). The researchers then average these values to calculate a mean opinion score (MOS). Although MOS scores are not a perfect representation of the listening experience, they do make it possible to compare and contrast listening experiences. If group A reports an MOS of 4.1 and group B reports an MOS of 2.2, it’s safe to say that—on average—listeners in group A had a much better experience than listeners in group B.
This same philosophy underlines the quality of experience metrics used by the Monitoring Server, an Office Communications Server 2007 component first introduced as an optional download and now fully integrated into the product. The only difference is that the Monitoring Server does not ask users to rate their listening experiences on a scale of 1–5; instead, the Monitoring Server uses a series of algorithms to predict how users would rate the quality of each listening experience. Based on those algorithms, the Monitoring Server reports the following MOS scores:
Listening MOS. A prediction of the wideband quality of an audio stream being played to a user. The MOS score takes into account audio fidelity and distortion as well as speech and noise levels.
Sending MOS. A prediction of the wideband quality of an audio stream sent from a user. The MOS score takes into account audio fidelity and distortion as well as speech and noise levels.
Network MOS. Another prediction of the wideband quality of an audio stream played to a user. In this case, however, only network factors are considered such as the audio codec used, packet loss, packet errors, and jitter (the variation in the delay time of packets arriving at a destination).
Conversational MOS. A prediction of the narrowband conversational quality of the audio stream played to the user. This value is indicative of how a large group of people would rate the quality of the connection for holding a conversation.
Note
When dealing with the Monitoring Server, narrowband refers to audio codecs that use an 8-kHz (kilohertz) sample rate. Wideband refers to audio codecs that use a 16-kHz sample rate. Telephone-quality communication is normally categorized as narrowband.
Like archiving, the Monitoring Server’s CDRs must be configured at the forest level and then enabled at the pool level. To configure CDRs, right-click the forest node in the Administrative Tool, point to Properties, and then point to Global Properties. In the Office Communications Server Global Properties dialog box, on the Call Detail Records tab, select the call types you would like to track (you may select as many, or as few, of these call types as you like).
Peer-to-Peer call details. Includes IM, A/V, file transfers, and application sharing
Conferencing call details. Includes all multiparty sessions, including Group Chat, A/V, file transfers, and any conferencing sessions conducted using the Microsoft Office Live Meeting client
Voice call details. Includes all Enterprise Voice calls
Monitoring itself must then be enabled at the pool level. To enable monitoring for a given pool, right-click the pool node, point to Properties, and then click Front End Properties. In the Front End Properties dialog box, on the Monitoring tab, select one (or both) of the following:
Enable Call Detail Recording (CDR). Enables you to record the CDR information specified at the forest level
Enable QoE Monitoring. Enables you to track Quality of Experience data
Unlike archiving, you do not have to configure user accounts to work with the Monitoring Server; usage information for all the users in the pool will automatically be monitored and recorded. However, you do have to associate a specific Monitoring Server with each pool. That task can also be performed from the Monitoring tab (click Associate and then select a server).
By default, the Monitoring Server stores QoE data in a SQL Server database named QoEMetrics. If you prefer, you can write your own scripts or applications to access the data in this database. Alternatively, you can install Monitoring Server Reports and take advantage of predefined reports that both retrieve and aggregate data from the QoEMetrics database. This is definitely the fastest and easiest way to retrieve information collected by the Monitoring Server.
The Monitoring Server Reports pack contains 12 predefined reports, including 3 CDR Activity Summary Reports and 9 different Media Quality Reports. Each report includes a filtering mechanism that enables you to customize the information that is displayed. For example, the UC-to-UC Summary Trend report enables you to filter on the following:
From/To Allows you to specify a start date and an end date for the report
Granularity Hourly, daily, weekly, monthly
Location You can select all subnets or single out one or two specific subnnets
Media Connectivity Direct, Relay, HTTP Proxy
Client Type Communicator, Internet Protocol (IP) Phone, Samara
Capture Device
Before you can install and use the Monitoring Server Reports, you must first install SQL Server Reporting Services. Reporting Services is not installed by default when you install SQL Server; consequently, it’s possible that you are running SQL Server but not running SQL Server Reporting Services. If that’s the case, simply restart SQL Server setup. When the Setup Wizard reaches the Components To Install page, select Reporting Services and then complete setup.
Likewise, you might have already installed Monitoring Server without installing Monitoring Server Reports. In that case, restart the setup program for Office Communications Server. On the Deployment Wizard Welcome page, click Deploy Other Server Roles and then, on the Deploy Other Server Roles page, click Deploy Monitoring Server. Finally, on the Deploy Monitoring Server page, click Step 4, Deploy Monitoring Server Reports.
After installation is complete, you can access these reports by pointing your Web browser toward the URL specified during setup. If you installed the reports on a computer named reportserver1 in the domain fabrikam.com, the URL will be the following: https://reports.fabrikam.com/reportserver?%2fOCSReports.
Monitoring Server Reports are incredibly useful any time you want detailed information about UC usage in your organization. However, there might be times when the information included within these reports is too much. Sometimes, you might want nothing more than a quick overview of UC usage. Likewise, only a handful of predefined reports are included with Monitoring Server Reports; it’s possible that the information you want (or, at the least, the format of that information) cannot be found on one of the prebuilt reports.
In addition, Monitoring Server Reports work only with the Monitoring Server database. They cannot be used to retrieve and report data stored in the Archiving Server database. If you want to extract data from the Archiving Server database, or if you want to extract custom data from the Monitoring Server database, then you have two primary approaches at your disposal: you can access this data by using the ArchivingCdrReporter tool, or you can directly access the database in question.
If you are interested in a quick overview of how Office Communications Server is being used in your organization, then the ArchivingCdrReporter Tool is the tool for you. ArchivingCdrReporter is a Resource Kit application that enables you to quickly and easily retrieve basic statistics from the Archiving and Monitoring databases. ArchivingCdrReporter is not a full-fledged, enterprise-ready reporting tool, but it can be extremely useful, especially for administrators with a limited knowledge of SQL Server and/or database programming. (The only real alternatives to ArchivingCdrReporter are to use scripts or a third-party application to directly access one of the databases.)
So how easy is it to use ArchivingCdrReporter? You install the tool by copying two files—ArchivingCdrReporter.exe and ArchivingCdrReporter_Config.xml—from the Resource Kit CD to a folder on your hard drive. From there, you start the program by double-clicking ArchivingCdrReporter.exe.
After ArchivingCdrReporter has started, you need to specify the database that you want to work with. To do this, click the Backend Details menu, which will bring up the Edit Database Details dialog box.
In the dialog box, click the appropriate tab (CDR to access Monitoring Server’s CDRs or Archiving to work with the Archiving Server’s IM records) and then specify both the server name (as well as the instance of SQL Server, if needed) and the database name. Click OK, and you will be connected to the database.
Note
Monitoring Server’s QoE metrics are not accessible using ArchivingCdrReporter. (Rather, they are not readily accessible.) To work with QoE data, use the Monitoring Server Reports discussed earlier in this chapter.
Incidentally, ArchivingCdrReporter can also retrieve information about Response Group Services. You can easily configure the utility to retrieve information from other SQL Server databases. To do so, you must modify the file ArchivingCdrReporter_Config.xml. For example, suppose you have a database named UserDatabase located on a server named ocs2007. To add this database to ArchivingCdrReporter_Config.xml, you would create a node similar to the following:
<Database> <Alias>New Database</Alias> <Server>ocs2007 </Value> <Name>UserDatabase</Name> </Database>
Modifying ArchivingCdrReporter_Config.xml is discussed in more detail in the next section of this chapter.
Upon selecting a database, the reports available in ArchivingCdrReporter will be adjusted accordingly. Some reports are valid only in the CDR database, some are valid only in the Archiving database, and a few are valid in either database. After selecting a database, you can then retrieve information by clicking on the desired report. For example, suppose you would you like to know the total number of IM sessions that have been conducted in your organization. In that case, select the Archiving database and then click the Total Number of IM Sessions report. The total number of IM sessions will then be displayed in ArchivingCdrReporter.
In the original version of ArchivingCdrReporter, that is basically all you can do with the returned recordset. You can look at the data in the ArchivingCdrReporter window. With the R2 version of the tool, however, you now have some additional capabilities at your disposal. For example, you can select items within the recordset, right-click the records, and then click Copy to copy the information to the Clipboard. (Or, if you want to select all the records, right-click anywhere on the recordset and then click Select All.) Alternatively, you can right-click the recordset and then click Export To Excel to save the data to an Excel spreadsheet.
Ideally, ArchivingCdrReporter would come pre-equipped with every report—and every database query—you would ever need; in that case, retrieving usage information would be as simple as starting up ArchivingCdrReporter and clicking the desired report.
In reality, of course, it would be impossible to anticipate every report every administrator might need (not to mention the logistical nightmare of trying to accommodate all those reports within the ArchivingCdrReporter user interface). This means that it’s quite possible that the database query you really need won’t be found anywhere in ArchivingCdrReporter. This is not a problem because if you believe a particular query is missing from ArchivingCdrReporter, all you have to do is modify an XML file and add that query to the tool.
Each report shown in ArchivingCdrReporter is stored as a node in the file ArchivingCdrReporter_Config.xml. For example, the node for the report Total Number of IM Sessions looks like this:
<Query> <Name>Total Number of IM Sessions</Name> <Value>Select Count(*) as 'Number of IM Sessions' From Messages</Value> <Database>Archiving</Database> </Query>
As you can see, the report is enclosed in a <Query> node, a node consisting of three child items:
<Name>. The name of the report as it appears in ArchivingCdrReporter
<Value>. The SQL query used to retrieve data from the database
<Database>. The database (CDR or Archiving) that the query should be run against
Any new report you add to ArchivingCdrReporter requires that you supply this same type of information.
Note
You can also include an option <Description> node where you can type a description of the query; for example <Description>This query returns the number of instant messages sent in the past week.</Description>. This comment will appear as a tool tip any time an ArchivingCdrReporter user hovers his or her mouse over the query title.
For example, suppose you need a count of all the instant messages sent from a particular user. One way to get this information is to specify the user’s ID number (for example, 2) as part of the SQL query. (This can also be done by linking tables and using the user’s Uniform Resource Identifier (URI), but using the ID number enables us to keep this example as simple as possible.) In that case, the node for your new report might look something like this:
<Query> <Name>Total Number of IM Sessions Sent By User 2</Name> <Value>Select Count(*) as 'Number of IM Sessions' From Messages Where FromID = 2 </Value> <Database>Archiving</Database> </Query>
All we have done here is to create a new <Query> node. Inside that node, we set the <Name> to Total Number of IM Sessions Sent By User 2; we set the <Value> (that is, our SQL query) to the following:
Select Count(*) as 'Number of IM Sessions' From Messages Where FromID = 2
This query will retrieve all the records from the Messages table where the FromID field is equal to 2. This might not be that useful a report to have hard-coded into ArchivingCdr-Reporter. Again, however, the goal here is to show you how to modify the XML file, not to suggest which queries you should or should not add to that file.
Finally, we assign Archiving as the target <Database>. What if this query would be valid in either the Archiving database or the CDR database? In that case, our node would include two <Database> elements, one for each database:
<Database>Archiving</Database> <Database>CDR</Database>
All that is left now is to decide where you want to place the new report. If you look closely at the ArchivingCdrReporter window, you see that reports have been categorized for you. For example, Total Number of IM Sessions is included in the section labeled Peer to Peer Usage Reports. Each of these sections is contained in a <Queries> node, a node that includes a <Name> element followed by all the individual report nodes. For example:
<Queries>
<Name>Peer to Peer Usage Reports>
<Query>
<Name>Total Number of IM Sessions</Name>
<Value>Select Count(*) as 'Number of IM Sessions' From Messages</Value>
<Database>Archiving</Database>
</Query>
<Queries>You can either add your new report to an existing section, or you can create a brand new section for your report. For example, to create a new section titled Custom Reports and place your new report within that section, add the following <Queries> nodes:
<Queries>
<Name>Custom Reports>
<Query>
<Name>Total Number of IM Sessions Sent By User 2</Name>
<Value>Select Count(*) as 'Number of IM Sessions' From Messages Where FromID = 2
</Value>
<Database>Archiving</Database>
</Query>
<Queries>Save the file ArchivingCdrReporter_Config.xml and then exit ArchivingCdrReporter. When you restart the application, your new section—and your new report—will be available for use.
As noted earlier, scripts offer an alternate method for accessing the events in event logs. In much the same way, scripts can also be used to access the data stored in the various Office Communications Server databases. For more information and for sample scripts, see the Office Communications Server Tech Center at http://go.microsoft.com/fwlink/?LinkID=133618.
Of course, before you can use a script to access a database, you need to know several things about that database, including the names of all the tables in the database, the fields that comprise each of those tables, and the data type of each of those fields. One way to get this information is to use Microsoft SQL Server Management Studio, a tool that is automatically installed when you install SQL Server.
For example, to access the Archiving Server database, start the SQL Server Management Studio. When the Connect To Server dialog box appears, type the name of the SQL Server instance in the Server Name box. For example, if the Archiving database were installed in a SQL Server instance named archinst on a server named server1, type the following and then click Connect:
server1archinstIf you can’t remember the name of the SQL Server instance where the Archiving Server database or the Monitoring Server databases were installed, locate the server in the Administrative Tool, and then look at the Status pane. There you’ll find the name of the SQL Server instance and the name of the actual database itself.
After the connection is made, expand the Databases node and then expand the node for the Archiving database (LcsLog). After expanding the database node, expand the Tables node. When you do so, you will see all the tables in the LcsLog database:
At this point, you know the names of all the tables in the database. To determine the fields for a given table, expand the table node and then expand the Columns node. This will show you the fields for that particular table. For example, if you expand the ClientVersions table, you will see the following two items:
VersionID (PK, int, not null)
Version (nvarchar[256], not null)
These two items indicate that the ClientVersions table has a field named VersionID; this field happens to be a primary key (PK), contains integer data (int), and does not allow for null values (that is, each record in the table must have a VersionID). It also means that this table includes a field named Version, which uses the nvarchar data type, can accept a maximum of 256 characters and does not allow for null values. If you are familiar with databases and database programming, this will be enough information to get you started.
If you aren’t familiar with databases and database programming, knowing the structure of the database and its tables is likely to be of little use to you. However, you can still use SQL Server Management Studio to look at the records stored in one of these tables. To do that, right-click the table name and then click Open Table. The table records will appear in the accompanying window pane.