Web Conferencing Server

Web Conferencing Architecture

Office Communications Server Web conferencing requires that Live Meeting clients can connect to a Standard Edition server or an Enterprise pool, a Web Conferencing Server, and a Web Components Server (IIS). Furthermore, the Web Conferencing Server and Web Components Server must have access to the shared folders that the administrator created during deployment, in order to store meeting information (metadata) and meeting content. The Web Conferencing Server must have read/write access to the metadata folder and write access to the content folder. The Web Components Server must have read access to the content folder.

Figure 22 shows the required topology for Web conferencing with Office Communications Server.

Figure 22.   Web Conferencing Server topology

These servers can be installed and run on the same physical computer or they can be installed on different computers. However, it is recommended that a dedicated file server hosts the conferencing metadata and content folders.

File Structure

At a minimum, the Web Conferencing Server is configured with two UNC paths that indicate where the server stores conference state (metadata) and conference content. The first UNC path is where the server stores the conference metadata files. The second UNC path is where the server stores conference content. These folders are also referred to as the metadata folder and the content folder.

The following paths can be configured using either the MMC or the Windows Management Instrumentation (WMI) MSFT_SIPDataMCUCapabilitySettings class:

• MeetingMetadataLocation property for metadata file location.

• MeetingPresentationContentLocation property for content location.

In addition to these folders, the Web Conferencing Server can also be configured with a third UNC path for a compliance folder. Regulatory compliance is not enabled by default, but if your organization needs to retain data exchanged in Web conferences to satisfy regulatory compliance requirements, you can configure a UNC path to the compliance folder using either the MMC or the WMI MSFT_SIPDataComplianceSettingClass.

These UNC paths can point to a file system running on the same computer or, preferably, on a dedicated file server. The administrator manually creates these folders when deploying Office Communications Server.

Metadata Folder

The metadata folder stores the conference metadata (for example, the number of slides, the slide names, and the slide types) that is shared by the Web Conferencing Server with clients over PSOM. Under the metadata folder root, the Web Conferencing Server creates the following structure of subfolders:

• For each conference organizer, the Web Conferencing Server creates a separate folder below the metadata folder root. The organizer folder name is a hash value computed using the organizer URI.

• For each conference, the Web Conferencing Server creates a separate folder below the organizer subfolder. The conference folder name is the same as the conference ID.

• Metadata files for a conference are stored in the conference folder.

Figure 23 shows the structure of metadata folders for m organizers and n conferences for the first organizer.

Figure 23.   Metadata folder and subfolder structure

The Web Conferencing Server creates these folders and subfolders when it receives a C3P addConference request from the Focus. If a folder for an organizer does not exist, the Web Conferencing Server creates a new organizer folder. If a folder for an organizer already exists, the Web Conferencing Server creates the conference subfolder below the existing organizer folder. If a folder for a conference does not exist, the Web Conferencing Server creates a new conference folder. If a conference folder already exists, the Web Conferencing Server saves the metadata files in the existing conference folder.

Sensitive information about conferences, including each conferences encryption key, is stored in the metadata folder. As a result, it is recommended that, during deployment, the administrator grants Read/Write permissions for the metadata folder only to the user group that will administer the Web Conferencing Server.

Organizer Folder

When a Web Conferencing Server needs to create a metadata folder for a conference, it extracts the organizer URI from the addConference XML. The URI is passed as input for a hash function. The result of this call is used to search through the subfolders of the metadata root folder to determine whether there is already an existing organizer subfolder. If no organizer subfolder exists, the Web Conferencing Server creates a new one.

Having a separate folder for each organizer allows the administrator to easily move the conferences owned by a particular user. The resource kit has a tool, DMHash.exe, which allows an administrator to input an URI and obtain the hash. For example, if you need to change the URI for a user and continue to have the content available, you need to:

• Run DMHash.exe with the old URI and get the name for the organizer folder.

• Run DMHash.exe with the new URI and get the name for the new organizer folder.

• Rename the old folder using the new hash value.

Conference Folder

When a Web Conferencing Server needs to create a metadata folder for a conference, after the server has created or identified the appropriate organizer folder, the server extracts the conference ID from the XML in the C3P addConference request, and then searches the subfolders below the organizer folder for a folder with the same name as the conference ID. If a matching folder does not exist, the Web Conferencing Server creates a new folder below the organizer folder.

