Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
This article highlights the ways in which Microsoft Lync Server 2010 Monitoring/Archiving server improves data transmission using Microsoft Message Queuing (MSMQ).
Authors: Weiming Shen, Xu Liu, and Clark Chen
Publication date: May 2011
Product version: Lync Server 2010
The Microsoft Lync Server 2010 Monitoring/Archiving server offers several improvements that enhance the reliability of data transmission using Microsoft Message Queuing (MSMQ). In Microsoft Office Communications Server 2007 R2, messages were occasionally dropped if those messages could not be delivered or processed due to network issues or delivery expiration timeouts. With Lync Server, we retain these messages and attempt to deliver them after the blocking issues have been resolved. In addition, we also provide a manageable way to raise warning events before messages might be dropped (for reasons such as MSMQ running out of disk space). As a result, administrators have the opportunity to resolve the issue and avoid data loss in such cases.
The following illustration shows how Monitoring/Archiving server use MSMQ to interact with the Lync Server Front End servers:
In Office Communications Server 2007 R2, messages for Archiving, Call Detail Recording (CDR), and Quality of Experience (QoE) were delivered in a straightforward fashion. Each message was stamped with an expiration time (the TIME_TO_REACH_QUEUE setting) before being delivered to MSMQ. If the message could not be delivered to the Archiving or Monitoring server before the expiration time, the message was dropped by the MSMQ service and never written to the database. In addition, messages received by the target queue were marked with a second expiration time (the TIME_TO_BE_RECEIVED setting). If the message was not retrieved from the target queue before that expiration time, that message would be dropped, even though it had been delivered to the target queue before the TIME_TO_REACH_QUEUE setting expired. These expiration times were required because Front End servers had limited resources, and we wanted to have an automated way to purge messages when something went wrong, and without interfering with the messaging process.
With this approach, there were several scenarios in which processing could fail and messages would be dropped:
These issues can also lead to a problem with the Critical mode feature supported in Office Communications Server 2007 R2, the optional feature that shuts down the messaging system if messages cannot be archived. In Office Communications Server 2007 R2, it might take several hours before the system realizes that messages are accumulating in the target queue and expiring before they can be written to the database. That means that several hours' worth of data might be lost before the system shuts itself down. That could be a serious problem for organizations that are required by law to keep a copy of all electronic communications.
These issues are primarily due to limitations in data transmission reliability in Office Communications Server 2007 R2 monitoring and archiving. Because of that, we have introduced several major improvements in Lync Server 2010:
The following diagram illustrates the improvements made to archiving and CDR in Lync Server 2010. Note that these enhancements do not necessarily apply to QoE; that's because QoE messages are typically not considered mission critical and, as a result, can be dropped in certain scenarios.
The following table shows the set of new features supported by each monitoring component:
Queue health monitoring
Dead letter queue
Many of these features can be customized by modifying registry values found under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RtcSrv\Parameters. These configurable values are listed in the following table:
Amount of quote space that must be used before the initial low disk space warning is sent.
Amount of quote space that must be used before subsequent low disk space warnings are sent.
Amount of time between system heartbeat checks.
Amount of time the system waits before checking the dead letter queue.
Amount of time between quota disk space checks.
Amount of time it takes for a heartbeat message to reach the target queue.
Amount of time it takes a heartbeat message to be received and processed.
Amount of time it takes for a data message to reach the target queue.
Amount of time it takes a data message to be received and processed.
Any changes made to these registry values will not take effect until the Front End service is restarted. Be careful when making these changes, as an improper configuration could lead to data loss.