I came across this recently when I had to conduct a bit of a deep dive into how Lync conferences behave when they effectively reach “end of life”. In the first instance, I managed to find this about conference expiration in Office 365:
• For a one-time scheduled meeting, the expiry time is the scheduled end time plus 14 days.
• For a recurring scheduled meeting with an end date, the expiry time is the scheduled end time of the last meeting occurrence plus 14 days.
• For an ad hoc IM or A/V conference, the expiry time is 8 hours.
• For a recurring scheduled meeting without a specified end date, the expiry time is 6 months after the last meeting activation.
To clarify, meeting activation is whenever a conference is accessed by a participant.
These settings apply to Lync on-premises also, but I wanted to know if they could be modified. I knew I’d seen something mentioned about modifying when conferences end, and Brian Ricks reminded me of Set-CsUserServicesConfiguration. With this cmdlet, we can set a parameter -DeactivationGracePeriod that allows us to set the maximum amount of time that a meeting can remain active. However, this was only half of the story.
Deactivation and expiration are related, but different.
Deactivation is when the server will forcefully shut down a meeting. It’s like a server-driven version of the exit-and-end-meeting presenter command. However, you can immediately reactivate a deactivated meeting. This is just a brake on runaway meetings, so if someone locks their workstation and goes on vacation while signed into a meeting the meeting will eventually end. It’s meant to be an “infinity” value. You set it just higher than you expect a real meeting to last.
Expiration is when the server deletes the meeting, its contents, and coordinates (i.e. the link won’t work anymore). Expiration can’t happen while a meeting is activated, and there are grace periods based on the meeting type and scheduled end date. The grace periods are to give time to download meeting data (like uploaded handouts or whiteboards) before it’s deleted.
So, conference deactivation is when Lync will end an active meeting so it doesn’t sit there and take up server resources unnecessarily. It’s controlled using the cmdlet I mentioned above (Set-CsUserServicesConfiguration). Conference expiration however is hard-coded behaviour based on the type of conference that’s been initiated and means the absolute end of a meeting. This means the meeting URL and conference ID cease to work and all meeting content is deleted.
Interesting stuff to know. Credit to CJ Vermette from Microsoft for explaining this and clarifying how the two behaviours are different.
Pingback: Lync Conference Expiration and Deactivation Explained | Justin Morris on UC | JC's Blog-O-Gibberish
Pingback: Lync MVP Article Roundup: April 2013 - NextHop - Site Home - TechNet Blogs
Pingback: Conferencing Activation/Deactivation Deep Dive
As mentioned “A recurring scheduled meeting without a specified end date, the expiry time is 6 months after the last meeting activation.” If I am understanding correctly, a meeting will be re-activated when the authenticated user joins the meting at every occurrence (off-course within 6 months period). This re-activation should reset the 6 months counter to start over and thus make it virtually never ending, as long as an authenticated user keep, keep joining(re-activating) the meeting. Am I correct here or you would suggest any thing else?
I agree meeting and its content is permanently purged when it Expires.
However, you can still purge just the meeting content (like attachments, ppts, etc) before the meeting Expires.
This is done by modifying the value for ContentGracePeriod using the Set-csConferencingConfiguration.
For example, if you set it to the lowest acceptable value (30 minutes). The content gets deleted after 30 minutes after the meeting is DEACTIVATED.
One can notice that the content is gone if they re-use the meeting at a later time (as long as they do not re-use it within 30 minutes after the last meeting completed)
If they do reactivate the meeting within 30 minutes after it was last completed, the ContentGracePeriod timer is reset. The old content will be still there.
One thing to note is that there does not appear to be an expiry time for a meeting using the dedication meeting space. This is likely considered to be an “ongoing” meeting and therefore non expiring. The ExpiryTime is noticed in the user’s primary FE RTC database within RTCLOCAL instance in a tabled called dbo.conference. Meetings created using the dedicated meeting space will have a “NULL” value for ExpiryTime, but adhoc meetings are set to 8 hours after meeting and meetings using the public workspace are set to 15 days. These days all SfB meetings in o365 are unique meeting IDs so the notion of a non-expiring dedicated meeting may be of less concern, but for those with on-prem deployments, FYI.
Yash (commenter above) also makes a good point with wiping meeting content, however, if you are consistently using your dedicated meeting space for meetings, then it is unlikely you’d ever hit the default ContentGracePeriod of 15 days. So either lower the ContentGracePeriod to something less, or change experience to default to using public meeting spaces for all users. Or some combination of the two 🙂
Hi,
Grace period settings are for OnPrim Skype, Can you help me for Skye for business online. What is the grace period and how we can modify it as per our requirements.
Thanks
It’s covered in the original article I linked to. It can’t be changed afaik.