The conference folder contains all the information that is used by Web Conferencing Server to recreate the content of a conference. Figure 24 shows the structure of the files that are stored in a conference folder.

Figure 24.   Conference folder and subfolder structure

The conference folder has one subfolder named for presentations. In this subfolder, the Web Conferencing Server creates all the conference files.

Types of Slides

The Web Conferencing Server enables conference participants to share content that has been uploaded to the conference. If PSOM was used to upload all content to the conference, content can be downloaded from the Web Conferencing Server to a participant's Live Meeting client using either PSOM or HTTPS. If content is uploaded using HTTPS, then the download is performed by the IIS server instead of the Web Conferencing Server.

Table 10 describes the protocols that can be used to upload and download each type of slide that a Live Meeting presenter can create.

Table 10.   Upload and download protocols for Live Meeting slides

Content Upload and Download over PSOM

PSOM offers the most basic mechanism for uploading and downloading content to a conference. Uploading and downloading over PSOM involves only the Live Meeting clients, the Web Conferencing Server, and the file server where the Web conferencing metadata and content folders reside.

Using PSOM, the presenters Live Meeting client uploads a slide and its content. The Web Conferencing Server checks the presenter's permissions and then creates the state for the new slide. The Web Conferencing Server saves the state on the file server and then shares the new slide state with all clients in the conference.

Figure 25 shows the upload and download process for conference content.

Figure 25.   Data flow for conferencing content upload and download over PSOM

For all slide types except poll slides, the content is sent with the first PSOM message. For poll slides, the content (question and choices) is sent after an initial create slide has been sent.

Content Upload over PSOM and Download over HTTPS

When the actual content for a slide is uploaded to the Web Conferencing Server, the client uses a stream to send the data from the local computer to the Web Conferencing Server. The stream mechanism is built on top of PSOM to send, in real-time, a large amount of data. (PSOM is typically used to send only small pieces of data, such as integers and short strings.)

When the content of slides uploaded to the server over PSOM must be accessed by conference participants, HTTPS is used to download the content.

For example, PowerPoint slides, Word documents, and handout slides (file transfers) all require participants to transfer from the Web Conferencing Server a significant amount of data, including images and original documents. For these types of slides, the data is transferred to clients using the Web Components Server. First, the Web Conferencing Server writes the content to the shared folder for conferencing content. (The folders where the content is saved are encrypted.) Then, the Web Conferencing Server sends clients in the conference the URL and the encryption key for the content files. Each participant uses this URL to download the content from the Web Components Server. Using the encryption key, each participant decrypts the content and displays it in the Live Meeting window.

Figure 26 shows the data flow when clients download conference content over HTTPS.

Figure 26.   Data flow for download of conference content over HTTPS

The upload process is similar to the one whereby the content is downloaded over PSOM. The difference is that the Live Meeting client always sends content to the Web Conferencing Server in a separate step, as a stream over PSOM.

After the Web Conferencing Server receives the content stream from the presenter, the Web Conferencing Server generates a random encryption key and file name for the content and saves the content into the content folder on the shared file system. After the content is saved to the file server, the Web Conferencing Server sends the encryption key and file name to the client. The client sends a GET request to the Web Components Server. Since the Web Components Server is configured to use the same content folder, IIS is able to resolve the request and send the client the encrypted content. The Live Meeting client then decrypts the content and displays it.

Slide Set Files

For each slide set created, the Web Conferencing Server saves two encrypted XML files. The encryption algorithm is AES and the encryption key is the master key stored in the conference.xml file. Because the files are encrypted, their file names use an .exml file name extension.

Each slide set has a unique identifier. The slide set file names are created using the following patterns:

      set-<unique_identifier>.exml and set-s-<unique_identifier>.exml

For example, for a slide set with the unique identifier abc, the file names are set-abc.exml and set-s-abc.exml.

The content of the two files is the same. The second file is provided for backup purposes. When the Web Conferencing Server needs to save new changes in the slide set with the unique identifier aaa, the server opens the first file—set-aaa.exml—and attempts to save the changes to that file. If the original write operation succeeds, the server creates a copy of set-aaa.exml and names the copy slide-s-aaa.exml. If the write operation fails, the Web Conferencing Server deletes set-aaa.exml, creates a new copy of set-s-aaa.exml, and names the copy set-aaa.exml.

