Configuring Meeting Workspace Options in Outlook 2003 | Microsoft Office 2003 Editions Resource Kit (Pro-Resource Kit)

A Meeting Workspace is a Web site for centralizing all the information and materials for an upcoming meeting. Before the meeting, you use a workspace to publish the agenda, attendee list, and documents you plan to discuss. After the meeting, you use the workspace to publish the meeting results and track tasks. You send a Microsoft Outlook meeting request to invite people to the meeting, and in the message, include a hyperlink that goes to the workspace where invitees can learn the details and see the materials.

You can configure a number of options to set up and manage your Meeting Workspace deployment with Microsoft Office Outlook 2003. You can manage how users choose Meeting Workspace servers and other options when creating workspaces to include in Outlook meeting requests. You can configure Meeting Workspaces to work when you use a POP server as your messaging server, and you can also view Meeting Workspace error messages in a log file to help troubleshoot problems with Meeting Workspace configurations.

Note

By default, when you use Meeting Workspaces with Outlook, you must have a Microsoft Exchange server configured as your messaging server.

A Meeting Workspace is a special type of Microsoft Windows SharePoint™ Services 2.0 Web site created under a top-level SharePoint site. Help for the Meeting Workspace as well as general SharePoint Help is available from the workspace.

Note

If you have Windows SharePoint™ Services installed on your network, users within your company can invite anyone to a workspace who is in the same Microsoft Windows NT forest as the original user. For more information about domains and forests, see information on Active Directory in Windows Help.

Using policies to define server lists and other user options

When you use policies to enforce Meeting Workspace settings for groups of users in your organization, you can configure options such as defining the list of Meeting Workspace servers users can choose from. Or, if you do not want users to use this feature, you can disable Meeting Workspace access entirely.

In a server list, you can specify how to prepopulate the drop-down lists that users see when working with Meeting Workspaces in Outlook. You access the Meeting Workspace feature by clicking Meeting Workspace on an Outlook meeting request. On the Meeting Workspace task pane that is presented, click Change settings. On this next Meeting Workspace task pane, choose a server from the Select a location: drop-down list. On the same pane, you can create a new workspace, choosing a template language and a template type from drop-down lists. Or, you can link to an existing workspace by choosing one from the Select a workspace drop-down list.

You use Group Policy to configure the lists and settings you want for Meeting Workspace. When you load the Microsoft Office 2003 ADM files into Group Policy, policies related to Meeting Workspace are located under User Configuration\Administrative Templates\Microsoft Office Outlook 2003\Meeting Workspace. This is also the location where you create a new policy to list Meeting Workspace servers and other items in Meeting Workspace task pane drop-down lists.

Configuring server list behavior for meeting organizers

You can configure how Meeting Workspace server lists are presented to meeting organizers in Outlook—for example, server lists can show a most recently used (MRU) list, or the list of servers and templates can be repopulated from the default list each time a workspace is being created. You can also help to prevent Meeting Workspace access by disabling the Meeting Workspace option for Outlook meeting requests.

When you specify the list of servers, you can ensure that the server list is repopulated with default servers and default templates. You can also help to control whether users can access servers other than those specified. You remove the Meeting Workspace button from Outlook meeting requests with the Disable Meeting Workspace button policy. Double-click the policy to open the Properties dialog, then select Enabled to enable the policy itself. Then select Check to disable Meeting Workspace button.

You configure options for the Meeting Workspace Select a location drop-down list with the Disable user entries to server list policy. Double-click the policy to open the Properties dialog, then select Enabled to enable setting the policy itself. In the Check to disable users from adding entries to server list drop-down list, select one of the following:

Publish default, allow others—You specify a list of default servers that appears in the drop-down list, but users can specify other servers by using the Other workspace server pop-out dialog. In addition, other Windows SharePoint Services sites and document workspace sites that users visit appear on the server list. With this setting, no user MRU list is created.
Publish default, disallow others—The default server list you specify is locked down for users. Users cannot access the Other workspace server pop-out dialog to specify servers that are not on the provided list. With this setting, no user MRU list is created.

Specifying a list of servers and default templates

