UCMA allows you to join a Lync conference as a so-called “trusted participant,” which has several interesting effects. First, it hides the participant in the conference roster, so that participants can’t see that your application is joined to the conference. Second, it allows your application to perform a variety of privileged operations like changing how audio is routed within the conference. If your application keeps conferences around for a while with trusted participants connected, you may run into a situation where conferences get unexpectedly deactivated by Lync Server. This can lead to confusing state changes, or even cause external participants like PSTN callers to be ejected.
A little background will be helpful here. When a Lync conference is created, it doesn’t get completely started up right away. Only when a participant joins does the conference get “activated” by Lync Server, at which point media begins to flow to and from the MCUs (multi-point control units, the components that mix and distribute media to participants). As more participants join, the MCUs continue to send media back and forth and the conference takes place. At some point, the conference ends. For Lync Server, the trigger for this is when the last authenticated participant leaves the conference. When this happens, Lync Server leaves a short grace period and then “deactivates” the conference, kicking out any remaining participants and stopping the flow of media.
The conference can stay in this sort of hibernation and later be reactivated if participants join again. This is what happens when you schedule a recurring Lync meeting through Outlook. The meeting stays in the deactivated state between occurrences, and is reactivated when someone joins for the next time. Eventually, the conference reaches its expiry time (which you can set in a property on the ConferenceScheduleInformation class) and is deleted, at which point it can’t be reactivated again.
Now, the trouble is that trusted conference participants don’t count for the purpose of preventing conferences from being deactivated. So, if you only have trusted participants and non-authenticated participants in your conference, it’s in danger of being deactivated after the grace period, leading to all participants being kicked out. If this happens in your application, it may appear to be a very mysterious problem – the conferences are seemingly being arbitrarily shut down by Lync Server even though there are still participants! The reason is that the trusted participants won’t prevent the conference from being shut down. There needs to be at least one authenticated, non-trusted participant in the conference to prevent deactivation.
Note that changing the expiry time won’t have any effect on this behaviour. The expiry time controls when the conference is deleted, not when it’s deactivated. You can set your expiry time for years in the future, but if there are no authenticated, non-trusted participants, the conference will still get deactivated. Setting the expiry time far ahead, though, will at least allow you to reactivate the conference easily if it does get deactivated. By the same token, if you want to clean up conference resources quickly after the conferences end and don’t plan to reuse the conferences, you may want to set the expiry time very early. Even if you set the conference to expire within a few minutes, it won’t be shut down and deleted as long as there are still authenticated and non-trusted participants in it.
I hope this helps a few people avoid some very confusing troubleshooting.