Figure 27 shows the logical flow of the update operation.

Figure 27.   Update slide operation

The update procedure for slide sets is called every five minutes. This value is hard coded and cannot be changed. If an update operation fails, the changes made to a slide set in the past five minutes are not saved. If the Web Conferencing Server stops running during this period, changes to the slides can be lost. However, the Web Conferencing Server continually tries to update the files every five minutes. As a result, if one attempt fails, the Web Conferencing Server can attempt to save the content later.

Each slide set file contains the XML serialization of the data required to recreate the slide set content. The generic layout for this XML is as follows:

• A root node that contains information about the slide set (for example, the name, creator, and time when the slide set was created).

• A child node for each slide in the slide set. This node contains the information about the slide (for example, the name, creator, time when the slide was created, type of slide, a link to the original document, and a link to the images representing the slide).

• Based on the type of slide, there can be child nodes. For example, there can be a child node for the annotations in a PowerPoint slide or a child node for the question and answer choices in a poll slide.

The file is a snapshot of the current content for a given slide set. The file does not store historical information such as deleted slides or the values for attributes before they have been updated.

There are two types of slides:

• Slides for which all the slide content is shared between Web Conferencing Server and meeting clients using only the PSOM channel. The following table lists the slide types for which all content is shared over PSOM.

  Table 11. Slides shared over PSOM

  Slide Type	Slide Content Shared over PSOM
  Web slide	Name, URL
  Poll Slide	Name, question, answer choices
  Text Slide	Name, content
  Application Sharing Slide	Name, type of sharing (Desktop or Application), color depth, process ID

• Slides for which some part of the content is shared between the Web Conferencing Server and meeting clients over PSOM and some other part of the content is shared between the Web Components Server and meeting clients over HTTPS. The following table lists the slide types for which content is partially shared over PSOM and partially shared over HTTPS.

  Table 12. Slides partially shared over PSOM and partially shared over HTTPS

  Slide Type	Slide Content Shared over PSOM	Slide Content Shared over HTTPS
  Whiteboard	Name, annotations	Background image (white rectangle)
  Snapshot	Name, annotations	Background image (the desktop screen capture from the conference presenter)
  PowerPoint	Name, annotations	PNG files for the large slide image and for the slide thumbnail; original PPT document
  Word Document	Name, annotations	PNG files for the big image and for thumbnail; original MDI document
  Multimedia	Name	Original multimedia file; the chunk files

For slides for which some content is shared over PSOM and some is shared over HTTPS, the content that is shared over HTTPS is stored in the conference content folders. The conference metadata file for the slide set stores only the link to the conference content file and the encryption key.

For example, if you have a slide generated from a PowerPoint slide, under the XML node for that slide you find the:

• Randomly generated name for the original uploaded PPT file.

• Encryption key for the PPT file.

• Randomly generated name for the large image of the slide in PNG format.

• Encryption key for the PNG file.

• Randomly generated name for the thumbnail image of the slide in PNG format.

• Encryption key for the PNG file.

You can use the names of these PPT and PNG files to search for the slide content in the conference content folders.

<poll-slide 
   name="[ Poll 1 ]" 
   recording-id=""
   createdby="sip:vw01@rtcdev.nttest.microsoft.com [vw01]">
   <question>What day is today?</question>
   <choice>MON</choice>
   <choice>TUE</choice>
   <choice>WED</choice>
   <choice>THU</choice>
   <choice>FRI</choice>
   <choice>SAT</choice>
   <choice>SUN</choice>
</poll-slide>

<text-slide 
   name="[ Text Slide 1 ]" 
   recording-id="" 
   createdby="sip:vw01@rtcdev.nttest.microsoft.com [vw01]"
>
   <current-text>
   This is the content of a text slide I've just typed
   </current-text>
</text-slide>

<web-slide 
   name="[ Web Slide 1 ]" 
   recording-id="" 
   createdby="sip:vw01@rtcdev.nttest.microsoft.com [vw01]" 
   url="https://microsoft.com">
</web-slide>