You can configure the list of servers and corresponding Meeting Workspace templates that will appear in a drop-down list when a user clicks Meeting Workspace in a meeting request. A single registry key or policy stores all the Meeting Workspace server list entries.

On the Resource Kit CD

You can deploy the registry key that specifies the list of Meeting Workspace servers to your users by using the Custom Installation Wizard (for an initial deployment) or the Custom Maintenance Wizard (to update an existing installation). These tools are installed together with other Office 2003 tools when you run the Office Resource Kit Setup program. For more information, see Appendix A, “Toolbox.”

The server list policy has a specific format that must be followed. Server names are separated from each other by vertical pipes (“|”) without any carriage returns (CRs) or line feeds (LFs). There are six fields per record as described below. There can be from one to five records in the policy. This is a MRU list, so the first server record (for example, Server1) is the most recently used server and the fifth server record (for example, Server5) is the oldest server reference.

The OrganizerName field is ignored when you use a policy to specify the server list, but the other fields should always have valid content.

Note

You can see the current server list settings on any computer that has been used to create Meeting Workspaces by examining this registry key:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Meetings\Profile\MRUInternal

You specify the server list for the Meeting Workspace with the Default servers and data for Meeting Workspaces policy. However, because the policy string is complex, you should first type the entries into a text editor (such as Notepad), then paste the entire string into the policy. When you have created the server list string following the syntax described below, double-click the policy to open the Properties dialog, then select Enabled to enable setting the policy itself. In the Default field, paste the server list string you have created.

The syntax for the server list string is outlined below:

http://Server1 |Friendly name for server  1|TemplateLCID|TemplateID|TemplateName|OrganizerName|http://Server2  |Friendly name for server  2|TemplateLCID|TemplateID|TemplateName|OrganizerName|http://Server3  |Friendly name for server|

The list continues with the same structure, with an entry for each server you want to include.

There are six fields in each record:

Field 1: URL of server
Field 2: Friendly name for server
Field 3: TemplateLCID
Field 4: TemplateID
Field 5: TemplateName
Field 6: OrganizerName

Each field is separated from the next field with a vertical pipe (“|”), and each complete record is separated from the next record with a vertical pipe (“|”) after the last field (OrganizerName). Thus there are a total of six vertical pipes in each record that is included in the setting.

For the field TemplateLCID, specify a decimal value that identifies the language for the template, such as 1033 (representing English).

For the other template fields, you can use a custom template or choose a template name and the corresponding TemplateID from the following table of default templates.

TemplateName	TemplateID
Basic Meeting Workspace	Mps#0
Blank Meeting Workspace	Mps#1
Decision Meeting Workspace	Mps#2
Social Meeting Workspace	Mps#3
Multipage Meeting Workspace	Mps#4

Note

You can specify a custom template name and TemplateID instead of using a default template. For more information about creating custom templates, see “Working with Templates” in the Customization section of the Administrator’s Guide for Windows SharePoint Services on the Windows SharePoint Services Web site at http://www.microsoft.com/sharepoint/assistance.

The following is an example of a server list entry (note that OrganizerName is blank):

http://server1/sites/design_team|The Juniper  Project|1033|MPS#4|Multipage Meeting Workspace||

Configuring Meeting Workspace integration when using a POP Server

You can configure Meeting Workspace integration for Outlook when you use a POP server as your messaging server. The following configuration enables Outlook to be able to transport and persist Meeting Workspace properties for meeting organizers and meeting attendees who use a POP server.

Note

Using Outlook delegates with Meeting Workspace is not supported in POP server configurations.

To use Meeting Workspaces with a POP server, the following is required:

The POP server must be configured to support Transport-Neutral Encapsulation Format (TNEF).
Outlook meeting requests must be sent by using rich transport.

This section provides a pointer to reference information that can help you configure your POP server to use TNEF, along with steps that meeting organizers must take to help ensure that meeting requests are sent by using rich transport.

The following scenario describes the user experience when Meeting Workspaces are included in meeting requests and Outlook is used with a POP server.

