Monitoring is a topic that's dear to me, as I'm commonly asked, "Why should I monitor Lync?" This question usually comes up when administrators are deciding on the initial Lync Server 2013 server roles to deploy and the organization is trying its best to scale back on the quantity of servers that's about to deploy. The good thing with Lync Server 2013 is that there isn't a separate Monitoring Server role any more. Instead, the Lync Monitoring functionality is collocated on the Front End Server. In other words, you just need to enable the Monitoring functionality on the Front End Server rather than installing a Monitoring Server role separately on another server or on its own server, as you had to do in previous editions. Let's take a look at the following areas that explain why you should monitor:
- Questions you might be asked with a Lync Enterprise Voice deployment
- What Lync Monitoring brings to the table
- Built-in reports
Questions You Might Be Asked with a Lync Enterprise Voice Deployment
Network terms that are bound to come up in a Lync VoIP deployment are jitter, packet loss, latency, and Mean Opinion Score (MOS), just to name a few. Most Lync administrators aren't used to monitoring and gathering this type of data from the Lync side. This is where Lync Monitoring comes into the picture. Suppose that you just deployed Lync Server 2013 with Enterprise Voice and your manager comes into your office and asks questions such as:
- What time during the day do we have the most conference calls?
- For a certain voice call, was the caller leveraging the VPN or calling from inside the organization?
- What codec was being leveraged for a particular conference call?
- What is the average roundtrip latency for Lync calls?
You don't want to be in a situation where you aren't able to answer your manager's questions.
What Lync Monitoring Brings to the Table
The questions just given are often asked by people who are interested in the quantity or quality of calls taking place in a Lync environment. With its ability to capture reports hourly, daily, weekly, or even monthly, Lync Monitoring is valuable for determining trends, performing analyses, and even troubleshooting Enterprise Voice problems.
With the Lync Monitoring functionality collocated on the Front End Server, you no longer need to worry about collocating it on another server or deploying an additional server for it. You just need to:
- Make sure that SQL Server Reporting Services (SSRS) is installed on the same back-end server that hosts the SQL Server database you want to use for monitoring.
- Enable and configure the Monitoring functionality on the Front End Server.
- Install Lync Server 2013 Monitoring Reports on the back-end server that's hosting SSRS.
When Lync Server 2013 Monitoring Reports is installed, you have access to more than 30 built-in reports. For example, the report in Figure 1 shows the number of conference calls during a 24-hour period. As you can see, the peak conference call times were between 8 a.m. and 10 a.m. and at 1 p.m. for this particular day. By looking at how many conference calls take place each day, you can determine whether additional servers are needed to support conferencing.
Figure 2 displays a media report for a single call that occurred during normal business hours. The purpose of this report is to determine whether the caller and the callee (i.e., the person who was called) were inside the organization (not remote) or not (remote) and whether they were using the VPN. In this case, the report reveals that both the caller and callee were inside the organization and not using the VPN. In addition, the report reveals what protocol (UDP or TCP) the clients leveraged in their communication (in this case, UDP) and the client connectivity path to each other (in this case, the peer-to-peer communication was direct).
Figure 3 shows a report for a conference call between Lync endpoints. The report displays information about the codec used (in this case, G722), jitter, packet loss, and MOS rating. Reports like this are helpful when investigating the quality of conference calls, including any perceived network problems. From the sample report in Figure 3, you can gather that the audio quality of the conference call was pretty good. A key indicator of the audio quality was the MOS rating of 3.19. The MOS rating ranges from 1 to 5, with 1 being the poorest quality and 5 being the highest quality.
Why Not Monitor?
The question that I end up asking myself is, "Why not monitor?" Monitoring in Lync Server 2013 is easier than in previous editions because the Monitoring functionality is collocated on the Front End Server. And the reports I've shown you reveal an important benefit of monitoring: You have increased knowledge and awareness of what your Lync clients are doing in regard to Enterprise Voice. That way, when your manager asks how well Lync Enterprise Voice is performing, you can confidently answer his or her question.