Microsoft Lync and Skype for Business have a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use those APIs.

Fix for long delay when scheduling many conferences in UCMA

Posted: October 30th, 2013 | Author: | Filed under: UCMA 4.0 | Tags: , , | No Comments »

The Lync Server 2013 cumulative update back in July fixed a potentially serious issue with conference scheduling. The main symptom of the issue is long delays when scheduling many Lync conferences simultaneously – it can take around two minutes per conference, rather than a few seconds as you would expect. I wanted to write up a quick explanation here for anyone who runs into this issue when building UCMA applications. 

In normal Lync Server usage outside of third-party applications, it’s quite rare for many Lync conferences to be scheduled at once. There are a few reasons for this. Most people’s settings in the Lync Outlook add-in reuse the same conference for all of the Lync meetings scheduled through Outlook. (This is the default setting.) This means that for the most part the only time the Lync client schedules a new conference is when an “ad hoc” conference is created, either through the “Meet Now” option in the Lync client or through adding a third participant to a two-party call. While this can happen frequently in large Lync environments, it’s extremely rare outside of application scenarios for tens of conferences to be scheduled within a few seconds on the same Front End pool.

Many advanced UCMA applications, though, make extensive use of conferences for call control. This allows services like recording or attendants to be delivered to the call. In some cases, applications may even create a large number of conferences at once in order to maintain a sort of “reserve pool” of conferences. Because of this, UCMA applications can easily trigger this delay in Lync Server 2013 environments where the cumulative updates have not been installed.

The knowledge base article on the issue has more details. Apparently the delay is caused by a deadlock that occurs on one of the database tables used for conference data when multiple conference scheduling requests arrive from the same user: a rarity in normal Lync operations, as I’ve just explained.

So if you notice long delays when scheduling conferences from your UCMA application, make sure that the latest cumulative update has been applied to all of the servers in your Lync environment, and this should resolve the problem.

Leave a Reply

  • Note: Comment moderation is in use because of excessive spam. Your comment may not appear immediately.