locked
Re-enter Live Meetings ? RRS feed

  • Question

  • Hi,

    I know i read this somewhere but I have no idea where to find it anymore.
    When a scheduled meeting is over, and I want to join the meeting after let's say, 3 days again to recap the ppt's or other content
    I can join the meeting with the invitaion e-mail.
    But how long can I do this, and how can i change this reentrance period?

    Thanks
    Wednesday, October 7, 2009 11:51 AM

Answers

  • Understanding Conference Expiration

    To save disk space and improve performance, Office Communications Server does not store conferences and their content indefinitely. When a conference is created, the conference is given an expiration time. When a conference expires, the conference data record is deleted from the back-end conferencing database and all content data associated with the meeting is deleted. After a meeting expires, no participants, including the organizer, can join the meeting.

    The front-end server runs a low-priority expiration thread for the RTC database. When woken up, the thread searches for conferences that meet all of the following criteria:

    • There is an expiration time associated with the conference, and the expiration time has passed; or there is no expiration time associated with the conference, and six months have passed since the last recorded conference activation.
    • The conference is not currently active.

    Any meetings that satisfy the preceding criteria are deleted from the RTC database.

    It is up to the scheduling client to specify the expiration time when creating a conference on the server. The expiration time is communicated to each conferencing server that is involved when the conference is activated. Here are some recommendations based on the conference type:

    • For one-time scheduled conferences, set the expiration time to be the scheduled end time plus 14 days.
    • For recurring scheduled conferences with an end date, set the expiration time to be the scheduled end time of the last occurrence plus 14 days.
    • For recurring scheduled conferences without specified end dates, do not set an expiration time or set null as the expiration time.
    • For ad hoc IM or A/V conferences, set the expiration time to be eight hours.

    Note
    If no expiration time is specified by the client, the maximum grace period (six months) allowed by the server is used as the expiration time. This maximum allowed grace period is reset whenever a conference is activated. For example, after a conference is activated and deactivated, it will expire in six months. After three months, the meeting is activated again, and then the conference will expire in another six months, not three months.

    Similarly, the Web Conferencing Server also runs a low-priority expiration thread similar to the one that runs on the front-end server. When woken up, the thread scans the conference content metadata file share and checks for the expiration time for each conference. The Web Conferencing Server adds a grace period (by default 14 days) on top of the expiration time. It deletes the content folder associated with a conference only if the conference expiration time plus the grace period has passed.

    Source: http://www.windowsnetworking.com/articles_tutorials/Microsoft-Office-Communications-Server-Resource-Kit-Chapter5-Conferencing-Scenarios-Part2.html


    Bruno Estrozi - MCSE +S +M/MCTS/MCITP - Unified Communications Specialist | http://brunoestrozi.com.br
    Wednesday, October 7, 2009 12:16 PM
  • I believe this is the section of the documentation you are looking for: http://technet.microsoft.com/en-us/library/dd572561(office.13).aspx

    The default Expiration time on a scheduled meeting is 14 days.  Updating the 'ContentExpirationGracePeriod' value in WMI controls the timeout.

    Also take a look at this blog for more details: http://unified-communications.blogspot.com/2008/03/content-life-cycle-ocs-and-tools.html
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, October 7, 2009 12:18 PM
    Moderator
  • Managing Meeting Life Cycles

    Meeting life cycles are controlled by the following processes:

    • Deactivation. Deactivating a meeting ends the instance of the meeting, but the meeting continues to exist in the database and can be reactivated and rejoined.
    • Expiration. When the expiration time is reached, the meeting and all associated meeting content are deleted from the database. The default expiration time is 14 days.

    Meeting deactivation and expiration are primarily automatic processes in Office Communications Server 2007. However, there are three WMI settings that the administrator can use to modify the meeting deactivation and expiration processes.

    For conference deactivation, there are two pool-level WMI settings that are stored as properties in the MSFT_SIPMeetingScheduleSetting WMI class in the root\CIMV2 namespace, as described in Table 12.

    Table 12. MSFT_SIPMeetingScheduleSetting WMI class in the root\CIMV2 namespace

    Property Name Type Default Value Description

    UnAuthenticatedUserGracePeriod

    Integer (0~60)

    10 (minutes)

    Grace period allowed for anonymous or federated users to stay in the meeting without any authenticated user in the meeting.

    MaxMeetingLength

    Integer

    (0 ~ 8760)

    24 (hours)

    Maximum length of any meeting without join activity.

    For conference expiration, there is one pool-level WMI setting that is stored as a property in the MSFT_SIPDataMCUCapabilitySetting WMI class in the root\CIMV2 namespace, as described in Table 13.

    Table 13. MSFT_SIPDataMCUCapabilitySetting WMI class in the root\CIMV2 namespace

    Property Name Type Default Value Description

    ContentExpirationGracePeriod

    Integer (0~365)

    14 (days)

    Grace period in addition to the expire time, after which the Web Conferencing Server should clean up content for a conference.

    Use Windows Management Instrumentation Tester (WBEMTest) and the following procedure to modify deactivation and expiration WMI settings.

    1. Log on to an Office Communications Server 2007 Standard Edition Server or a server in an Enterprise Edition pool, or a server with Office Communications Server 2007 administrative tools installed, as a member of the RTCUniversalServerAdmins group or an account with equivalent user rights.

    2. Click Start, click Run, type wbemtest, and then click OK.

    3. In the Windows Management Instrumentation Tester dialog box, click Connect.

      Bb936616.27e7feec-ae94-4768-a4b8-31d5ec539898(en-us,office.12).jpg
    4. In the Connect dialog box, in Namespace, type root\cimv2, and then click Connect.

    5. In the Windows Management Instrumentation Tester dialog box, click Open Instance.

    6. In the Get Object Path dialog box, in Object Path, type the WMI class name (MSFT_SIPMeetingScheduleSetting or MSFT_SIPDataMCUCapabilitySetting), and then click OK.

    7. In the Object editor dialog box for the WMI class, click Instances.

    8. In the Query Result dialog box, double-click an instance.

    9. In the Object editor dialog box for the WMI class, double-click the property you want to edit in Properties:

      • If you specified the MSFT_SIPMeetingScheduleSetting WMI class in step 6 of this procedure, double-click UnAuthenticatedUserGracePeriod or MaxMeetingLength.
      • If you specified the MSFT_SIPDataMCUCapabilitySetting WMI class in step 6 of this procedure, double-click ContentExpirationGracePeriod.
    10. In the Property Editor dialog box, change the value to the new value in the Value box, and then click Save Property.

    11. When you are finished with the editing, in the Object editor dialog box, click Save Object.

    12. Close all dialog boxes, and then close Windows Management Instrumentation Tester.

    13. To verify that the change was applied, open Event Viewer and look for event ID 56015.


      Source: http://technet.microsoft.com/en-us/library/bb936616.aspx


    Bruno Estrozi - MCSE +S +M/MCTS/MCITP - Unified Communications Specialist | http://brunoestrozi.com.br
    Wednesday, October 7, 2009 12:23 PM