<image-slide 
   name="[ White Board 1 ]" 
   recording-id="" 
   createdby="sip:vw01@rtcdev.nttest.microsoft.com [vw01]" 
   image-width-attr="704" 
   image-height-attr="528" 
   page-number="-1" 
   rich-slide-type="Whiteboard" 
   thumbnail-aspect="1.33333337">
   <ann 
      COLOR="0" 
      AUTHOR="vw01" 
      TYPE="1" 
      recording-id="">
      01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011400980116009901160099
   </ann>
   <ann 
      COLOR="0" 
      AUTHOR="vw01" 
      TYPE="23" 
      recording-id="">
      17000000009700fa01090144
   </ann>
</image-slide>

<image-slide 
   name="[ Snapshot 1 ]" 
   recording-id="" 
   createdby="sip:vw01@rtcdev.nttest.microsoft.com [vw01]" 
   image="x8d51284585d1.epng" 
   key="a51fe0f3e26813761e12435a9c2c5d89" 
   image-filesize-attr="52865" 
   image-width-attr="388" 
   image-height-attr="369" 
   page-number="-1" 
   rich-slide-type="Image" 
   thumbnail-image="xe31d11b0506d.epng" 
   thumbnail-key="a51fe0f3e26813761e12435a9c2c5d89" 
   thumbnail-aspect="1.0" 
   compliance-image="xcb4de1d7b784-aae.png">
   <ann 
      COLOR="0" 
      AUTHOR="vw01" 
      TYPE="1" 
      recording-id="">
      01000000000a0075007a00af007100cc009c00c000ba009d00b0009b009d00f40084011400980116009901160099
   </ann>
   <ann 
      COLOR="0" 
      AUTHOR="vw01" 
      TYPE="23" 
      recording-id="">
      17000000009700fa01090144
   </ann>
</image-slide>

<image-slide 
   name="Page 1" 
   slideset-name="test.txt" 
   recording-id="" 
   createdby="sip:vw01@rtcdev.nttest.microsoft.com [vw01]" 
   image="xebc7f400248d.epng" 
   key="ce3de85a37a8a6fc6b3b702b70a1a925" 
   image-filesize-attr="6778" 
   image-width-attr="816" 
   image-height-attr="1056" 
   document="x9838edc7b0d2.emdi" 
   document-key="8ca685d4bcfb9afe94cc27ea4bd0a2e1" 
   document-filesize-attr="1537" 
   rich-slide-type="Modi" 
   thumbnail-image="x908006115ceb.epng" 
   thumbnail-key="40d224ca035ee8f77ba9c7342da17b1b" 
   thumbnail-aspect="0.772727251" 
   thumbnail-filesize-attr="748" 
   compliance-image="xf3ae96bf86cd-aag-pngimage0.png" 
   compliance-document="xbe356497761b-aag-x.mdi">
</image-slide>

<demo-slide 
   name="Command Prompt - vw01" 
   recording-id="" 
   createdby=sip:vw01@rtcdev.nttest.microsoft.com [vw01]
   shareProcInfo=sip:vw01@rtcdev.nttest.microsoft.com - 01C7E74B9137AC70
   shareHwnd="262300" 
   shareSpeed="1" 
   sharePid="4592"
   slideHotKey="19"
   slideColor="24" 
   shareTitle="Command Prompt" 
   slideCtrl="1" 
   shareType="1">
</demo-slide>

Handouts (File Transfers)

You can think of file transfers, also known as handouts, as another type of slide set. Handouts can be considered slide sets that contain only one slide of a single type: a transferred file.

The Web Conferencing Server follows the same process to save and update handout slides that it uses for other slide sets. First, the server saves two encrypted XML files for each handout. The content of the two files is the same. The second file is provided for backup purposes.

The update procedure for a handout is called every five minutes. If an update operation fails, the changes made to a handout in the past five minutes are not saved. If the Web Conferencing Server stops running during this period, changes to the handout can be lost. However, the Web Conferencing Server continually tries to update the XML files every five minutes. As a result, if one attempt fails, the Web Conferencing Server can attempt to save the content later.

The only differences in the save and update process for handouts are the location where the files are saved and updated, the naming convention used to name the files, and the file that keeps track of the IDs for the slide set for handouts.

