This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
This topic provides information about using Exchange Web Forms to develop messaging applications.
An Exchange Web form is a Web page that is registered in the form registry of the Exchange store. Registering a form in the form registry allows Active Server Pages (ASP) and HTML pages to be associated with a specific type of data in the Exchange store and to replace the default Microsoft® Outlook® Web Access rendering when an HTTP request for the data is made.
Microsoft currently supports Exchange Web forms. However, for long-term compatibility, we recommend that you render the Web forms by using standard ASP tags, instead of by using the Exchange form rendering tags.
Exchange Web Forms
Applications that use Exchange Web forms typically leverage the authenticated remote-access capabilities of Outlook Web Access to display information about items in the Exchange store in a manner that is not already available with Outlook Web Access. Custom forms stored in Exchange can mix-and-match functionality from the Exchange Web Forms renderer and ASP with HTML.
The Exchange form renderer provides objects that represent the form elements and their properties on the Web page. In addition, applications built by using Exchange Web forms and ASP have access to the typical ASP objects, as well as the ability to create COM object instances.
Data Access Model
The objects that are available by means of the Exchange Web form object model form a hierarchical set of objects and collections.
Exchange Web forms are scripts, and do not have threading capabilities.
Exchange Web forms are scripts that execute on the Exchange server, within the operation of Outlook Web Access.
Exchange Web forms can be used remotely by means of Outlook Web Access. However, Web forms are stored and processed on the Exchange server.
Exchange Web forms do not by themselves generate Windows Event Log entries, and do not include any predefined performance counters.
Currently shipping with Microsoft Exchange 2000 Server and Exchange Server 2003. No changes are anticipated at this time. However, to better ensure long-term compatibility, we recommend that you render the registered forms by using ASP tags instead of by using the Exchange forms renderer tags. Versions of Exchange later than Exchange Server 2003 might not include, or provide access to, this technology.
Exchange Web Forms
Languages and Tools
Exchange Web forms are HTML pages that use either the Exchange forms renderer or ASP. You can write ASP by using VBScript, Jscript, or another ASP scripting language. Client-side scripting must use a language that is compatible with the intended client.
The use of ASP.NET in Exchange Web forms is not supported.
Exchange Web forms are scripts. The Exchange Form object can be accessed by scripts. However, only scripts that are executing as an Exchange Web form can use the Exchange Form objects.
No special debugging tools are needed to debug applications that use Exchange Web forms. Note, however, that because the forms execute on the Exchange server, debugging may require the developer to have access to the Exchange server. Always use caution when allowing anyone direct access to the Exchange server.
It should not be difficult to find developers who are capable of successfully creating Exchange Web forms. However, finding developers who have first-hand experience with all the tasks involved in creating, registering, and maintaining Exchange Web forms might be more difficult.
Extending Outlook Web Access by using Exchange Web forms is discussed in the Exchange Server 2003 SDK and in the Exchange 2000 Server SDK. Use the documentation appropriate to the version of Exchange you are developing for. To access the Exchange 2000 Server SDK and the Exchange Server 2003 SDK, see Microsoft Exchange Server on MSDN.
Refer to your Exchange and MSDN subscription licensing agreements to determine whether additional licenses are required for the computers on which your Exchange Web forms are developed and deployed.
Exchange Web Forms
To use Exchange Web forms, the folder permissions must allow scripts to run, and the developer must have full access to those folders. To debug Exchange Web forms by using the Windows Script Debugger, the developer may require additional permissions to allow debugging. Use caution whenever granting permissions to run scripts on the Exchange store.
A user who has sufficient permissions to access the folder, and to register the form, must set up applications that use Exchange Web forms.
To use Exchange Web forms, the folder permissions must allow scripts to run. Use caution when granting permissions to run scripts on the Exchange store.
Built-in Security Features
Exchange Web forms leverage the security model of Outlook Web Access. Access to the folders and items that the Web form uses is controlled by permissions set on the Exchange store items.
Security Monitoring Features
Exchange Web Forms
Server Platform Requirements
Exchange Web forms are stored inside the Exchange store, and act on items within the store. To test and use Exchange Web forms, you must install and enable Outlook Web Access.
Client Platform Requirements
Base client requirements are the same as those for Outlook Web Access. However, browser-specific features used in an Exchange Web form may limit the range of compatible browsers that can be used to access the Web form.
Deploying Exchange Web forms involves copying the Web form pages onto the Exchange server and registering them. Refer to the SDK documentation for complete information about registering Exchange Web forms.
If special user permissions are granted to enable deployment and testing of an Exchange Web forms-based application, remember to review and possibly remove those permissions after the application has been deployed and tested.