Microsoft
Understanding the
Monitoring Server Reports
Published May 2011
Copyright
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.
©2011 Microsoft Corporation. All rights reserved.
Microsoft, Excel, Lync, Windows, Windows PowerShell, and Word are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
Copyright 2
Introduction 5
Reports About Individual Communication Sessions and Conferences 6
Reports About Overall Usage and Trends 6
Reports About the Response Group Application 7
Reports About Failure Analysis and Diagnostics 7
Call Detail Report 8
Call List Report 10
Conference Detail Report 12
Media Quality Summary Report 13
Peer-to-Peer Session Detail Report 17
User Activity Report 18
Call Admission Control Report 22
Conference Activity Report 23
Conference Summary Report 24
Device Report 26
IP Phone Inventory Report 29
Location Report 31
Peer-to-Peer Activity Summary Report 33
Peer-to-Peer IM Report 34
Peer-to-Peer Voice and Video Report 36
PSTN Conference Summary Report 38
User Registration Report 39
Response Group Call List Report 41
Response Group Usage Report 43
Call Diagnostic Summary Report 46
Conference Diagnostic Report 48
Diagnostic Report 50
Failure Distribution Report 51
Failure List Report 53
Media Quality Metrics Distribution Report 56
Peer-to-Peer Activity Diagnostic Report 60
Server Media Quality Trend Report 62
Server Performance Report 63
Top Failures Report 65
Introduction
Monitoring Server Reports is an optional feature that ships with Microsoft® Lync™ Server 2010 communications software. If you have installed Lync Server 2010 Monitoring Server, your system will automatically collect a wealth of information about all the communication sessions (including Enterprise Voice phone calls, instant messaging sessions, and conferences) that take place in your organization. The data collected by Monitoring Server falls into one of two categories:
• Call detail records (CDR), which includes information such as who made a call (or initiated a conference), who that person called, and the duration of the call
• Quality of Experience (QoE) data, which reports standard telecommunications metrics (such as jitter, packet loss, and round-trip times) that can be used to help administrators assess the quality of a call and to troubleshoot any problems that might have lessened the quality of a call.
The collected data is stored in one of two Microsoft® SQL Server® databases (one for CDR and the other for QoE metrics). These two databases are fully documented (see Reference in the Lync Server TechNet Library at ), which means that all the records are readily accessible to administrators who are well-versed in writing SQL Server queries.
But what if you aren't well-versed in writing SQL Server queries, or what if you don't have the time to learn the database schemas and create these queries? That's where Monitoring Server Reports come in. Monitoring Server Reports is a predefined set of reports (written for use with the SQL Server Reporting Services) that all administrators can use to retrieve information about Lync Server communication sessions, without having to write their own SQL Server queries. This information includes a wide range of topics: there are reports that detail the number of conferences held in an organization and the number of people who participated in those conferences; there are reports that detail the total number of users who have logged on to Lync Server that also indicate how many logged-on users have actually employed the system; and there are reports that help you diagnose and troubleshoot failures that might have marred a phone call, an instant messaging (IM) session, a conference, or any other communication session that uses Lync Server.
This document provides a detailed look at each of the reports included in Lync Server Monitoring Server Reports. It includes a brief description of each report and what it actually reports on, instructions about how to access the report, and information about how to make the best possible use of the report. What this document does not do is offer generic information about performing common Monitoring Server Reports activities such as filtering, sorting, and exporting data. For that information, see the document Using Monitoring Server Reports, also in this download package.
If you'd like to see some real-life examples of Monitoring Server Reports in action, then you might be interested in the following videos:
• Help Desk Troubleshooting: Lync Call Issues at
• System-wide Troubleshooting: Lync Call Connectivity at
The Help Desk Troubleshooting video demonstrates how a support person might assist a user who has been having call quality problems, while the System-wide Troubleshooting video shows how administrators can use Monitoring Server Reports to determine whether users are able to make and complete calls and, if they’re not able to, why.
As noted, this document provides a detailed look at each of the reports included in Lync Server Monitoring Server Reports. Those reports include the following:
Reports About Individual Communication Sessions and Conferences
• Call Detail Report
Provides detailed information about an individual call made from or received within your organization.
• Call List Report
Provides detailed information about calls made from or received within your organization.
• Conference Detail Report
Provides detailed information about conferences held within your organization
• Media Quality Summary Report
Provides overall quality data for different endpoint types, including Enterprise Voice peer-to-peer calls, Enterprise Voice conference calls, and calls that rely, at least in part, on the public switched telephone network (PSTN).
• Peer-to-Peer Session Detail Report
Provides detailed information about peer-to-peer communication sessions, including information about the modalities (for example, IM and video) used in the session and diagnostic information about failed sessions.
• User Activity Report
Provides a list of peer-to-peer and conference activities for each of your users.
Reports About Overall Usage and Trends
• Call Admission Control Report
Provides information about sessions conducted under restrictions placed by call admission control (CAC).
• Conference Activity Report
Provides a detailed look at conferencing sessions, broken down by pool and by server type.
• Conference Summary Report
Provides a summary of all conference activities.
• Device Report
Provides a summary of devices that are used for Enterprise Voice calls and includes the average media quality of the calls by device.
• IP Phone Inventory Report
Provides information about the IP phones currently in use in the organization. The report is based on phone registrations and logons.
• Location Report
Provides a list of network locations and a summary of the media quality of the calls that occur at each location.
• Peer-to-Peer Activity Summary Report
Provides a summary of peer-to-peer IM, audio, video, file transfer, and application sharing sessions.
• Peer-to-Peer IM Report
Provides a detailed look at peer-to-peer IM sessions broken down by pool and by authentication type.
• Peer-to-Peer Voice and Video Report
Provides a detailed look at peer-to-peer voice and video communications broken down by pool, call type, access type, and Mediation Server.
• PSTN Conference Summary Report
Provides a summary of all PSTN conferences; these are conferences in which at least one user dials in using the PSTN.
• User Registration Report
Provides a summary of user connectivity to the Lync Server deployment based on registration events such as user logons.
Reports About the Response Group Application
• Response Group Call List Report
Provides a detailed look at individual calls received by the Response Group application.
• Response Group Usage Report
Provides a summary of calls made to Response Group workflows.
Reports About Failure Analysis and Diagnostics
• Call Diagnostic Summary Report
Provides an overall summary of failed peer-to-peer sessions and conferencing sessions.
• Conference Diagnostic Report
Provides an overall trend view of failed conferencing sessions and trend views for each conference modality.
• Diagnostic Report
Provides diagnostic and troubleshooting information (including SIP response codes and diagnostic headers and IDs) for failed sessions.
• Failure Distribution Report
Provides an analysis of failed sessions.
• Failure List Report
Provides detailed information about the individual participants involved in a failed conference.
• Media Quality Metrics Distribution Report
Provides a graphical view of specified QoE metrics.
• Peer-to-Peer Activity Diagnostic Report
Provides an overall trend view of failed peer-to-peer sessions.
• Server Media Quality Trend Report
Provides a way for you to graphically compare as many of five servers on selected QoE metrics.
• Server Performance Report
Provides information about the servers that have experienced the most problems based on measurements of key quality metrics such as degradation, packet loss, and jitter.
• Top Failures Report
Provides a list of the most frequent failures and their trends over time.
Call Detail Report
[pic]
Overview
The Call Detail Report provides a detailed look at an individual call. The report includes nearly all the QoE metrics and statistics collected by Monitoring Server, divided into report sections such as the following:
• Call Information
• Caller Device and Signal Metrics
• Callee Device and Signal metrics
• Caller Client Event
• Callee Client Event
• Audio Stream (Caller to Callee)
• Video Stream (Caller to Callee)
• Audio Stream (Callee to Caller)
• Video Stream (Callee to Caller)
Keep in mind that the categories and the metrics you see on a given report depend on two things: the type of session and the type of endpoints used in the session. For example, an audio-only call will not report metrics for video streams; that's because the call didn't have a video stream. Likewise, you might have a report that lists caller statistics but not callee statistics. That's typically because the callee was not using a SIP-compliant device. Endpoints are responsible for reporting statistics at the end of a call; however, a cell phone (which knows nothing about SIP or SIP statistics) is unable to report that kind of information. If you call someone and they answer you on their cell phone, you will not get a report from that cell phone when the call ends.
The Call Detail Report is most useful when you are trying to determine exactly why a given call experienced problems.
Accessing This Report
[pic]
The Call Detail Report can be accessed from any of the following reports:
• The Location Report (by clicking either the Call volume or the Poor call percentage metric)
• The Media Quality Summary Report (by clicking either the Call volume or Poor call percentage metric)
• The Server Performance Report (by clicking either the Call volume or Poor call percentage metric)
• The Call List Report (by clicking the Detail metric)
From within the Call Detail Report you can access the Device Report by clicking either of the following metrics:
• Capture device
• Render device
You can also access the Server Media Quality Trend Report by clicking the A/V edge server metric.
Making the Best Use of This Report
The Call Detail Report will typically include more than 250 different metrics, including items such as Microphone timestamp drift, Low SNR time, and Near end to echo time. If you can't remember what all of these metrics actually measure, try holding your mouse over the metric label; often, a tooltip will appear describing that metric:
[pic]
If you're having problems locating a metric, type part of the metric label in the search box and then click Find. For example, if you can't find the Low SNR time metric, type SNR in the search box, and then click Find.
Call List Report
[pic]
Overview
The Call List Report provides QoE metrics for individual calls made and received in your organization. Note that the actual metrics reported will depend on how you access the Call List Report. For example, if you open the report from the Device Report, you'll see metrics such as the following, metrics that are also reported on the Device Report:
• Caller's microphone
• Caller's speaker
• Callee's microphone
• Callee's speaker
• Ratio of voice switch time
However, if you open the Call List Report from the Location Report, you won't see any of those metrics; instead, you'll see metrics like these:
• Round trip (ms)
• Degradation (MOS)
• Packet loss
• Jitter (ms)
That's because those are the metrics reported on the Location Report. Either way, from the Call List Report, you can always click the Detail metric to access complete QoE information for any call.
Accessing This Report
[pic]
The Call List Report can be accessed from any of the following reports:
• The Location Report (by clicking the Call volume or Poor call percentage metric)
• The Device Report (by clicking the Call volume or Poor call percentage metric)
• The Media Quality Summary Report (by clicking the Call volume or Poor call percentage metric)
• The Server Performance Report (by clicking the Call volume or Poor call percentage metric)
From within the Call List Report, you can access the Call Detail Report by clicking the Detail metric.
Making the Best Use of This Report
If you can't remember what some of the Call List Report metrics (such as Ratio voice switch time) actually measure, simply hold your mouse over the metric label; a tooltip will appear giving you a brief description of the metric:
[pic]
Conference Detail Report
[pic]
Overview
The Conferencing Detail Report provides detailed information about all the users who participated in a conference. For example, you can see information such as the date and time that a user joined the conference, the date and time that the user left the conference, and the user agent of the endpoint that was used to connect that user to the conference. You can also see information about the user's role in each conference (for example, presenter or attendee). And, perhaps most importantly, you get to quickly see which users were able to successfully join and complete the conference and which users were not.
Accessing This Report
[pic]
The Conference Detail Report can be accessed from the following reports:
• The Call Admission Control Report (by clicking the Detail metric for a conference)
• The Failure List Report (by clicking the Conference metric)
• The User Activity Report (by clicking the Conference URI metric)
From the Conference Detail Report, you can access the Diagnostic Report by clicking the Diagnostic Report (Detail) metric.
Making the Best Use of This Report
While in the Conference Detail Report, hold your mouse over any of the health status icons to get more information:
[pic]
Media Quality Summary Report
[pic]
Overview
The Media Quality Summary Report is perhaps your best bet for analyzing call quality in your organization. This report provides detailed QoE call metrics broken down into the following categories:
• Unified communications (UC) peer-to-peer calls (such as a Microsoft® Lync™ 2010-to-Lync 2010 call)
• UC conference sessions
• PSTN conference sessions
• PSTN calls: media bypass
• PSTN calls (non-bypass): UC leg
• PSTN calls (non-bypass): Gateway leg
• Other call types
When you first open the report, you see summary information for each of these categories. Without leaving the report, you can expand each category to look at subcategories such as calls made from Microsoft® Office Communicator 2007 R2 communications software to Lync. Then you can drill down into these subcategories to see details about each call made within that subcategory. For example:
[pic]
The Media Quality Summary Report also allows you to apply filters that enable you to compare the call quality of wired calls versus wireless calls; internal calls versus external calls; and virtual private network (VPN) calls versus non-VPN calls.
Accessing This Report
[pic]
The Media Quality Summary Report is accessed from the Monitoring Server Reports home page. You can drill down to the Call List Report by clicking either of the following metrics:
• Call volume
• Poor call percentage
In addition, you can access the Media Quality Metrics Distribution Report by clicking any of the following:
• Round trip (ms)
• Degradation (MOS)
• Packet loss
• Jitter (ms)
• Healer concealed ratio
• Healer stretched ratio
• Healer compressed ratio
Making the Best Use of This Report
As noted, the Media Quality Summary Report divides the displayed data into the following categories:
• UC Peer to Peer Calls (such as Lync-to-Lync calls)
• UC Conference Sessions
• PSTN Conference Sessions
• PSTN Calls: Media Bypass
• PSTN Calls (Non-Bypass): UC Leg
• PSTN Calls (Non-Bypass): Gateway Leg
There might be times when you want to export the data for just one of these categories; for example, perhaps you are interested only in PSTN calls that used media bypass. When you export the data to Microsoft® Excel® spreadsheet software, however, you get all the data, and that data gets saved as an outline:
[pic]
That might not look too bad, but an outline can make it difficult to sort and filter the data (especially if you're interested only in a subset of the data) and can also make it very difficult to export that data to a comma separated values (CSV) file (a format that makes it easy to run different data analyses by using Windows PowerShell™).
Because of that, you might find it useful to try an alternate approach. First, expand just the category of interest to you (for example, UC Peer to Peer Calls). Your copy of the Media Quality Summary Report will then look something like this:
[pic]
Now, export the data in Microsoft® Word format. When you do that, you'll save only the data that was displayed on the screen; you won't get any of the hidden data:
[pic]
From there, you can copy just the data of interest to you and then paste that into Excel.
Peer-to-Peer Session Detail Report
[pic]
Overview
The Peer-to-Peer Session Detail Report returns detailed information about a peer-to-peer session. For example, if you select an IM session, the report will tell you the number of messages sent by each of the two users in the session.
Accessing This Report
[pic]
The Peer-to-Peer Session Detail Report can be accessed from any of the following reports (all of which can be accessed from the Monitoring Server Reports home page):
• IP Phone Inventory Report
• User Activity Report
• Call Admission Control Report
• Failure List Report
From the Peer-to-Peer Session Detail Report, you can access the Diagnostic Report by clicking the Diagnostic Report (Details) metric. You can also access the Top Failures Report by clicking either of these two metrics:
• Response
• Diagnostic ID
Making the Best Use of This Report
The Peer-to-Peer Session Detail Report includes a large number of metrics, many of which might not be familiar to system administrators. Oftentimes, however, you can view a tooltip that offers a brief description of that metric simply by holding your mouse over the metric label. For example, here's what you'll see if you hold your mouse over the label AGC gain:
[pic]
Note that the actual metrics shown on a given report will depend on the type of peer-to-peer session you selected. An audio/video (A/V) session will report a different set of metrics than an IM session.
You can also hold your mouse over the Response code and Diagnostic ID metrics in order to obtain a description of those values:
[pic]
User Activity Report
[pic]
Overview
The User Activity Report provides a detailed list of the peer-to-peer and conferencing sessions carried out by your users in a given time period. Unlike many of the Monitoring Server reports, the User Activity Report ties each call to individual users. For example, peer-to-peer sessions specify both the SIP Uniform Resource Identifier (URI) of the person who initiated the call (the From user) and the person who was being called (the To user). If you expand the information for a conference, you'll see a list of all the conference participants and the role they held for that conference:
[pic]
The User Activity Report is sometimes referred to as the "help desk" report; that's because the report is often used by help desk personnel to retrieve session information for a specific user. You can filter for calls made to or made from an individual user simply by typing the user's SIP URI in the User URI prefix box.
If you do this, keep in mind that the User Activity Report will search anywhere in the URI field for the value entered in this box. For example, suppose you are searching for this user:
Ken.Myer@
If you just type ken in the URI box the User Activity Report will locate Ken.Myer@. It will also locate these users:
• Ronen.Ashkenazi@
• Markus.Rankenburg@
• Ken.Kwok@
• Will.Kennedy@
In other words, the more specific information you enter, the more likely it will be that you will get back just the information of interest to you.
Accessing This Report
[pic]
The User Activity Report is accessed from the Monitoring Server Reports home page; you can also reach the User Activity Report by clicking the User URI metric on the IP Phone Inventory Report. From within the User Activity Report, clicking the Conference URI (for a conference) takes you to the Conference Detail Report. Similarly, clicking the Detail metric for a peer-to-peer call takes you to the Peer-to-Peer Session Detail Report.
Making the Best Use of This Report
There's a lot of good information in the User Activity Report, but sometimes that information can be difficult to get at. For example, all the user activity that takes place in your organization during a specified period is included in the User Activity Report. This means that, buried within the report, is information about which users actually used Lync Server in some way, shape, or form.
Note. We should qualify that statement a little. First, it's always possible that some sort of user activity might have gone unrecorded: while Monitoring Server strives to keep information about all phone calls, it's possible that a call could have been made without the information about that call being written to the database. Monitoring Server is designed to give an extremely accurate but not necessarily perfect look at how Lync Server is being used. (The fact that there is no guarantee that 100% of all calls are recorded explains why Monitoring Server should not be used as a billing system.)
Second, a Monitoring Server report can display, at most, only 1,000 records. Depending on the amount of user activity you have, and depending on the time period you are working with, that means your query might not return all the data actually stored in the database.
In addition to that, the User Activity Report indicates the type of session (modality) that a user participated in (for example, IM, file transfer, or audio). However, you can't actually filter by modality; the Modality filter offers only one choice: All. The only way to filter by modality is to export the data and then do your filtering in another application (such as Excel or Windows PowerShell).
What this means is that you can easily retrieve detailed information about any one user in your organization. What you can't do, at least not directly, is answer questions like these:
• Which users actually used the system during this time period?
• Which users were the most active during this time period?
• Are the users who make the most phone calls also the users who participate in the most IM sessions?
If you need to answer questions like this, your best bet is to export the data retrieved by Monitoring Server Reports to an Excel spreadsheet; you then use that spreadsheet, a CSV file, or both to analyze the data in ways that Monitoring Server Reports can't. For example, suppose you have exported the report data to Excel and then to a CSV file. (For details about doing this, see the document Using Monitoring Server Reports, also in this download package.) At that point, you can import the data from the CSV file to Windows PowerShell by using a command similar to this:
$x = Import-Csv –Path "C:\Data\User_Activity_Report.csv"
After the data has been imported, you can use simple Windows PowerShell commands to help answer your questions. For example, this command returns a list of unique users who served as the "From user" in at least one session:
$x | Group-Object "From user" | Select Name | Sort-Object Name
In other words:
Name
----
David.Ahs@
Gilead.Almosnino@
Henrik.Jensen@
Ken.Myer@
Pilar.Ackerman@
This command lists the unique users based on the total number of sessions that they participated in:
$x | Group-Object "From user" | Select Count, Name | Sort-Object Count –Descending
That command returns data similar to this:
Count Name
----- ----
523 Ken.Myer@
63 David.Ahs@
29 Pilar.Ackerman@
17 Gilead.Almosnino@
10 Henrik.Jensen@
This command limits the reported sessions to those that included audio as a modality:
$x | Where-Object {$_.Modalities –match "audio"} | Group-Object "From user" | Select Count, Name | Sort-Object Count –Descending
Here's another tip for making the best use of the User Activity Report. If you hold your mouse over any Diagnostic ID shown on the report, a tooltip will appear describing that ID:
[pic]
Call Admission Control Report
[pic]
Overview
The Call Admission Control Report provides information about peer-to-peer sessions and conferencing sessions that were conducted under restrictions set in place by CAC. CAC, introduced in Lync Server, provides a way for administrators to allow (or not allow) communication sessions based on bandwidth constraints. For example, administrators can create policies that impose a limit on the amount of bandwidth available for voice and video calls. If that bandwidth limit has been reached, then no new voice or video calls can be placed until one of the current calls has ended and freed up the required network resources.
Accessing This Report
[pic]
The Call Admission Control Report is accessed from the Monitoring Server Reports home page. From the Call Admission Control Report, you can drill down to either of the following reports:
• Conference Detail Reports (by clicking the Details metric from a conference session)
• Peer-to-Peer Session Detail Reports (by clicking the Details metric from a peer-to-peer session)
Making the Best Use of This Report
To get a list of calls that failed because of insufficient bandwidth, select Calls rejected because of call admission control from the Call category drop-down list. Most of the returned calls will likely have a diagnostic ID of 5:
Insufficient bandwidth to establish session. Attempt PSTN re-route.
That indicates that CAC limitations were preventing the call from being made on the Voice over Internet Protocol (VoIP) network.
Conference Activity Report
[pic]
Overview
The Conference Activity Report makes it easy for you to answer questions like these: how many conferences are we holding each day, and when exactly are we holding these conferences? Information like this is useful not only in its own right but also as a troubleshooting tool. For example, suppose users are complaining that the network seems particularly slow in the middle of the day. A quick glance at the Conference Activity Report suggests one possible reason: far more conferences are being scheduled between the hours of 10:00 AM and 2:00 PM than at any other time:
[pic]
If the slow network is causing problems, you can encourage users to reschedule some of their conferences during the less-heavily trafficked times of the day.
Accessing This Report
[pic]
The Conference Activity Report is accessed from the Conference Summary Report by clicking either one of the following metrics:
• Total conferences
• Total participants
Making the Best Use of This Report
By default, the Conference Activity Report shows you the total number of conferences for the specified time period (for example, the total number of conferences per day or the total number of conferences per hour of the day). However, you can also choose to display the total number of participants for that time period or the total number of participant minutes. To do that, click the Show/Hide Parameters button to display the filtering options, and then select one of the following from the report by drop-down list:
• Participant count
• Participant minutes
• Conference count
Conference Summary Report
[pic]
Overview
The Conference Summary Report provides an overall view of your conferencing sessions. A conference typically involves more than two users and requires the use of Lync Server conferencing services. By comparison, a peer-to-peer session typically involves just two users and does not require the use of Lync Server's conferencing services. Peer-to-peer activities are reported on the Peer-to-Peer Activity Summary Report.
The Conference Summary Report not only tells you how many conferences were held during a given time period (hourly, daily, weekly, monthly) but also tells you the total number of people who took part in those conferences and the total number of unique conference organizers.
Note. A "unique” organizer is anyone who scheduled at least one conference. For example, if Pilar Ackerman scheduled one conference, she counts as one unique organizer. If Ken Myer scheduled 148 conferences, he, too, counts as one unique organizer. The following table shows eight scheduled conferences but just three unique organizers (Ken Myer, Pilar Ackerman, and David Ahs):
|Conference organizer |Conference date |
|Ken Myer |4/1/2011 10:00 AM |
|David Ahs |4/1/2011 11:00 AM |
|Ken Myer |4/1/2011 11:00 AM |
|Pilar Ackerman |4/1/2011 1:00 PM |
|Ken Myer |4/1/2011 2:00 PM |
|Pilar Ackerman |4/1/2011 2:00 PM |
|Ken Myer |4/2/2011 10:00 AM |
|Pilar Ackerman |4/2/2011 10:00 AM |
The Conference Summary Report also indicates how many conferences included audio, video, or both.
Accessing This Report
[pic]
The Conference Summary Report is accessed from the Monitoring Server Reports home page. You can drill down to the Conference Activity report by clicking either of the following metrics:
• Total conferences
• Total participants
Making the Best Use of This Report
Total values for most of the metrics used on the Conference Summary Report can be found at the bottom of the report; scroll down to see values such as the total number of conferences held during the specified time period and the total number of people who participated in those conferences. One metric that is not totaled at the bottom of the report is Total unique conference organizers. Why not? Well, suppose you are looking at a month's worth of data. On day 1 you had 34 unique conference organizers; on day 2 you had 27 unique conference organizers. Does that mean you had 61 unique conference organizers for those two days? Not necessarily. After all, all 27 people who organized conferences on day 2 might be among the 34 people who organized conferences on day 1. For example, in this simple report, note that Ken Myer and Pilar Ackerman scheduled conferences both on 4/1/2011 and on 4/2/2011:
|Conference organizer |Conference date |
|Ken Myer |4/1/2011 10:00 AM |
|David Ahs |4/1/2011 11:00 AM |
|Ken Myer |4/1/2011 11:00 AM |
|Pilar Ackerman |4/1/2011 1:00 PM |
|Ken Myer |4/1/2011 2:00 PM |
|Pilar Ackerman |4/1/2011 2:00 PM |
|Ken Myer |4/2/2011 10:00 AM |
|Pilar Ackerman |4/2/2011 10:00 AM |
To get a better idea of the total number of unique users who organized conferences, change your time interval; for example, look at the data by month instead of by day.
To show you the difference, when testing Monitoring Server Reports, we looked at the Conference Summary Report for the month of August 2010. Viewed day-by-day, the report suggested that there were 5,429 unique conference organizers. When looked at in the per-month view, that total dropped to 942. Why? Because there were numerous duplicates in the day-by-day view.
Device Report
[pic]
Overview
The Device Report might be better titled the “Microphone and Speakers Report”; that's because the Device Report retrieves call-related metrics (such as poor call percentage, echo, and voice switch time) grouped by the microphones and speakers used in the call. If you are interested in IP phones (also commonly referred to as "devices"), use the IP Phone Inventory Report instead.
By default, the information displayed in the Device Report is also based on the microphone (the capture device) and speakers or headset (the render device) used in the call. For example, suppose you have several users who use the following capture device and the following render device:
• Capture device: Microphone (SoundMAX Integrated Digital HD Audio)
• Render device: Headset earphone (Microsoft LifeChat LX-3000)
If those users made a total of 254 calls, you'll see an entry like this in the report:
|Capture device |Render device |Call volume |
|Microphone (SoundMAX Integrated Digital HD |Headset Earphone (Microsoft LifeChat LX-3000) |254 |
|Audio) | | |
Now, suppose you have a number of users who use that same capture device but a different render device. In that case, you'll have a second line entry in the report for that unique combination of capture device and render device:
|Capture device |Render device |Call volume |
|Microphone (SoundMAX Integrated Digital HD |Headset Earphone (Microsoft LifeChat LX-3000) |254 |
|Audio) | | |
|Microphone (SoundMAX Integrated Digital HD |Speakers (SoundMAX Integrated Digital HD Audio)|319 |
|Audio) | | |
If you would rather see combined totals for a given device (for example, for the SoundMAX capture device, regardless of the render device used), select the appropriate option from the Device type drop-down list (either Capture device or Render device). If you select Capture device in this example, that will give you output similar to this:
|Capture device |Call volume |
|Microphone (SoundMAX Integrated Digital HD |573 |
|Audio) | |
Accessing This Report
[pic]
The Device Report is typically accessed from the Monitoring Server Reports home page. However, if you are viewing the Call Detail Report, you can drill down to the Device Report for a specific device by clicking either of the following metrics:
• Capture Device
• Render Device
From the Device Report, you can drill down to the Call List Report by clicking either of the following metrics:
• Call volume
• Poor call percentage
Making the Best Use of This Report
When it comes to device names, the Device Report is extremely detailed; for example, in our test setup, we found the following Aastra capture devices:
• Aastra 3002 Microphone (2- Aastra 3002)
• Aastra 3002 Microphone (3- Aastra 3002)
• Aastra 3002 Microphone (Aastra 3002)
• Aastra 6725ip
• Aastra 6725ip Microphone (10- Aastra 6725ip)
• Aastra 6725ip Microphone (10- Aastra 6725ip)-V0
• Aastra 6725ip Microphone (2- Aastra 6725ip)
• Aastra 6725ip Microphone (3- Aastra 6725ip)
• Aastra 6725ip Microphone (4- Aastra 6725ip)
• Aastra 6725ip Microphone (5- Aastra 6725ip)
• Aastra 6725ip Microphone (6- Aastra 6725ip)
• Aastra 6725ip Microphone (7- Aastra 6725ip)
• Aastra 6725ip Microphone (9- Aastra 6725ip)
• Aastra 6725ip Microphone (9- Aastra 6725ip)-V0
• Aastra 6725ip Microphone (Aastra 6725ip)
• Aastra 6725ip Microphone (Aastra 6725ip)-V0
• Aastra 6725ip Microphone (USB Audio Device)
• Aastra 6725ip Microphone (USB Audio Device)-V0
Oftentimes you'll want that level of detail; at other times, however, you might be interested only in how many calls use any Aastra microphone, regardless of model number. How can you get at information like that? One way is to export the Device Report data to Excel, and then save that data to a CSV file (for example, C:\Data\Devices_Report.csv). You can then use a set of commands similar to these to import the CSV file into Windows PowerShell and report back the total number of calls made by using an Aastra capture device:
$devices = Import-Csv "C:\Data\Device_Report.csv
$sum = $devices | Where-Object {$_."Capture device" -match "Aastra"}
$sum | foreach-object {[Int]$x = [Int]$x + [Int]$_."call volume"}
$x
That will return a single value representing the total number of calls made by using an Aastra capture device. For example:
384
IP Phone Inventory Report
[pic]
Overview
The IP Phone Inventory Report reports information about the IP phones currently in use in your organization. Having said that, it should be noted that the report does have several limitations when it comes to being used as a true inventory report. For one thing, the IP Phone Report simply lists all the phones that logged on to Lync Server during the specified time period, sorted by their last logon time. If a phone did not log on during the specified time period, then it will not be listed in the inventory report. That includes phones that logged on before the time period started and were still logged on during the specified time interval. For example, suppose you wanted to look at the phone inventory for March 2011. Suppose, as well, that several phones logged on to Lync Server on February 28, 2011 and were still logged on on March 1st. Those phones will not show up on the inventory report for March 2011.
It's also important to note that the inventory report could include phones that your organization no longer uses. For example, suppose a number of Fabrikam phones logged on to the system on March 1, 2001; five days later your organization got rid of all those Fabrikam phones and replaced them with a newer Contoso model. The Fabrikam phones will still appear on the inventory report simply because they logged on to the system during the month of March.
In addition, the IP Phone Inventory Report does not report summary totals for the different types of phones. For example, suppose you have 105 Polycom CX600 phones. The report will not tell you that you have 105 of these phones; instead, you will simply see 105 separate entries for the Polycom Cx600. The only way to know that there are 105 entries for the Polycom Cx600 would be to count each of those entries manually.
Note. Or, as we’ll see in a few minutes, export the data, and use Excel or Windows PowerShell to do that counting for you.
Accessing This Report
[pic]
The IP Phone Inventory Report is accessed from the Monitoring Server Reports home page. If you click the User URI metric you can access the User Activity Report for that user. Clicking the Last activity metric for a peer-to-peer call will take you to the Peer-to-Peer Session Detail Report; clicking that same metric for a conference will take you to the Conference Detail Report.
Making the Best Use of This Report
If you're interested only in usage information for one particular kind of phone (for example, if you want to find out how often a Polycom CX600 phone is being used) you can get that information directly from the IP Phone Inventory Report by filtering for that particular kind of phone. However, if you want summary information for all your phones (for example, to find out how many people are using a Polycom CX600, how many are using an LG-Nortel IP8540, and so on), then you will need to export the data and use another application (such as Windows PowerShell) to do that type of analysis. For example, suppose you export the data to a CSV file (C:\Data\IP_Phone_Inventory_Report.csv). In that case, you could use these two commands to provide summary data for all your phones:
$phones = Import-Csv "C:\Data\IP_Phone_Inventory_Report.csv"
$phones |Group-Object Manufacturer, "Hardware version" | Select-Object Count, Name | Sort-Object Count –Descending
That will return data similar to this:
Count Name
----- ----
267 POLYCOM, CX700
267 POLYCOM, CX600
166 POLYCOM, C
68 Microsoft, CPE
64 LG-Nortel, IP8540
59 Aastra, 6725ip
37 LG-Nortel, IP
22 POLYCOM, CX3000
11 Microsoft, CPE_A
9 POLYCOM, CX500
7 Aastra, 6721ip
Similarly, these two commands tell you which phones logged on to the system but were never actually used to make a call (the value of the Last activity metric is blank, indicating that there hasn't been any last activity):
$phones = Import-Csv "C:\Data\IP_Phone_Inventory_Report.csv"
$phones | Where-Object {$_."Last activity" -eq ""}
That returns data similar to this for each phone that has not been used:
Manufacturer : POLYCOM
Hardware version : CX600
MAC address : 00-04-F2-00-01-76
User URI : 422
User agent : CPE/4.0.7423.1 OCPhone/4.0.7423.1 (Microsoft Lync 2010 (Beta) Phone Edition)
Last logon time : 8/30/2010 4:44:48 PM
Last logoff time : 8/30/2010 5:59:07 PM
Last activity :
There’s another interesting way to use the IP Phone Inventory Report: if you have the Media Access Control (MAC) address of an IP phone, you can find out the user who last used that phone simply by entering that address in the MAC address text box. The IP Phone Inventory Report will then report back the SIP address of the user who last logged on with that phone (among other things). Alternatively, you can enter a user SIP address (in the User URI prefix box) to find out all the phones that have been used by that user.
Location Report
[pic]
Overview
The Location Report provides information about call quality metrics grouped by network location (that is, by network subnet). If your users are experiencing problems with their calls, this report can help you determine if those problems are widespread or if they are largely confined to a given network segment.
Accessing This Report
[pic]
The Location Report is accessed from the Monitoring Server Reports home page. You can drill down to the Call List Report by clicking either of the following metrics:
• Call volume
• Poor call percentage
Making the Best Use of This Report
One of the more interesting uses of the Location Report is one that you could very easily overlook; sometimes it can be difficult to draw conclusions just by looking at the Location Report. That's because subnets are not sorted in order, and subnets can appear multiple times in the report (and as both the Caller location and the Callee location). To get a better idea of how well things are working on a given subnet, you might want to export the data to Excel.
Admittedly, if you export the Location Report data to Excel, you'll see pretty much the same set of data that you see in the Location Report itself. However, if you scroll down the list in Excel, you'll also see a matrix similar to this:
[pic]
This matrix shows you the relationship between a caller location (the subnets listed down the leftmost side of the matrix) and all its callee locations. For example, in the preceding figure, you can see that the users in subnet 10.121.130.0 made calls to both subnet 157.54.62.0 and 157.54.62.128. The values in the figure represent the average round-trip time (in milliseconds) and the total number of calls made (the value in parentheses). For example, the value 2.14 (74) indicates an average round-trip time of 2.14 milliseconds and a total of 74 calls.
Looking at the data in this fashion can help you determine if poor call results are an anomaly or are suggestive of a real problem with a given network segment. For example, three of the four values listed for subnet 10.171.42.0 are worrisome: they exceed 200 milliseconds. On the other hand, those values represent only a total of nine calls, which means there might be two or three very poor calls that are skewing the results. What this suggests is that this subnet is one that you might want to keep an eye on.
We should point out that there is one drawback to exporting data to Excel: the data is saved as an outline, and each row is repeated. (This is due to a small issue in the Location Report, which results in your having two identical rows in the Excel spreadsheet for each row in the Location Report.)
Duplicate rows are obviously a problem; you can't make any conclusions based on erroneous data. One way to work around this problem is to export the data in Word format instead of in Excel format. After you've done that, you can open the exported file in Word, copy the data table (which is not saved as an outline and therefore does not include the duplicate rows), and then paste that table into Excel.
Peer-to-Peer Activity Summary Report
[pic]
Overview
The Peer-to-Peer Activity Summary Report provides an overall view of your peer-to-peer communication sessions. A peer-to-peer session typically involves just two users and does not require the use of Lync Server conferencing services. By comparison, a conference typically involves more than two users and does require the use of Lync Server conferencing services. Conference activity is reported on the Conference Summary Report.
The Peer-to-Peer Activity Summary Report helps you answer questions such as these:
• How many peer-to-peer instant messages do my users send on a typical day?
• Are any of my users taking advantage of Lync Server's program sharing and file transfer capabilities?
• Users have been complaining that the network seems slow at certain times of the day. How many minutes are being devoted to peer-to-peer audio and video sessions during those time periods?
Accessing This Report
[pic]
The Peer-to-Peer Activity Summary Report is accessed from the Monitoring Server Reports home page. From the Peer-to-Peer Activity Summary Report, you can drill down to the Peer-to-Peer IM Report by clicking either of the following metrics:
• Total peer-to-peer IM sessions
• Total peer-to-peer IM messages
Likewise, you can drill down to the Peer-to-Peer Voice and Video Report by clicking any of these metrics:
• Total peer-to-peer audio sessions
• Total peer-to-peer audio session minutes
• Total peer-to-peer audio sessions
• Total peer-to-peer audio session minutes
Making the Best Use of This Report
At the bottom of the Peer-to-Peer Activity Summary Report, you'll find totals for metrics such as Total peer-to-peer IM sessions and Total peer-to-peer IM messages. This provides a quick summary of the detailed information found in the body of the report.
Peer-to-Peer IM Report
[pic]
Overview
The Peer-to-Peer IM Report provides trend information about peer-to-peer IM sessions, broken down by pool and by authentication type. The report can show either the total number of sessions held during the specified time period (for example, day-by-day or hour-by-hour), or it can show the total number of instant message sent during that time period.
Accessing This Report
[pic]
The Peer-to-Peer IM Report can be accessed only by first opening the Peer-to-Peer Activity Summary Report and then clicking either of the following metrics:
• Total peer-to-peer IM sessions
• Total peer-to-peer IM messages
Making the Best Use of This Report
By default, the Peer-to-Peer IM Report shows you the message count per hour (or day, depending on your settings). However, you can also choose to view the day by sessions per hour. To do that, click the Hide/Show Parameters button in the upper right corner of the Reports window:
[pic]
After that you can then select Session Count from the Report by drop-down list:
[pic]
Peer-to-Peer Voice and Video Report
[pic]
Overview
The Peer-to-Peer Voice and Video Report provides a detailed look at the distribution of voice and video calls over a specified period of time (for example, calls per hour or calls per day). The report also gives you the option of viewing all the voice and video calls that were made or viewing only the successful calls or the failed calls. The report shows call information broken down into the following groupings:
• Calls per pool
• Calls per call type (for example a Lync-to-Lync call versus a Lync call to a person on the PSTN network)
• Calls per access type (users logged on to the internal network versus users logged on to the external network)
• Calls per Mediation Server
Accessing This Report
[pic]
The Peer-to-Peer Voice and Video Report can be accessed only by first opening the Peer-to-Peer Activity Summary Report and then clicking either of the following metrics:
• Total peer-to-peer audio sessions
• Total peer-to-peer audio minutes
• Total peer-to-peer video sessions
• Total peer-to-peer video minutes
Making the Best Use of This Report
There are actually a number of ways you can filter the Peer-to-Peer Voice and Video Report; by default, however, those filtering options are hidden from view. To view the filtering options available to you, click the Show/Hide Parameters button in the upper right corner of the report window:
[pic]
After you do that, the filtering options will be available for your use:
[pic]
PSTN Conference Summary Report
[pic]
Overview
In Lync Server, a "PSTN conference" is any conference in which at least one participant dials in to the audio portion by a using a PSTN phone. (A PSTN phone is a landline phone, a cell phone, or any other non-VoIP telephone.) Although referred to as PSTN conferences in the Monitoring Server Reports, these conferences are perhaps more-commonly known as “dial-in conferences.”
The PSTN Conference Summary Report provides information about all the PSTN conferences held in your organization (that is, all the conferences that had at least one dial-in user). The report includes information about the total number of PSTN conferences, the total number of people who participated in those conferences, and, perhaps, most important, the total number of dial-in users (the Total PSTN participants metric).
Accessing This Report
[pic]
The PSTN Conference Summary Report is accessed from the Monitoring Server Reports home page. The PSTN Conference Summary Report is not linked to any other reports. Note, too, that you cannot retrieve detailed call information for a PSTN conference, in part because individual endpoints are responsible for submitting this information. PSTN phones are not capable of tracking or submitting call detail information.
Making the Best Use of This Report
To determine the percentage of all your conferences that include dial-in users, compare the value of the Total PSTN conferences metric with the Total conferences metric found on the Conference Summary Report.
If you don't see as many PSTN conferences as you might have expected to see, keep in mind that the ability to organize a conference that allows dial-in users depends on the conferencing policy that has been assigned to a user: if very few of your users are allowed to hold PSTN conferences you would obviously see very few PSTN conferences. You can quickly verify which of your conferencing policies (if any) allow users to schedule PSTN conferences by running the following command from within the Lync Server Management Shell:
Get-CsConferencingPolicy | Select-Object Identity, EnableDialInConferencing
That will return data similar to this:
Identity EnableDialInConferencing
-------- ------------------------
Global True
site:Redmond False
site:Dublin False
Tag:RedmondDialInUsers True
Tag:DublinDialInUsers True
User Registration Report
[pic]
Overview
The User Registration Report provides an overview of user logon activity, most notably information about the number of users who logged on to Lync Server during a specified time period (hourly, daily, weekly, or monthly). Keep in mind that the report tells you only how many people logged on; it does not tell you which people logged on. Information about which users are using Lync Server (and which ones are not) is not readily available by using Monitoring Server Reports. However, you can get a rough estimate of this information by using the User Activity Report.
When providing information about user logons, the User Registration Report draws two important distinctions. First, it breaks logons down into two primary categories: internal logons and external logons. Internal logons represent users who logged on from inside your organization's firewall (that is, while connected to the corporate network). External logons represent users who logged on from outside the firewall and through an Edge Server (for example, a user who logged on from an Internet café). If you're wondering how many (if any) of your users are logging on from outside the firewall, the User Registration Report can provide you with an answer.
In addition, the User Registration Report notes how many active users were present during a given time period. An active user is a user who took part in an IM session, participated in a conference, made or received a phone call, or otherwise used Lync Server during that period of time. This is different from a user who logged on but never actually used the system.
Accessing This Report
[pic]
The User Registration Report can be accessed only from the Monitoring Server Reports home page. The User Registration Report does not link to any other reports.
Making the Best Use of This Report
After you've deployed Lync Server, one commonly-asked question is this: how do I know if my users are actually using this new technology? Although it has a few limitations in this regard, the User Registration Report can help you answer this question. To determine whether users are using Lync Server, you need to do two things. First, get the value of the Unique logon users metric from the User Registration Report. Why Unique logon users? Because this value tells you how many distinct individuals logged on to Lync Server.
By comparison, the Total logons metric shows how many total times someone (anyone) logged on to Lync Server. For example, suppose Ken Myer logged on to Lync Server five different times in a single day. In that case, Ken Myer would count as five separate logon sessions for the Total logons metric but just one logon user for the Unique logon users metric.
Let's look at a table that helps to explain this a little better. Suppose these are all your logons for a given time period:
|User |Logon time |
|Ken Myer |4/1/2011 8:45 AM |
|Ken Myer |4/1/2011 8:46 AM |
|Pilar Ackerman |4/1/2011 9:17 AM |
|Ken Myer |4/1/2011 9:22 AM |
|Pilar Ackerman |4/1/2011 9:31 AM |
Notice that we have a total of five logons. However, there are only two unique logon users: Ken Myer (who logged on three times) and Pilar Ackerman (who logged on twice). That's the difference between logons and unique logon users.
In addition to knowing the number of unique logons, you need to know the total number of users who have been enabled for Lync Server. That value can be retrieved by opening the Lync Server Management Shell and running the following Windows PowerShell command:
(Get-CsUser).Count
If the preceding command returns a value of 1,236 and Unique logon users metric returns an average value of 667, that suggests that a little over half of your Lync-enabled users are actually logging on to the system each day (667 divided by 1,236 or approximately 54%).
Note. Keep in mind that the logon metrics record users who actually logged on during the specified time period; they don't keep track of users who were already logged-on to the system. What does that mean? Well, suppose your Unique logon users metric shows 667 logons; in our example, that suggests that about half your users are logging on to the system. However, suppose 300 users were already logged on to the system at the time you began checking the logon data. That would mean that you actually had nearly 1,000 users logged on to Lync Server, which would mean that closer to 80% of your users were logged on.
You should also compare the Unique logon users value with the value of Unique active users metric. The Unique active users metric tells you how many unique users actually used Lync Server: they made a phone call, joined a conference, or participated in an IM session. This is useful information because Lync can be configured to automatically start each time a user starts the Windows® operating system. Because of that, you might have a large number of users who log on to Windows each day and are automatically logged on to Lync but then never actually use Lync Server.
Unique active users also helps provide more meaningful data in an organization where users typically do not log off Windows at the end of the day; instead, they simply lock their computers and leave Windows—and Lync—running. In a situation like that, you might end up with very few logons per day because your users logged on several days ago and never logged off. However, the Unique active users value will let you know if anyone is actively using Lync or another Lync-compatible endpoint.
Response Group Call List Report
[pic]
Overview
The Response Group application provides a way for Lync Server to answer and route phone calls based on the number that was dialed and, optionally, on the caller's responses to a series of questions. The Response Group Call List Report represents a collection of calls made for a specified period of time and for a specified type of call. The Response Group Usage Report (which must be opened before you can open the Response Group Call List Report) recognizes the following call types:
• Received calls The total number of calls received by all instances of the Response Group.
• Successful calls The total number of calls that were picked up by the Response Group.
• Offered calls The total number of calls that were transferred to a Response Group agent.
• Answered calls The total number of calls that were actually answered by a Response Group agent.
• Percentage of abandoned calls The percentage of calls that were received by the Response Group but were never answered by an agent. This value is calculated by subtracting the Answered calls from the Received calls, and then dividing that value by the number of Received calls. For example, if you received 10 calls and seven were answered, you would subtract seven from 10, leaving three unanswered calls. That value would then be divided by 10, giving you an abandoned call percentage of 30%.
• Transferred calls Total number of Response Group calls that were transferred because of a queue timeout or queue overflow.
In turn, the Response Group Call List Report shows a breakdown of the calls in any one of those categories; for example, on that report you might see information about all the Answered Calls and only the Answered Calls.
Accessing This Report
[pic]
The Response Group Call List Report can be accessed only by clicking one of the following metrics found on the Response Group Usage Report:
• Received calls
• Successful calls
• Offered calls
• Answered calls
• Transferred calls
Making the Best Use of This Report
The Response Group Call List Report allows you to limit the displayed data to calls involving a particular Response Group workflow. To do this, you need to enter the workflow URI (that is, the workflow's SIP address) in the Workflow URI box. Before you can do that, however, you must actually be able to see the Workflow URI box. To display the filtering options for the Response Group Call List Report, click the Show/Hide Parameters button in the upper right corner of the report window:
[pic]
Note that the Response Group Call List does not display information about either the Response code or the Diagnostic ID if you hold the mouse over either of those metrics. If you need more information, you might note the Response code, Diagnostic ID, or both, and then search for those values in the Top Failures Report.
Unlike the Response Group Usage Report, the Response Group Call List Reports does list workflow URIs. That means that, if you would like to know the answer to a question like, "Which individual workflow received the most calls?", you might do the following:
1. On the Response Group Usage Report, set the time period that you want, and then click the Received calls metric. That will open the Response Group Call List Report.
2. Export the data shown on the Response Group Call List Report. You might export the data in Excel format and then use Excel to convert that data to a CSV file.
3. Run your analyses using Windows PowerShell.
For example, if you have saved the data to a file named C:\Data\Response_Group_Call_List_Report.csv, you can then use the following command to return the total number of received calls for each workflow listed in the report:
$calls = Import-Csv -Path "C:\ Data\Response_Group_Call_List_Report.csv"
$calls | Group-Object Workflow | Select-Object Count, Name | Sort-Object Count –Descending
That should return information similar to this:
Count Name
----- ----
160 Redmond Help Desk
47 Dublin Help Desk
31 North America Customer Support
16 EMEA Customer Support
14 Employment Opportunities
Response Group Usage Report
[pic]
Overview
As noted, the Response Group application provides a way for Lync Server to answer and route phone calls based on the number that was dialed and, optionally, on the caller's responses to a series of questions. Typically, Response Group calls are not routed to an individual person but, instead, are routed to a team of people referred to as an agent group. For example, if someone calls the phone number for your help desk, Lync Server can automatically route that call to the first available help desk agent; alternatively, Lync Server could ask a series of questions ("Press 1 if you are having hardware problems. Press 2 if you are having software problems. Press 3 if you are having network problems.") and then route the call to the most appropriate help desk agent based on the answer to those questions.
The Response Group Usage Report provides a detailed look at the number of phone calls received by all your Response Group workflows and then breaks down those calls into more finite categories such as Offered calls, Answered calls, and Abandoned calls.
As you might expect, then, the key to working with the Response Group Usage Report is to understand the difference between the reported call types:
• Received calls The total number of calls received by all instances of the Response Group.
• Successful calls The total number of calls that were picked up by the Response Group.
• Offered calls The total number of calls that were transferred to a Response Group agent.
• Answered calls The total number of calls that were actually answered by a Response Group agent.
• Percentage of abandoned calls The percentage of calls that were received by the Response Group but were never answered by an agent. This value is calculated by subtracting the Answered calls from the Received calls, and then dividing that value by the number of Received calls. For example, if you received 10 calls and seven were answered, you would subtract seven from 10, leaving three unanswered calls. That value would then be divided by 10, giving you an abandoned call percentage of 30%.
• Transferred calls Total number of Response Group calls that were transferred because of a queue timeout or queue overflow.
If you are looking at the Response Group Usage Report and can't remember the definition for any of these call types, simply hold your mouse over the appropriate call type label. A tooltip will appear that offers a brief description of the call type.
The Response Group Usage Report allows you to filter on a workflow URI (the SIP address associated with that workflow). However, workflow URIs do not actually appear on the report itself. If you would like to know things such as which workflows are answering the most calls or which workflows are experiencing the most transferred calls, click the appropriate metric to open the Response Group Call List Report for that given time period. That reports does list the workflow URIs.
Accessing This Report
[pic]
The Response Group Usage Report is accessed from the Monitoring Server Reports home page. From the Response Group Usage Report, you can drill down to the Response Group Call List Report by clicking any of the following metrics:
• Received calls
• Successful calls
• Offered calls
• Answered calls
• Transferred calls
Making the Best Use of This Report
One of the more interesting uses of the Response Group Usage Report might not be readily apparent: the ability to retrieve usage information for a single Response Group workflow.
Note. At this point, we should probably clarify what we mean when we talk about a “Response Group workflow.” A Response Group workflow is basically a set of instructions that determines what Lync Server does when a user dials a particular phone number. To that end, each workflow is uniquely associated with a phone number; when someone calls that number, the workflow determines how the call will be handled. For example, we mentioned that the workflow might cause the call to be routed to a series of interactive voice response (IVR) questions that prompt the caller to enter additional information (for example, "Press 1 for hardware support. Press 2 for software support."). Alternatively, the workflow might cause the call to be placed in a queue with the caller put on hold until an agent is available to answer the call. The availability of agents to answer calls is also dictated by the workflow; workflows are used to configure both business hours (the days of the week and the times of day when agents are available to answer calls) and holidays (days when no agents are available to answer calls). Any time you dial a phone number that belongs to the Response Group, you are essentially calling a Response Group workflow.
Although workflow URIs do not appear in the Response Group Usage Report, it's still possible to view the usage statistics for a single workflow. Why would you want to do that? Here's one example. Suppose you recently unveiled a new advertising campaign and are curious to know whether people are calling in to ask about the advertised product. If you have associated a Response Group workflow with the phone number given in the advertisements, you can easily check to see how many people (if any) are calling that number.
You might also use a similar approach to gauge the number of calls being handled by your internal help desk or your customer service department.
To review usage statistics for a particular workflow, all you need to do is enter the workflow URI in the Workflow URI box. That's the tricky part: as noted, workflow URIs (the SIP address associated with a workflow) do not appear on the report. That means you need to find some other way to determine the URI of a workflow. One of these alternate methods is to use Windows PowerShell and the Lync Server Management Shell. For example, this command returns the URIs for all your Response Group workflows:
Get-CsRgsWorkflow | Select-Object Name, PrimaryUri
That will return data similar to this:
Name PrimaryUri
---- ----------
Customer Support sip:support@
Help Desk sip:helpdesk@
New Ad Campaign sip:newads@
This command returns information for a single workflow, the one with the name New Ad Campaign:
Get-CsRgsWorkflow -Name "New Ad Campaign" | Select-Object Name, PrimaryUri
Call Diagnostic Summary Report
[pic]
Overview
The Call Diagnostic Summary Report provides an overall look at failed peer-to-peer and conferencing sessions. The report shows the overall failure rate for both types of sessions and further breaks the failure information down by session modality type:
• Instant messaging
• Application sharing
• File Transfer
• Audio
• Video
Accessing This Report
[pic]
The Call Diagnostic Summary Report is accessed from the Monitoring Server Reports home page. From the Call Diagnostic Summary Report, you can access the Peer-to-Peer Activity Diagnostic Report by clicking the Failure rate metric under the Peer-to-Peer Session Summary section of the report. You can also access the Conference Diagnostic Report by clicking any of the following conference metrics:
• Overall session failure rate
• Focus failure rate
• MCU failure rate
Making the Best Use of This Report
The Call Diagnostic Summary Report includes graphs that compare failure rates for the various modalities used in Lync Server:
[pic]
As it turns out, the columns in these graphs are actually links; for example, if you click the Instant messaging column for peer-to-peer sessions, you'll drill down to an instance of the Peer-to-Peer Activity Diagnostic Report, a report that provides additional details about all the IM sessions included in the Call Diagnostic Summary Report.
Conference Diagnostic Report
[pic]
Overview
The Conference Diagnostic Report provides information about the success and failure of all conferencing sessions. Note that Lync Server distinguishes between different kinds of failure:
• Expected failure An expected failure is typically a failure only in the most technical sense. For example, suppose someone starts a conference but hangs up before anyone can join. Technically that's a failure: the conference was initiated but not completed. However, that's a failure that you would expect to happen: if the organizer cancels the conference before anyone can join, then you would not expect that conference to be completed.
• Unexpected failure An unexpected error is exactly what the name implies: an error that, based on the circumstances, you would not expect to occur. For example, suppose a conference could not be held because the organizer's meeting policy could not be retrieved. That's an unexpected error; after all, you should always be able to retrieve a user's meeting policy.
Note that the Success, Expected failure, and Unexpected failure metrics might not add up to the Total sessions metric. For example, you might see the following values in the report:
|Successes |Expected failures |Unexpected failures |Total sessions |
|3956 |142 |1 |4099 |
If you add 2,024 + 469 + 16 you get a total of 2,509 sessions and yet, the Total sessions column shows a total of 2,521 sessions. What are the extra 12 sessions for (2,521 - 2,509)?
Those are sessions that the system was unable to categorize as successful or unsuccessful. That will sometimes be the case with calls involving a Microsoft® Office Communications Server 2007 R2 client: those calls cannot always be categorized as being a Success, an Expected failure, or an Unexpected failure.
Accessing This Report
[pic]
The Conference Diagnostic Report is accessed from the Monitoring Server Reports home page. From the Conference Diagnostic Report, you can access the Failure Distribution Report by clicking either of the following metrics:
• Unexpected failure volume
• Expected failure volume
Making the Best Use of This Report
The Conference Diagnostic Report includes a series of graphs similar to this:
[pic]
Each of the columns shown in the graph is actually a link; if you click a column, you'll drill down to the Failure Distribution Report for that time period and that conference type.
Diagnostic Report
[pic]
Overview
The Diagnostic Report provides diagnostic and troubleshooting information for a failed session. This information includes both the Diagnostic ID and the Diagnostic header that were reported when the session failed. The Diagnostic ID is a unique identifier (in the form of an ms-diagnostics header) that gets attached to a SIP message, while the Diagnostic header provides an accompanying description for the Diagnostic ID.
Accessing This Report
[pic]
The Diagnostic Report can be accessed by clicking the Diagnostic Report (Detail) metric on either the Peer-to-Peer Session Detail Report or the Conference Detail Report.
Making the Best Use of This Report
To be honest, there isn't much you can do with the Diagnostic Report other than read it. If you hold your mouse over the Diagnostic ID a description of the ID will be displayed in a tooltip. However, that description is identical to the reason in the Diagnostic header, which makes the tooltip not all that useful.
Failure Distribution Report
[pic]
Overview
The Failure Distribution Report ranks failed sessions in the following categories:
• Top diagnostic reasons
• Top modalities
• Top pools
• Top sources
• Top components
• Top from users
• Top to users
• Top from user agents
These categories can help you determine exactly where a problem is occurring (and, in some cases, why that problem is occurring). For example, suppose you recorded 242 failed A/V sessions during a given day. If you look at the Failure Distribution Report, it might show that 237 of those failed sessions took place in your Dublin pool. This gives you a good place to start when it comes to tracking down and diagnosing the causes behind those failures. In fact, if you click the Dublin pool under the Top pools category, you will see a Failure Distribution Report just for that pool. You can then begin analyzing why the Dublin pool was experiencing so many difficulties.
Accessing This Report
[pic]
The Failure Distribution Report can be accessed from any of the following reports by clicking either the Expected failure volume or the Unexpected failure volume metric in the:
• Top Failures Report
• Conference Diagnostic Report
• Peer-to-Peer Activity Report
From the Failure Distribution Report, clicking any of these metrics will take you to the Failure List Report:
• Top diagnostic reasons (sessions)
• Top modalities (sessions)
• Top pools (sessions)
• Top sources (sessions)
• Top components (sessions)
• Top from users (sessions)
• Top to users (sessions)
• Top from user agents (sessions)
Making the Best Use of This Report
Depending on your monitor size and screen resolution, it's possible that some of the data shown in the Failure Distribution Report might be truncated when viewed on your screen; this is especially true for metrics such as user agents, which can have very long labels. For example, a user agent with a name like UCCAPI/4.0.7400.0 OC/4.0.7400.0 (Microsoft Communicator 2010 (Beta Refresh) might be only partially displayed onscreen:
UCCAPI/4.0.7400.0 OC/4.0.7400.0 (Microsoft Communicator 2010 (Beta ...
Fortunately, you can see the entire label simply by holding your mouse over the truncated value. For example:
[pic]
One interesting metric that you can filter on by using the Failure Distribution Report is the Diagnostic ID. If you see the same Diagnostic ID cropping up in other reports, you can filter on that ID in the Failure Distribution Report and get a very detailed look at exactly where and how often that ID has been reported during a failed session.
Failure List Report
[pic]
Overview
The Failure List Report provides information about the individual participants who took part in a failed peer-to-peer or conferencing session. This information includes the URI of the user who experienced the problem and also the SIP Response code and Diagnostic ID associated with the failure.
Accessing This Report
[pic]
The Failure List Report is accessed by clicking any of the following metrics on the Failure Distribution Report:
• Top diagnostic reasons (sessions)
• Top modalities (sessions)
• Top pools (sessions)
• Top sources (sessions)
• Top components (sessions)
• Top from users (sessions)
• Top to users (sessions)
• Top from user agents (sessions)
From the Failure List Report you can access the Peer-to-Peer Session Detail Report by clicking the Session detail metric for a peer-to-peer session. You can also access the Conference Detail Report by clicking the Conference metric for a conference.
Making the Best Use of This Report
In the Failure List Report, you can view a description for each Response code or each Diagnostic ID simply by holding your mouse over that value. For example, if you hold your mouse over Diagnostic ID 7025, you'll see the following displayed in a tooltip:
Internal server error creating media for user.
It's important to note that the Failure List Report does not provide a straightforward way to directly retrieve a list of all the users who participated in at least one failed session, nor does it provide a way to determine which users were most-often involved in a failed session. (For one thing, the Failure List Report has no filtering capabilities.) However, if you export the data and then convert it to a CSV file, you can use some Windows PowerShell commands to find the answers to questions like those. For example, suppose you save the data to a CSV file named C:\Data\Failure_List.csv and then use the following command. Based on the data saved in that file, this command lists all the users who were involved in at least one failed session:
$failures = Import-Csv –Path " C:\Data\Failure_List.csv"
$failure |Sort-Object "From user" | Select-Object "From user" –Unique
That command will return a list similar to this:
From user
----
Pilar.Ackerman@
Henrik.Jensen@
Gilead.Almosnino@
David.Ahs@
Ken.Myer@
These two commands report back the total number of failed sessions that each user was involved in:
$failures = Import-Csv –Path "C:\Data\Failure_List.csv"
$failures | Group-Object "From user" | Select-Object Count, Name | Sort-Object -Property Count –Descending
That will return data similar to this:
Count Name
----- ----
20 Pilar.Ackerman@
20 David.Ahs@
16 Gilead.Almosnino@
16 Ken.Myero@
14 Henrik.Jensen@
Media Quality Metrics Distribution Report
[pic]
Overview
The Media Quality Metrics Distribution Report enables you to see a graph that shows the distribution values for a QoE metric such as jitter or packet loss. To explain what that means, imagine a scenario such as this one: your users make a total of 10 phone calls; these 10 calls report the following round-trip times:
|Call number |Round-trip time (in milliseconds) |
|1 |50 |
|2 |50 |
|3 |50 |
|4 |50 |
|5 |50 |
|6 |50 |
|7 |50 |
|8 |4550 |
|9 |50 |
|10 |50 |
If you average those round-trip times, you'll come up with 500 milliseconds (5,000 divided by 10). Five hundred milliseconds is an extremely long round-trip time. As a result, you might believe that you have a serious problem with network congestion. (Long round-trip times are typically the result of overloaded networks.)
In reality, of course, 90% of your calls had excellent round-trip times; you simply had one extremely bad call that skewed the overall results. If you look only at the average round-trip time, you might jump to a very wrong conclusion.
The Media Quality Metrics Distribution Report helps you avoid jumping to wrong conclusions by showing you a graphical distribution of a specified metric (such as the round-trip time). If you looked at a graph of your phone calls, you would see that round-trip times are distributed like this:
[pic]
A graph like the preceding one makes it clear that you had nine very good calls and one very bad call. You might still want to further investigate that one call; however, the fact that nine out of the 10 calls were very good suggests that there is no reason to make any drastic changes to your network, at least not at this point in time.
Accessing This Report
[pic]
The Media Quality Summary Report is accessed from the Monitoring Server Reports home page. From the Media Quality Summary Report you can access the Call List Report by clicking either of the following metrics:
• Call volume
• Poor call percentage
You can also access the Media Quality Metrics Distribution Report by clicking any of the following metrics:
• Round trip (ms)
• Degradation (ms)
• Packet loss
• Jitter (ms)
• Healer concealed ratio
• Healer stretched ratio
• Healer compressed ratio
Making the Best Use of This Report
The Media Quality Metrics Distribution Report shows you graphs similar to this:
[pic]
The preceding figure shows the default view; admittedly, this default view will sometimes result in a graph that's difficult to read. Fortunately, the report makes it possible for you to zoom in on these metrics by changing the values displayed on the round trip (x) axis. For the round-trip report, the x-axis runs from 0 milliseconds to 100 milliseconds. However, by changing those values to 5 and 20 you get a graph that looks like this:
[pic]
To change the values shown on the x-axis, click the Show/Hide Parameters button to display the filtering options, and then enter the appropriate values in the Minimum in x Axis and Maximum in x Axis boxes. For example, to shows values between 5 and 20 milliseconds, set those filter options to the following:
|Filter option |Value |
|Minimum in x Axis |5 |
|Maximum in x Axis |20 |
Here's another tip for using the Media Quality Metrics Distribution Report: although it's easy to overlook, this report also links directly to the Call List Report:
[pic]
Peer-to-Peer Activity Diagnostic Report
[pic]
Overview
The Peer-to-Peer Activity Diagnostic Report provides information about the success and failure of your peer-to-peer communication sessions. As noted earlier, Lync Server distinguishes between different kinds of failure:
• Expected failure An expected failure is typically a failure only in the most technical sense. For example, suppose you call someone, but he or she is away from the office and unable to answer the phone. Because the call was not answered, the call is technically considered a failure. On the other hand, this was an expected failure: Lync Server does not expect you to answer the phone if you're not available to answer the phone.
Sometimes expected failures are due to an administrator’s action. For example, if you temporarily pause the IM service, any attempt to send an instant message while the service is paused will result in an expected failure. In other cases, user education might help you reduce the number of expected failures. For example, if users learn to first check a person's status and not attempt to make a phone call unless that person is available, then your number of 52,116 "Remote participant not available" errors should decrease.
• Unexpected failure An unexpected error is exactly what the name implies: an error that, based on the circumstances, you would not expect to occur. For example, suppose you call someone and that person tries to put you on hold; when they do so, you are dropped from the call. That's an unexpected error: the system should not hang up on you any time you're placed on hold. As a general rule, unexpected failures are true failures: they are problems that likely cannot be remedied through user education or similar measures.
We mentioned earlier that the Success, Expected failure, and Unexpected failure metrics might not add up to the Total sessions metric. This is because there might be sessions that the system was unable to categorize as successful or unsuccessful, which will sometimes be the case with calls involving an Office Communications Server 2007 R2 client: those calls cannot always be categorized as being a Success, an Expected failure, or an Unexpected failure.
For example, in the preceding figure, we have the following values:
|Successes |Expected failures |Unexpected failures |Total sessions |
|2024 |469 |16 |2521 |
If you add 2,024 + 469 + 16 you get a total of 2,509 sessions and yet, the Total sessions column shows a total of 2,521 sessions. What are the extra 12 sessions for (2,521 - 2,509)?
Accessing This Report
[pic]
The Peer-to-Peer Activity Diagnostic Report is accessed from the Monitoring Server Reports home page. From the Peer-to-Peer Activity Diagnostic Report, you can access the Failure Distribution Report by clicking either of the following metrics:
• Unexpected failure volume
• Expected failure volume
Making the Best Use of This Report
There are actually a number of ways you can filter the Peer-to-Peer Activity Diagnostic Report, but, by default, those filtering options are hidden from view. To view the filtering options available to you, click the Show/Hide Parameters button in the upper right corner of the report window:
[pic]
After you do that, the filtering options will be available for use:
[pic]
Server Media Quality Trend Report
[pic]
Overview
The Server Media Quality Trend Report provides a way for you to graphically compare up to five servers on QoE metrics such as call volume, poor call percentage, packet loss, and jitter. This makes it easier to do things such as identify servers that are performing poorly, identify servers that are underused, or identify servers that are being overused.
Accessing This Report
[pic]
The Server Media Quality Trend Report can be accessed from either one of the following reports:
• Server Performance Report (by clicking the Trend metric)
• Call Detail Report (by clicking the A/V Edge server metric)
Making the Best Use of This Report
When you click the Trend metric on the Server Performance Report for a specific server, the Server Media Quality Trend Report will open. However, because of an issue in the reports, you will see only a blank instance of that report; the server you selected in the Server Performance Report will not be displayed on your screen. Instead, you will need to select that server from the Servers drop-down list. Note that the Servers drop-down list includes a Select All option. This option will not work if you have more than five servers; the Server Media Quality Trend Report can display data only for a maximum of five servers at a time.
The Server Media Quality Trend Report includes a series of graphs similar to this:
[pic]
For both Call Volume and Poor Call Percentage the individual points on these graphs are inks; clicking a point on the graph will open an instance of the Call List Report showing the total calls (or poor calls) for the specified time period.
Server Performance Report
[pic]
Overview
The Server Performance Report provides a list of Lync Servers that have experienced the highest-percentage of poor calls. The report breaks down servers by server type, reporting separate statistics for the following types:
• Mediation Server
• A/V Conferencing Server
• A/V Edge Server
• Gateway (Mediation Server)
• Gateway (Mediation Server bypass)
It’s important to note that the rankings shown in this report are relative rankings. What does that mean? Well, suppose your worst-performing server had one poor call among its 1,000 placed calls. That's a percentage of .1%. However, if that's the worst-performing server you have (that is, if all your other servers have a poor call percentage even lower than .1%), then that server will still appear on the Server Performance Report. That simply means that you must always concern yourself with the actual poor call percentage and the call volume; don’t assume that a server is performing poorly just because it appears on this report.
Accessing This Report
[pic]
The Server Performance Report is accessed from the Monitoring Server Reports home page. From the Server Performance Report, you can drill down to the Call List Report by clicking either of the following metrics:
• Call volume
• Poor call percentage
In addition, you can drill down to the Server Media Quality Trend Report by clicking the following metric:
• Trend
Making the Best Use of This Report
The Server Performance Report provides a number of ways to filter data; for example, you can filter on network type (calls made from a wired connection versus calls made from a wireless connection) and access type (calls made from inside the firewall versus calls made from outside the firewall). It's a good idea when viewing the server performance report to make use of these filters. For example, when testing the Monitoring Server Reports for the purpose of this document, we had a Mediation Server that barely made the list with a poor call percentage of 3.24%. However, when we looked solely at wireless calls, that same server jumped to the top of the list with a poor call percentage approaching 20%. Obviously the server was having difficulty with wireless calls. However, that problem was partially obscured because it was not having problems with wired calls, and it handled far more wired calls than wireless ones.
Top Failures Report
[pic]
Overview
The Top Failures Report provides a look at the most-commonly reported failures and their trends over time. Failures are based on a combination of the following two metrics:
• Diagnostic ID The unique identifier (in the form of an ms-diagnostics header) that is attached to a SIP message. Diagnostic IDs often provide information that is useful in troubleshooting call-related problems.
• Response code The code used in SIP communication sessions to respond to a SIP request. For example, suppose Ken Myer sends the INVITE request to Pilar Ackerman (that is, suppose Ken Myer calls Pilar Ackerman). If Pilar answers, her phone will send the response code 200 (OK), letting Ken's phone know that Pilar has answered. The Top Failures Report includes only response codes that were sent in response to a call failure. Monitoring Server does not keep track of all the response codes issued during the course of a call.
For example, you might have the following two entries for Diagnostic ID 3173:
|Diagnostic ID |Response Code |
|3173 |200 |
|3173 |400 |
The same Diagnostic ID but a different response code.
Information is reported not only for the total number of sessions where a failure occurred but also for the total number of users who were impacted by the failure.
Accessing This Report
[pic]
The Top Failures Report is accessed from the Monitoring Server Reports home page. Clicking the Reported sessions metric will take you to the Failure Distribution report.
Making the Best Use of This Report
The Top Failures Report is unusual in at least one regard: it lets you filter on as many as five diagnostic IDs at once. (Typically you can filter only on one item—such as one user SIP address—at a time.) To filter on multiple diagnostic IDs, simply enter each ID in the Diagnostic IDs box, separating the IDs by using commas. (If you want to, you can leave a blank space after each comma.) For example:
1011, 2412, 1033, 52116, 1008
Do that, and only failed calls that reported at least one of those five diagnostic IDs will be displayed.
Here's another tip: if you hold your mouse over a Response code, you'll see a tooltip that tells you what that Response code means. For example, if you hold the mouse over the Response code 486 you'll see this message:
Busy Here.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- free marketing plan template microsoft word
- microsoft minecraft education
- microsoft excel 2010 user guide
- find my microsoft password please
- microsoft minecraft education download
- minecraft microsoft edition download
- microsoft word double sided page
- download microsoft office onenote 2016
- microsoft crm dynamics
- microsoft loan calculator
- microsoft dynamics crm features list
- microsoft excel coupon