The meeting organizer initiates a meeting request in Outlook and creates or links to a Meeting Workspace in the request.
The attendee receives the meeting request and sees a Meeting Workspace table in the message body, properly formatted, that includes a link to the Meeting Workspace.
The Meeting Workspace properties are persisted to the attendee’s calendar.
Attendee’s response is sent to the Meeting Workspace server.

More about TNEF support

For Meeting Workspaces to work properly in Outlook meeting requests when a POP server is used as the messaging server, the POP server must have TNEF enabled. The Meeting Workspace properties are stored in a MAPI property associated with the meeting request form. TNEF is required to transport the properties from the meeting organizer to the meeting attendee. When the meeting attendee receives the Meeting Workspace properties (after the properties are transported by using TNEF), Outlook stores the properties in the attendee’s client meeting request.

TNEF is a format for converting a set of MAPI properties—a MAPI message—into a serial data stream. The TNEF functions are primarily used by transport providers that need to encode MAPI message properties for transmission through a messaging system that does not support those properties directly. For example, an SMTP-based transport uses TNEF to encode properties like PR_SENT_REPRESENTING, which do not have direct representations in the structure of an SMTP message.

For more information about using TNEF, see the Transport-Neutral Encapsulation Format (TNEF) appendix in the Messaging API SDK on Technet at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mapi/html/_mapi1book_transport_neutral_encapsulation_format_tnef_.asp.

Ensuring that rich transport is used

Meeting organizers who want to use Meeting Workspace with POP messaging servers must ensure that rich transport—rather than plain text transport—is used to send the meeting request to recipients. Rich transport means ensuring that Rich Text Format attributes and iCalendar information are included together in the transport. This ensures that the Meeting Workspace properties attached to the meeting request persist in the e-mail transport from organizer to attendee. The meeting organizer must take the following steps to help ensure that rich transport is used for the meeting request:

Use Rich Text Format (RTF) when sending the meeting request.
Do not attach an iCalendar (iCal) to the meeting request. (The iCalendar format is a common format for Internet calendars.)

Note that these are only requirements if POP is the messaging server. If the organizer is running against an Exchange server, these options are not needed.

Set Rich Text Format

Rich Text Format for meeting requests in Outlook can be set per meeting request or as the default for all Outlook messages (including meeting requests).

To set Rich Text Format for one meeting request

In the meeting request, in the To box, double-click the user name.
In the E-mail properties dialog, under Internet format, click Send using Outlook Rich Text format.

You can instead configure Outlook to use RTF for all Internet messages (including meeting requests).

To set Rich Text Format as the default for all Internet messages

In Outlook, on the Tools menu, click Options, click the Mail format tab.
Click Internet Format.
Then in the drop-down list in the Outlook Rich Text options section, select Send using Outlook Rich Text format.

Do not send an iCalendar attachment

To specify that an iCalendar attachment is not sent with a meeting request, clear Send as iCalendar on the Tools menu in the individual meeting request. This forces the iCalendar properties to be transported in the MIME message header. (Note that this option is not available if Outlook is running against Exchange server.)

Viewing error message logs

Some Meeting Workspace errors are suppressed by default to help avoid user confusion. However, Meeting Workspace errors are written to the Windows Event Log, which can help you track down problems when troubleshooting.

Meeting Workspace users are alerted with an error message when there is a problem when creating a workspace or when a problem with the workspace arises later (for example, when a meeting workspace server fails). When problems occur separately from the process of initiating a meeting and creating a workspace, users might not understand what went wrong and what, if anything, they can do about the problem. Because these errors occur asynchronously, in some cases it may not be obvious that the error was triggered by a meeting update action.

When there are steps users can take to fix the problem, error messages about the problem are always shown to users. Error messages that will merely confuse users are suppressed by default. However, if you need to debug certain Meeting Workspace issues, it might be helpful to examine the error content in the Windows event log.

You can view the log files by using the Windows Event Viewer. To open Event Viewer, in Control Panel, double-click Administrative Tools, and then double-click Event Viewer. You can see logging information related to Outlook by clicking Application Log in the left pane.

Resources and related information

For more information about customizing SharePoint features, see the Administrator’s Guide for Windows SharePoint Services on the Windows SharePoint Services Web site at http://www.microsoft.com/sharepoint/assistance.