All replies

  • Understanding Conference Expiration

    To save disk space and improve performance, Office Communications Server does not store conferences and their content indefinitely. When a conference is created, the conference is given an expiration time. When a conference expires, the conference data record is deleted from the back-end conferencing database and all content data associated with the meeting is deleted. After a meeting expires, no participants, including the organizer, can join the meeting.

    The front-end server runs a low-priority expiration thread for the RTC database. When woken up, the thread searches for conferences that meet all of the following criteria:

    • There is an expiration time associated with the conference, and the expiration time has passed; or there is no expiration time associated with the conference, and six months have passed since the last recorded conference activation.
    • The conference is not currently active.

    Any meetings that satisfy the preceding criteria are deleted from the RTC database.

    It is up to the scheduling client to specify the expiration time when creating a conference on the server. The expiration time is communicated to each conferencing server that is involved when the conference is activated. Here are some recommendations based on the conference type:

    • For one-time scheduled conferences, set the expiration time to be the scheduled end time plus 14 days.
    • For recurring scheduled conferences with an end date, set the expiration time to be the scheduled end time of the last occurrence plus 14 days.
    • For recurring scheduled conferences without specified end dates, do not set an expiration time or set null as the expiration time.
    • For ad hoc IM or A/V conferences, set the expiration time to be eight hours.

    Note
    If no expiration time is specified by the client, the maximum grace period (six months) allowed by the server is used as the expiration time. This maximum allowed grace period is reset whenever a conference is activated. For example, after a conference is activated and deactivated, it will expire in six months. After three months, the meeting is activated again, and then the conference will expire in another six months, not three months.

    Similarly, the Web Conferencing Server also runs a low-priority expiration thread similar to the one that runs on the front-end server. When woken up, the thread scans the conference content metadata file share and checks for the expiration time for each conference. The Web Conferencing Server adds a grace period (by default 14 days) on top of the expiration time. It deletes the content folder associated with a conference only if the conference expiration time plus the grace period has passed.

    Source: http://www.windowsnetworking.com/articles_tutorials/Microsoft-Office-Communications-Server-Resource-Kit-Chapter5-Conferencing-Scenarios-Part2.html


    Bruno Estrozi - MCSE +S +M/MCTS/MCITP - Unified Communications Specialist | http://brunoestrozi.com.br
    Wednesday, October 7, 2009 12:16 PM
  • I believe this is the section of the documentation you are looking for: http://technet.microsoft.com/en-us/library/dd572561(office.13).aspx

    The default Expiration time on a scheduled meeting is 14 days.  Updating the 'ContentExpirationGracePeriod' value in WMI controls the timeout.

    Also take a look at this blog for more details: http://unified-communications.blogspot.com/2008/03/content-life-cycle-ocs-and-tools.html
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Wednesday, October 7, 2009 12:18 PM
    Moderator
  • Managing Meeting Life Cycles

    Meeting life cycles are controlled by the following processes:

    • Deactivation. Deactivating a meeting ends the instance of the meeting, but the meeting continues to exist in the database and can be reactivated and rejoined.
    • Expiration. When the expiration time is reached, the meeting and all associated meeting content are deleted from the database. The default expiration time is 14 days.

    Meeting deactivation and expiration are primarily automatic processes in Office Communications Server 2007. However, there are three WMI settings that the administrator can use to modify the meeting deactivation and expiration processes.

    For conference deactivation, there are two pool-level WMI settings that are stored as properties in the MSFT_SIPMeetingScheduleSetting WMI class in the root\CIMV2 namespace, as described in Table 12.

    Table 12. MSFT_SIPMeetingScheduleSetting WMI class in the root\CIMV2 namespace

    Property Name Type Default Value Description

    UnAuthenticatedUserGracePeriod

    Integer (0~60)

    10 (minutes)

    Grace period allowed for anonymous or federated users to stay in the meeting without any authenticated user in the meeting.

    MaxMeetingLength

    Integer

    (0 ~ 8760)

    24 (hours)

    Maximum length of any meeting without join activity.

    For conference expiration, there is one pool-level WMI setting that is stored as a property in the MSFT_SIPDataMCUCapabilitySetting WMI class in the root\CIMV2 namespace, as described in Table 13.

    Table 13. MSFT_SIPDataMCUCapabilitySetting WMI class in the root\CIMV2 namespace

    Property Name Type Default Value Description

    ContentExpirationGracePeriod

    Integer (0~365)

    14 (days)

    Grace period in addition to the expire time, after which the Web Conferencing Server should clean up content for a conference.

    Use Windows Management Instrumentation Tester (WBEMTest) and the following procedure to modify deactivation and expiration WMI settings.

    1. Log on to an Office Communications Server 2007 Standard Edition Server or a server in an Enterprise Edition pool, or a server with Office Communications Server 2007 administrative tools installed, as a member of the RTCUniversalServerAdmins group or an account with equivalent user rights.

    2. Click Start, click Run, type wbemtest, and then click OK.

    3. In the Windows Management Instrumentation Tester dialog box, click Connect.

      Bb936616.27e7feec-ae94-4768-a4b8-31d5ec539898(en-us,office.12).jpg
    4. In the Connect dialog box, in Namespace, type root\cimv2, and then click Connect.

    5. In the Windows Management Instrumentation Tester dialog box, click Open Instance.

    6. In the Get Object Path dialog box, in Object Path, type the WMI class name (MSFT_SIPMeetingScheduleSetting or MSFT_SIPDataMCUCapabilitySetting), and then click OK.

    7. In the Object editor dialog box for the WMI class, click Instances.

    8. In the Query Result dialog box, double-click an instance.

    9. In the Object editor dialog box for the WMI class, double-click the property you want to edit in Properties:

      • If you specified the MSFT_SIPMeetingScheduleSetting WMI class in step 6 of this procedure, double-click UnAuthenticatedUserGracePeriod or MaxMeetingLength.
      • If you specified the MSFT_SIPDataMCUCapabilitySetting WMI class in step 6 of this procedure, double-click ContentExpirationGracePeriod.
    10. In the Property Editor dialog box, change the value to the new value in the Value box, and then click Save Property.

    11. When you are finished with the editing, in the Object editor dialog box, click Save Object.

    12. Close all dialog boxes, and then close Windows Management Instrumentation Tester.

    13. To verify that the change was applied, open Event Viewer and look for event ID 56015.


      Source: http://technet.microsoft.com/en-us/library/bb936616.aspx


    Bruno Estrozi - MCSE +S +M/MCTS/MCITP - Unified Communications Specialist | http://brunoestrozi.com.br
    Wednesday, October 7, 2009 12:23 PM
  • Thank you so much.

    This Forum is amazing !


    Thanks
    Wednesday, October 7, 2009 12:33 PM