Since these cookies are strictly necessary to deliver the websites, you cannot refuse them without impacting your experience and how our websites function. These cookies are strictly necessary to provide you with services available through our websites and to use some of its features (such as access to secure areas). Note, that blocking some types of cookies may impact your experience on our websites and the services we are able to offer. You can also change your cookie preferences. Cookies help us know when you visit our websites, how you interact with us, and what content you view, so we can customize your experience with Acquia, including offering you more relevant content and advertising. We use cookies to enrich and personalize your user experience. So either lower the ContentGracePeriod to something less, or change experience to default to using public meeting spaces for all users.Aalto's websites may request cookies to be set on your device. 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. 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. 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. The ExpiryTime is noticed in the user’s primary FE RTC database within RTCLOCAL instance in a tabled called dbo.conference. This is likely considered to be an “ongoing” meeting and therefore non expiring. One thing to note is that there does not appear to be an expiry time for a meeting using the dedication meeting space. Interesting stuff to know. Credit to CJ Vermette from Microsoft for explaining this and clarifying how the two behaviours are different. This means the meeting URL and conference ID cease to work and all meeting content is deleted. 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. It’s controlled using the cmdlet I mentioned above (Set-CsUserServicesConfiguration). So, conference deactivation is when Lync will end an active meeting so it doesn’t sit there and take up server resources unnecessarily.
#Skype for business mac send meeting url download#
The grace periods are to give time to download meeting data (like uploaded handouts or whiteboards) before it’s deleted.
Expiration can’t happen while a meeting is activated, and there are grace periods based on the meeting type and scheduled end date. You set it just higher than you expect a real meeting to last.Įxpiration is when the server deletes the meeting, its contents, and coordinates (i.e. 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. However, you can immediately reactivate a deactivated meeting. It’s like a server-driven version of the exit-and-end-meeting presenter command. Deactivation and expiration are related, but different.ĭeactivation is when the server will forcefully shut down a meeting.
However, this was only half of the story. 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. To clarify, meeting activation is whenever a conference is accessed by a participant. For a recurring scheduled meeting without a specified end date, the expiry time is 6 months after the last meeting activation.For an ad hoc IM or A/V conference, the expiry time is 8 hours.
#Skype for business mac send meeting url plus#
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 a one-time scheduled meeting, the expiry time is the scheduled end time plus 14 days.In the first instance, I managed to find this about conference expiration in Office 365: 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”.
0 kommentar(er)
