Getting Started with Monitoring

in Lync 2010

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.

Microsoft,Microsoft, Lync, and SQL Serverare 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.

Microsoft Corporation 1

Contents

Introduction

What is Monitoring Server, and What Is Monitoring Server Reports?

How Do VoIP Networks Work, and Why Should I Care About That?

How Do I Monitor VoIP Traffic?

What Should I Look for When Monitoring VoIP Calls?

Poor Call Percentage

Round Trip

Degradation (MOS)

Packet Loss

Jitter

What Does It Mean to Monitor for Usage?

Introduction

One feature that you'll find in any modern car is a dashboard. (At least we assume that all modern cars have dashboards.) Dashboards typically contain all kinds of gauges, dials, and other instruments that provide information about a car and how well that car is performing. Some of these instruments are designed to run at all times and to keep a running tally of the car's current performance. For example, the speedometer tells you how fast you're driving, and the gas gauge tells you how much gas is left in the gas tank. Other instruments make their presence known only on an as-needed basis. You say you just looked at the dashboard and you don't see the Low Oil Pressure warning light? That's good: that means that you are not running low on oil.

Setting aside any legal requirements, there isn't any reason why your car has to have a speedometer or a gas gauge; if you don't have a speedometer or a gas gauge your car will run just fine. However, your driving experience will be a less-than-optimal one. Why? Because while it might seem like everything is fine, you'll never really know for sure. It might seem like you're staying below the speed limit, but how can you be sure? It might seem like you have enough gas to make it to work and back, but how can you be sure? No matter how well things might seem to be going, there will always be a certain amount of anxiety and uneasiness. And anxiety and uneasiness don't translate to an optimal driving experience.

Real-time performance data, like your current speed or the current amount of gas in the gas tank, is useful; so, too is long-term data about how your car is being used. For example, tires should be changed every 40,000 miles. Yes, there's no substitute for checking your tire tread when deciding whether you need new tires. However, knowing how many miles you've driven can give you some idea of how carefully, and how often, you should check the tire tread. You say you've driven only 5,000 miles on these tires? Then your tires probably don't need to be a major concern. But if it has been 48,000 miles since your last tire change, well, that's a different story. And you won't know that unless you have usage data that tells you that the car has been driven for 48,000 miles.

Here's another reason why cars have dashboards. Suppose you're out driving and something bad does happen. A well-designed dashboard and instrumentation system won't necessarily prevent problems from happening—if a water pump is going to fail, then that water pump is simply going to fail. However, many times a warning light can help minimize damage and help prevent a minor problem from becoming a major problem. For example, the Low Oil Pressure warning light doesn't come on only after your car has used up all its oil and is now on fire by the side of the road. Instead, the Low Oil Pressure warning light comes on before you run out of oil. It comes on when you still have enough oil to safely make it to the next gas station. Having to stop and buy a quart of oil is an inconvenience. Having to bail out of a burning car while traveling down the highway is something more than an inconvenience.

In other words, the instruments on your dashboard can help prevent a minor problem from turning into a major problem: if the Low Oil Pressure light comes on, then you should add oil to the car. That's useful to help you finish your current trip and to get from here to there. In addition, if you pay close enough attention to these warnings, they can also help you distinguish between a one-time anomaly and a real problem. Did you simply forget to put oil in the car this time around? That's fine: the Low Oil Pressure warning light comes on, you add oil, and the problem is resolved. But suppose the Low Oil Pressure warning light comes on again next week and then the week after that. A car that's working properly shouldn't require an oil change every week.

No matter what your car salesperson might tell you.

So what does all this have to do with Microsoft® Lync™Server2010 communications software? Needless to say, cars are complex pieces of machinery, cars cost money, and a broken car can cause problems not only for you but for other people as well (like family members or the people in your carpool). These reasons explain why it's a good idea to use the instrumentation on the dashboard to routinely monitor your car for both usage and performance and to respond promptly any time one of these instruments suggests there might be a problem somewhere.

As for LyncServer2010, Lync Server is a complex product, probably even more complex than a car. Lync Server costs money, and a broken deployment of Lync Server can cause problems not only for you but for other people as well (like all the people in your organization who depend on Lync Server for phone service, instant messaging, conferencing, and other communication needs). These reasons explain why it's a good idea to routinely monitor Lync Server for both usage and performance and to respond promptly any time there's the slightest hint that there might be a problem somewhere.

That's a reasonably good analogy, but, at first glance, therewould appear to be one major flaw in it. After all, it's easy to monitor usage and performance in your car: all cars come equipped with a dashboard, and all dashboards come equipped with instruments designed to monitor usage and performance. But what do any of those things have to do with Lync Server?

The fact that you're asking that question can only mean one thing: it's time to discuss Monitoring Server and Monitoring Server Reports.

Note. 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.

What is Monitoring Server, and What Is Monitoring Server Reports?

Monitoring Server is a Lync Server server role designed to collect usage information and Quality of Experience (QoE) data about the communication sessions that your users are involved in.

Note. We should clarify from the start that Monitoring Server keeps track of information about each session: who contacted who, which endpoints were used in the session, how long did the session last, what was the perceived quality of the session, and so on. However, Monitoring Server does not record and store the actual session itself. This is true for calls and also for instant messaging (IM) sessions: although Monitoring Server records information about IM sessions, it does not maintain a record of each instant message that was sent during the session. That's the job of Archiving Server, a server role not discussed in this document.