The files are saved under a separate subfolder (named ft) in the conference folder for the organizer. The FTMaxID files contain the last used ID. The names of the files in which the slide set information is saved take the following form: fileset-<id>.exml. The files are encrypted using the master encryption key.

The file content represents the XML serialization of handout information. Because handout slides are shared over HTTPS in the XML, there is an encryption key and the randomly generated name for the file that is saved in the content folder.

<fileset 
   name="a8f5689f4866.blb" 
   size="37" 
   key="48d9dd6ebe2ca367478da698493edc21" 
   UploadedOnDate="8/25/2007 12:20 PM" 
   UploadedOn="1188069617459" 
   UploadedBy="sip:vw01@rtcdev.nttest.microsoft.com" 
   file_deleted="false" 
   original_filename="test.txt" 
   creation_date="128325431784134388" 
   CreatedOnDate="1/18/8441 5:22 PM" 
   modification_date="128325431917125620" 
   ModifiedOnDate="1/20/8441 6:18 AM">
</fileset>

PersistData Folder (Shared Notes)

In the PersistData folder, the Web Conferencing Server stores only one file. The file contains the XML serialization of the shared notes information. The file is encrypted using the conference master encryption key. The file contains the XML serialization for rich text.

<PersistentData>
  <ScopeManager />
    <SharedNotes>
      <RichString>
        <PlainText>This is the content of the shared notes pane I've just edited 
        </PlainText>
      <StyleData>
        <Character>
          <FormatTable>
            <Format fontface="Arial" fontsize="9.0" bold="false" italic="false" underline="false" /><Format fontface="" fontsize="9.0" bold="false" italic="false" underline="false" />
          </FormatTable>
          <FormatRunTable>
            <FormatRun format="0" length="62" />
          </FormatRunTable>
        </Character>
        <Paragraph>
          <FormatTable>
            <Format bullets="0" numbering="0" /><Format bullets="1" numbering="0" />
            <Format bullets="0" numbering="1" />
          </FormatTable>
          <ParaFormats>
            <Paragraph format="0" />
          </ParaFormats>
        </Paragraph>
      </StyleData>
    </RichString>
  </SharedNotes>
</PersistentData>

Content Folder

The content folder stores the content that is shared between the Web Conferencing Server and clients using the Web Components Server. The content folders structure is similar to other subfolders. The content folder contains the following:

• A separate subfolder for each organizer; the folder name is a hash based on the organizer URI.

• Under the organizer subfolder, there is a separate folder for each conference; the folder name is the same as the conference ID.

Figure 28 shows the structure of the content folder.

Figure 28.   Content folder

Conference Content Folder

The conference content folder stores all the conference content that is shared between the Web Conferencing Server and meeting clients. Figure 29 shows the structure of the files that are stored in a conference folder.

Figure 29.   Conference folder and subfolders

File Size Restrictions

Size restrictions are enforced by the Web Conferencing Server for certain documents uploaded to the Web Conferencing Server, such as PowerPoint documents, Word documents, multimedia, snapshot slides, and handout slides. The following table describes the values that the Web Conferencing Server enforces.

Table 16 Web Conferencing Server file size restrictions

The values for the total size and number of files refer to the files in a conference. It is recommended that you reserve 100 MB for each conference created on the Web Conferencing Server. The file restriction values can be configured using the WMI MSFT_SIPDataMCUCapabilitySetting class.

File size policies are enforced each time a new slide or file is added to a conference or an existing slide or file is removed. If the presenter is trying to upload or transfer a new file that results in a violation of file size restrictions, the operation fails. The Web Conferencing Server also provides performance counters that indicate each time an upload or transfer exceeds one of these limits.

Compliance

If meeting compliance is enabled, compliance folders are created on the file server. The compliance folder stores the content that is shared between the Web Conferencing Server and meeting clients through the Web Components Server in a clear unencrypted format. The compliance folder structure is similar to the structure of subfolders in the metadata and content folders. The compliance folder contains the following:

• A subfolder for each organizer; the folder name is a hash value computed using the organizer URI.

• A subfolder for each conference under each organizer subfolder; the folder name is the conference ID.

Figure 30 shows the structure of the compliance folder.

Figure 30.   Compliance folder and subfolders

Ensure that only authorized users have read or write permissions and that the Web Conferencing Server has write permissions to the compliance folder.