Customizing Outlook Web Access
Topic Last Modified: 2009-07-16
This topic describes how to register forms and user interface extensions for Microsoft Office Outlook Web Access for Microsoft Exchange Server 2007.
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 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 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 when IIS is restarted.
Note
An IIS restart can cause sessions for users who are logged on to be disconnected.
Storage Considerations
Outlook Web Access in Exchange 2007 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\Customization folder. To modify the Outlook Web Access user interface, copy the template file in the forms\Customization folder, make your changes, and then change the name of the file to UIExtensions.xml.
In Outlook Web Access in Exchange 2007, 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.
| Method | How to Obtain User Credentials | Pros and Cons |
|---|---|---|
Publish custom Application as Single Sign-on using Microsoft Internet Security and Acceleration Server 2006. |
Retrieve the ISA firewall access token, and pass that to Exchange. |
ISA 2006 might not be part of your organization's normal 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 deal with users logging in as a different Windows user. Design and quality problems in the custom application can impact server performance, reliability and security. |
Deploy the application on a different server and crate a trust relationship for server-to-server authentication. |
Obtain the credentials from the IIS user context. |
No performance hits on the Exchange server. The custom application will have unrestricted access to Exchange data, leading 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.
| 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.