Monitoring Server is built around the fact that SIP-compliant endpoints (including software programs, such as Microsoft® Lync™2010, and hardware devices, such as an IP phone) automatically keep track of information during a call. This information includes:

End-to-end metrics End-to-end metrics deal with the actual transmission of the call itself; that is, they provide a sort of travel log as the call journeys across the network. These metrics (which include things such as packet loss, jitter, and round-trip times, all of which will be explained later in this document) provide information about what happened to the call from the time it left your phone to the time it arrived at the other person's phone. What these metrics don't do is describe things such as whether the other person was hard to hear or whether there was excessive noise on the line. That information is conveyed by the endpoint metrics.
Endpoint metrics Endpoint metrics enable you to determine what the call sounded like to each person involved in the call. Was it hard to pick out the other person's voice over the background noise? Could you hear an echo of your own voice every time you talked? Did it sound like the beginning and ending of sentences were cut off? Endpoint metrics often deal with hardware issues (that is, problems with your speaker or microphone) or with environmental issues (like having multiple phones involved in a call that are located too close to one another).
Configuration parameters Configuration parameters relay basic information about each endpoint involved in the call, including IP address, link speed, the Edge Server used in the call, and so on.
Event ratios To be honest, we aren't sure where the term "event ratios" came from. We do know that event ratios report back diagnostic IDs, SIP response codes, and other error messages generated during a call. As you might expect, these messages can be extremely useful when trying to diagnose problems that occurred during a call.

At the end of each call, SIP-compliant endpoints automatically transmit this information to the Front End Server that facilitated the call. You don't have to do anything to get endpoints to transmit that information; that behavior is built into SIP. However, if you want to collect and store that information, then you need to install and enable Monitoring Server.

Note. For details about installing Monitoring Server, seeDeploying Monitoring in the Lync Server TechNet Library at

If you do install and enable Monitoring Server, then call information is gathered by agents running on the Front End Server and relayed to the Monitoring Server; that relayed information is then stored in a pair of Microsoft® SQLServer® databases.

And then what? Well, after the data has been stored in the database, administrators who are familiar with writing SQL Server queries can access and analyze the information to help gauge system usage or to troubleshoot call-related problems. That's fine, except that many system administrators might not be able to write the complicated SQL Server queries needed to extract useful information from the monitoring databases.

Fortunately, there's an alternative: administrators can use Lync Server Monitoring Server Reports to perform these same tasks. Monitoring Server Reports (which ships with Lync Server) uses the SQL Server Reporting Service to provide administrators with predefined reports that cover key topics such as:

The number of users who log on to Lync Server and how many of those users actually use the system after they have logged on
The total number of IM sessions and conferences held in the organization
Quality ratings for phone calls and conferences
Inventory-type information regarding the IP phones and hardware devices in use in the organization

The individual reports included in Lync Server Monitoring Server Reports are discussed in more detail in the document Understanding the Monitoring Server Reports, also in this download package. Instead of giving you that level of detail, this document provides more general information about why you might want to monitor in the first place (actually, why you do want to monitor) and what you should monitor for. In doing so, this document tries to answer the following questions:

How do Voice over Internet Protocol (VoIP) networks work, and why should I care about that?
How do I monitor VoIP traffic?
What should I look for when monitoring VoIP calls?
What does it mean to monitor for usage?

How Do VoIP Networks Work, and Why Should I Care About That?

When it comes to conducting voice calls, the public switched telephone network (PSTN)—or what we tend to think of as the "regular old" phone network of landlines and cell phones—has a number of advantages over a VoIP program such as Enterprise Voice. For one thing, the PSTN network is an example of a "connection-oriented network." That means that, when you pick up the phone and place a call, the route that the call will take has been predetermined for you. Not only that, but when you make a call on the PSTN network, a circuit is reserved for you, and you are automatically allocated all the resources (such as bandwidth) needed for you to complete the call and carry out your conversation. After this circuit has been reserved for you, you do not need to worry about additional network traffic impinging on your call: in general, your call continues regardless of how many other calls are being placed at the same time.

Note. Admittedly, it's possible that there might be times (for example, on Mother's Day) when you try to make a call only to be told that "no circuits are available." In that case, you won’t be able to make your call until someone else hangs up and frees up that circuit and those resources. However, if you are able to make the call, the clarity and the quality of that call will be just as good as if you were the only one in the world currently using the phone.

Does it make a difference that the circuit is predetermined for you the moment you dial a phone number on the PSTN network, and does it make a difference that the PSTN uses a dedicated network for your phone calls? As a matter of fact, it makes a big difference. For one thing, these factors make PSTN phone calls very fast. Because the route has been predetermined, there's never a time when the system has to make a decision about how a call should be routed. As we'll see, the difference between a call with acceptable clarity and one without acceptable clarity is often measured in a matter of milliseconds (a millisecond equals 1/1000th of a second). When it comes to phone calls, faster is always better. And PSTN calls tend to be very fast.

In addition to that, having a dedicated circuit helps to ensure that the words you speak into your phone arrive at their destination in the correct order and in a regular and predictable timeframe. Suppose you say something like this into the phone:

"Hey, how's it going?"