Working with Outlook Web App Customization
This topic describes how to register forms and user interface extensions for Microsoft Office Outlook Web App for Microsoft Exchange Server 2010.
User Permissions
To modify the files that are required to customize Outlook Web App, 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 2010 that has the Client Access server role installed where you will deploy your customizations.
Deployment Considerations
Important
Outlook Web App 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 App 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 App
Outlook Web App 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 App in Exchange 2010 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 App reads only one UIExtensions.xml file, which is located in the forms\Customization folder. To modify the Outlook Web App 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 App in Exchange 2010, you register forms to handle custom item types in the registry.xml files. To register small icons to represent custom item types in the Outlook Web App 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 App. 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.
The following table lists the supported methods for obtaining and authenticating user credentials by using 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 App 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 App Application Pool
Currently, you can run custom applications inside the same application pool that Outlook Web App uses. However, it is important to be aware that any performance, reliability, or security problems in the custom application can directly affect Outlook Web App. 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 App 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 App object. Custom forms that work with Outlook Web App can be called only for Item objects. Exchange 2007 allows custom forms to be applied to Folder objects as well; however, this is not supported in Exchange 2010. |
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 App 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 App user whose mailbox is being accessed. |
Troubleshooting Custom Forms
Outlook Web App does not open the custom form if the Outlook Web App 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 App 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 App display page. Therefore, any custom forms that are listed in the <Experience Name="Basic"> element are ignored, and are unsupported.
Customizing the Outlook Web App Theme
You can customize the theme provided in Outlook Web App to change colors, icons, and the logo. Exchange 2010 only provides a single theme, and it is presented to all users who access Outlook Web App via that server. There is no way for an administrator or user to select themes.
At this time, documentation about how to modify the theme for Outlook Web App in Exchange 2010 is not available. Many of the concepts and techniques that apply to creating themes for Outlook Web Access in Microsoft Exchange Server 2007 still apply. For more information about creating themes, see Create a Theme for Outlook Web App on Microsoft TechNet. This section describes the major differences in the Exchange 2010 theme implementation.
Working with Theme Folders
The Outlook Web App theme files for Exchange 2010 are stored in the following location: \Client Access\OWA\version\themes. The "version" portion is either "premium" or "basic". The files for the single theme that is available in Exchange 2010 are located in the Base theme folder.
Exchange 2010 also includes theme folders named "1", and "2". Although those folders do not provide additional themes, avoid modifying the folders or their contents in any way.
Before you make changes to the Base theme, copy the Base theme folder and contents to a safe location in case you need to restore the original theme. You might need to do this to troubleshoot problems you’re having with a customized theme, or to return the theme to its original form.
Working with the CSS File
Because of significant changes in the Outlook Web App architecture and internal programming, many of the classes in the Cascading Style Sheet (CSS) files have changed in both name and values. So, although the Exchange 2007 documentation can help you understand how to modify the CSS files, specific references to classes are likely to be different.
Working with Images and Sprites
In Exchange 2007, the images transmitted to the browser were all in separate files. In this implementation, each small image required the request-and-response overhead incurred in an HTTP GET. To improve network bandwidth utilization, Exchange 2010 Outlook Web App uses "sprites". All of the small images are placed into one large image file, which is downloaded to the client browser only once, reducing HTTP overhead significantly. To display one of the small images, the browser selects only a small portion of the larger image. The CSSSprites.css file defines the pixel-offsets inside the larger image where each of the small images is located.
While using sprites lowers the network traffic and improves the overall user response time, it is more difficult to modify an individual image. In addition, at this time, not all image references in Outlook Web App use the sprites. The larger images such as the logo and banner images remain as separate image files.
If your custom theme requires you to modify the images, we recommend the following flow as being more reliable and less error-prone. First, locate the separate image file that you want to change. Then, using the larger sprite image and the CSS file, determine where in the sprite that image is located. Then, modify the separate image file and save that. Finally, copy the image data from the separate-image file into the proper place in the larger sprite file.
Working with Gradient Images and Sprites
The gradients that are used in Outlook Web App also use a sprite image file. However, determining all the places where the gradients are used can be difficult, which will make testing your changes more challenging. There are two gradient files: GradientV.png and GradientH.phg. GradientV.png contains the vertical gradients, while GradientH.png contains the horizontal gradients.