Customizing Outlook Web Access

Customizing Outlook Web Access

Exchange Server 2007 SP1

Topic Last Modified: 2007-11-09

This topic describes how to register forms and user interface extensions for Microsoft Office Outlook Web Access for Microsoft Exchange Server 2007 Service Pack 1 (SP1).

User Permissions

To modify the files that are required to customize Outlook Web Access, you must be logged on to a user account that is a member of the Local Administrators group on the computer that is running Exchange 2007 SP1 that has the Client Access server role installed where you will deploy your customizations.

Deployment Considerations

Important:
Outlook Web Access scans the forms folder and user interface extension for changes every hour, and when the Internet Information Services (IIS) service is restarted. We recommend that you rename the registry.xml.template file only after you have developed and tested all your custom form handling source code and other resources. Updating a registry.xml file on a production server before all the other components have been developed and tested can lead to security, reliability, and performance issues on that server.

Important:

Outlook Web Access scans the forms folder and user interface extension for changes every hour, and when the Internet Information Services (IIS) service is restarted. We recommend that you rename the registry.xml.template file only after you have developed and tested all your custom form handling source code and other resources. Updating a registry.xml file on a production server before all the other components have been developed and tested can lead to security, reliability, and performance issues on that server.

Deploying Your Custom Forms

When you are ready to deploy your Outlook Web Access customizations, create the custom form folder and copy all the source files and resources first. Your last step should be to rename the registry.xml.template file or copy the registry.xml file to the correct location. This will help prevent problems with users seeing the updated forms and user interface files before the custom form handling software is fully implemented.

If you are deploying the custom forms handling application to multiple Client Access servers, create all the custom form folders and copy the files to each Client Access server first. Then, when all the files are in place, copy the registry.xml files to each server.

Deploying User Interface Customizations

When you are ready to deploy your user interface extensions, copy the modified UIExtensions.xml file to all the affected Client Access servers.

Restarting Outlook Web Access

Outlook Web Access will automatically detect new and updated forms registrations and user interface extensions each hour. You can also reset IIS if you want the server to immediately recognize your changes.

Because this can cause sessions for users who are logged on to be disconnected, we recommend that you wait for Outlook Web Access to automatically detect the changes.

Storage Considerations

Outlook Web Access in Exchange 2007 SP1 provides a template file that is named registry.xml.template in the ClientAccess\Owa\forms\Customization folder inside the Exchange installation folder. To create and register a custom form, create a new folder inside the forms folder, and copy the registry.xml.template file into that folder. Make your changes to the registry.xml.template copy, and then rename the file to registry.xml

The UIExtensions.xml.template is located in the ClientAccess\Owa\forms\Customization folder inside the Exchange installation folder. Outlook Web Access reads only one UIExtensions.xml file, which is located in the forms folder. To modify the Outlook Web Access user interface, copy the template file into the forms folder, make your changes, and then change the name of the file to UIExtensions.xml.

In Outlook Web Access in Exchange 2007 SP1, you register forms to handle custom content types in the registry.xml files. To register small icons to represent custom content types in the Outlook Web Access user interface, include a Mapping element inside the SmallIconMappings element in the UIExtensions.xml file.

Code for your custom form applications is typically located in a subfolder inside the ClientAccess\Owa\forms folder. For example, you might name the folders after the registered content classes, and store all the forms that handle items of that content class in the same folder.

Authentication Considerations for Custom Applications

Several authentication options are available for custom applications that are integrated with Outlook Web Access. The method that you select depends on whether your application must access information that is stored in Exchange.

When an application requires access to data that is stored in Exchange, it must pass the user's credential information to the Exchange APIs. In most cases this will be either Exchange Web Services in Exchange 2007, or WebDAV, which is available in Microsoft Exchange 2000 Server and later versions of Exchange Server.

The following table lists the supported methods for obtaining and authenticating user credentials with Exchange.

Authentication methods

Method	How to Obtain User Credentials	Pros and Cons
Publish custom application as single sign-on (SSO) by using Microsoft Internet Security and Acceleration (ISA) Server 2006.	Retrieve the ISA firewall access token, and pass that to Exchange.	ISA 2006 might not be part of your organization's regular operations.
Deploy the custom application inside the Outlook Web Access Application Pool.	Use the already-accepted Exchange user credentials that are available in the current IIS user context.	Application does not have to handle users who are logging on as a different Windows user. Design and quality problems in the custom application can affect server performance, reliability, and security.
Deploy the application on a different server and create a trust relationship for server-to-server authentication.	Obtain the credentials from the IIS user context.	This method does not affect the performance of the Exchange server. The custom application will have unrestricted access to Exchange data, which can lead to potential security concerns.
Prompt for user's Exchange credentials.	Prompt the user for their Exchange or other logon credentials.	Inconvenient to have users reenter their user name and password. May be required if the application requires different credentials to access non-Exchange data.

Running Custom Applications in the Outlook Web Access Application Pool

Currently, you can run custom applications inside the same application pool that Outlook Web Access uses. However, it is important to be aware that any performance, reliability, or security problems in the custom application can directly affect Outlook Web Access. This can affect all users, not only those who are using the custom application.

URL Parameters

When you design a custom form, information about the item or folder is passed to the custom form .aspx page in the HTTP GET request.

The custom form locates and retrieves the data, whether it is actually stored in Exchange or in some other location. Similarly, the custom form modifies, saves, and sends the data as appropriate.

To provide context to the custom form request, Outlook Web Access passes parameters in the GET URL. The following table lists the parameters that Outlook Web Access passes.

Parameters that are passed in the GET URL

Parameter	Example	Description
ae	ae=Item	Application Element. Defines the type of Outlook Web Access object. Custom forms can be called for Folder and Item objects.
a	a=Open	Action. Describes the type of action to perform on the object.
t	t=IPM.Note	Type. Defines the content class type of the item.
id	id=RgAAAADAOYRcvwRy…	Identifier. Provides the Outlook Web Access identifier for the item. The application should use the Exchange Web Services method to convert the id value into a value that Exchange Web Services uses.
s	s=Draft	State. Describes the current state of the item. This parameter is optional. For e-mail messages, this value is typically Draft.
ea	ea=user@example.com	E-mail Address. Provides the short Simple Mail Transfer Protocol (SMTP) e-mail address of the Outlook Web Access user whose mailbox is being accessed.

Troubleshooting Custom Forms

Outlook Web Access does not open the custom form if the Outlook Web Access administrator enables segmentation and disables features that your form requires. If this occurs, verify that the features that you specified in the RequiredFeatures element are named correctly and are actually required. In addition, contact your administrator to determine whether they have intentionally disabled the features that you require.

Custom Forms in Basic Mode

In Outlook Web Access Premium mode, the message-composition window and full message-viewing window opens as a separate Web browser window. In Basic mode, all operations use the same Web browser window. The custom application has no supported way to return to the previous Outlook Web Access display page. Therefore, any custom forms that are listed in the <Experience Name="Basic"> element are ignored, and are unsupported.