Microsoft Corporation
January 1999
Summary: This article covers performance characteristics of Microsoft® Outlook® Web Access (OWA), deployment strategies, understanding the profile of a user population, hardware sizing and performance monitoring, security, and troubleshooting. Also covered are Active Server Pages (ASP) files of Outlook Web Access and how Outlook Web Access can be customized and extended. (17 printed pages)
Outlook Web Access Architecture
Extending Outlook Web Access
Performance Issues
Deployment Strategies
Monitoring and Troubleshooting
Security and Authentication
Additional Resources
Figure 1 is a high-level diagram of the Microsoft® Outlook® Web Access (OWA) architecture. Microsoft Exchange Server; Microsoft Internet Information Services (IIS), Windows NT® Server's built-in Web server; the scripts; and the Collaboration Data Objects (CDO) library are all server-side components. The only client-side component is the browser.
Figure 1. Outlook Web Access architecture
The IIS component should be version 3.0 or 4.0. If Outlook Web Access is running from Microsoft Exchange version 5.5 with Service Pack 1, version 4.0 of IIS is needed. A number of optimizations for IIS 4.0 in the current code base exist, mainly concerning Secure Socket Layers (SSL). Upload and lang are two dynamic-link libraries (DLLs) added to the IIS server when Outlook Web Access 5.5 is installed. The upload component supports RFC1876 file uploads, or all e-mail attachments. When a client is running Outlook Web Access and wants to attach a Microsoft Excel or Microsoft Word file, it is sent to the server as part of an RFC1876 upload.
The lang DLL accommodates multilingual servers. This allows a single server to have script sets for United States English, French, German, Japanese, and other languages. Based on the accepted language header sent by the browser, the server will choose the correct set of scripts. Note that if a change is made in the United States script, the same changes will need to be made in the other language scripts as well.
The Outlook Web Access scripts essentially constitute the entire Outlook Web Access program. As a service to the user community, Microsoft ships the Outlook Web Access source code.
CDOs and CDO-HTML are two of the component CDO libraries used by the ASP page scripts to connect to the Exchange service. CDO provides an object library, which allows Outlook Web Access to communicate with Exchange Server and take advantage of the server's collaborative capabilities. CDO allows developers to build their own collaborative Web applications in the same way that Microsoft uses CDO to build the Outlook Web Access client.
Global.asa—To find the Outlook Web Access script directory structure, look under the virtual root, which is normally under Exchsrvr/webdata. See Figure 2. This root contains a global.asa file with subroutines used to control six operations: when an application starts, when a session begins, when a session ends, when a page is loaded, when a page is discarded, and when an application ends.
Figure 2. Outlook Web Access script directory structure
An application starts in ASP pages when the first Web browser hits it for the first time. In the application start component, a few variables can be set up that have an application-level life span. An Outlook Web Access hit counter may be added here, for example, to count the number of sessions started, abandoned, and so on, in Outlook Web Access.
Another interesting element of global.asa is the session start. This instantiates all objects for a particular user session. By creating objects in a session scope, these objects are allowed to be customized for each user of the Web application. In the case of Outlook Web Access, individual session information, such as Exchange Server logon, is stored in session variables.
Lang—Languages are at the next level. If Exchange Server 5.5 is installed with or without Service Pack 1, only United States will appear. If other language packs are installed, additional languages will appear.
Constant.inc—A file called constant.inc is at the next level. Constant.inc contains the constants that define friendly names for properties on a server running Exchange Server. About ten lines of code are interesting to modify, but the rest should be left alone. This file contains a group of string constants that are the names of objects co-created in other scripts that cause CDO-HTML to function. In the first ten lines, however, things like a local password expiration date can be changed. In the Windows NT operating system, the default password expiration time is 45 days; in Outlook Web Access, it is 14 days. This number determines how many days before password expiration and is shown to users in a pop-up message.
Another thing that can be changed in constant.inc is the amount of data returned when resolving names. If a very small address book is used, it may be appropriate to let users have 100 return values when they enter an ambiguous address; the default is 50. If a very heavily loaded directory is used, an option may be to trim this back and return the ten closest matches.
Utility Files—Beneath the constant.inc file is a set of directories that falls in two categories: major frame components and utility directories. They contain no content to which a URL would ever point, but they are libraries. The lib directory, .inc and .include files are stored here. The way information is returned to the screen, how it is formatted, and the resolution routines happen in these lib directory files. The images directory contains the same information for .gif images. The graphical interface of Outlook Web Access is changed in this directory. Again, these changes must be replicated for each language supported.
Help—The help directory contains the help frames. Find-user, Calendar, Contacts, and Inbox are major items on the navigation bar, and are the topmost frames for each navigation component. This area can be used to change the shape of those frames, their placement, or the appearance of components within those frames.
Undocumented configuration parameters—The Outlook Web Access source code can be searched for config parameters in the .inc and .asp files. Several lines will appear that say: If session.config parameter=zero, then some value gets a default. The default may be changed, but it is not recommended. These parameters are read from the registry and defaulted if missing. If changes are made to these, the settings for Outlook Web Access will also change. Some of these registry settings include the default timeout for anonymous and authenticated users.
The most interesting places to customize the Outlook 98 messaging and collaboration client are located from forms on down.
One of the beauties of Outlook Web Access is how easily it allows Exchange data to be exposed to the outside world. Developers can make three types of changes:
Note, however, that modifications are unsupported by Microsoft. Microsoft Product Support will be helpful with minor issues, but custom applications are the responsibility of their creators.
Several steps are involved in exposing a Microsoft Exchange Public Folder to a Web page. First, set the permissions and publish it for anonymous access. To set permissions for anonymous access, open Outlook, select the folder, and select the permissions tab on the properties page. Select the anonymous user account in the permissions page, and set the desired permissions for that default user. For example, for a discussion application, anonymous users can be allowed to create and read items in the folder.
To publish the folder for anonymous access, go to the Microsoft Exchange Administration program. After opening the Administration program, go to the Configuration container, then the Protocols container, and finally to the HTTP protocols property sheet. Once the HTTP property sheet is open, go to the Folder Shortcuts tab, and add the folder to be published.
When users connect anonymously to Outlook Web Access, any folders published using this method will be listed so users can select them as shown in Figure 3.
Figure 3. Anonymous user view in Outlook Web Access
As part of Microsoft Exchange, Microsoft ships a Frame Set Distributed Transaction Coordinator (DTC), which allows publish folders to be published easily to a Web site. A design-time control is simply a control that writes HTML and ASP code. By completing a few parameters, the same page can be created automatically, without learning query-string parameters.
To use the DTC, first install it from the Microsoft Exchange 5.5 CD-ROM. The DTC can be found at the path: CDROM\support\collab\framedtc\fssetup.exe. Once the DTC is installed, Microsoft Visual InterDev® Web development system can be installed. To use the DTC, bring up the Toolbox in Visual Interdev 6.0 (please note that the DTC also works with Visual Interdev 1.0). Right-click the Toolbox, and select Customize Toolbox. Find FrameDTC.Frameset, and add it to the Toolbox. A Toolbox should appear that is similar to the one shown in Figure 4.
Figure 4. Visual Interdev Toolbox with the Frameset DTC
Once the DTC is added to the Toolbox, use a drag-and-drop operation to move the DTC into the Web page. Next, open the property sheet for the DTC by right-clicking it and selecting properties. From the property sheet, it is possible to select the Outlook Web Access server to which it will point, the preferred type of authentication, or the folder that will be published out to the Web. The properties page for the DTC is shown in Figure 5.
Figure 5. dtc properties.jpg
The final step is to see how the folder looks when published. An example folder is shown in Figure 6.
Figure 6. Final results after using Frameset DTC
The most common misconception about Outlook Web Access is that it is a thin client, when in fact it is a Messaging Application Programming Interface (MAPI) server that provides access to thin clients, or the browser. First, the server maintains multiple MAPI sessions, which incur certain overhead.
The ASP page platform is powerful and flexible, which brings limits. Specifically, the interpreted languages are accessible and easy to modify; but they are not compiled, which carries performance costs. Also, the server must manage the client state for every user connected, and it impersonates security context for each user. This requires additional resources at the operating system level, within IIS and ASP pages.
Last, the rich feature set in Outlook Web Access, comparable to the Outlook feature set, is rendered at the server. This is workload taken off the client but still taxing to the server.
It is important to note three performance implications associated with Outlook Web Access.
For the most efficient deployment of the most users per server, it is recommended that Outlook Web Access is moved off the Exchange server and deployed separately on proxy servers, so that requests are forwarded to Exchange. Consider Outlook Web Access and Exchange as two different workloads. The Exchange server is designed to deliver content and data, and the Outlook Web Access server handles client workloads with different characteristics best suited to the client's server. As the number of users scales up, Outlook Web Access servers can be added. See Figure 7.
Figure 7. Deployment strategies topology
Outlook Web Access capacity planning involves a great many variables; user profile is the most significant. Whether or not Secure Socket Layers (SSL) is being used has an impact, as does the Outlook Web Access server hardware. The key point is to use smaller front-end servers separate from the Exchange server.
The ideal hardware for an Outlook Web Access server contains a single or dual-processor 200 MHz Pentium Pro processor with 256 megabytes (MB) of RAM and a fast link to Exchange Server and a Backup Domain Controller (BDC).
Microsoft's published figure for how many users an Outlook Web Access server should support is 800 concurrent users. However, this figure is predicated on a specific light user profile and will not apply to every organization's Outlook Web Access deployment. There are no simple rules for number of users an Outlook Web Access server can support. Start with a trial deployment, and attempt to understand the user profile. Then, monitor performance. Looking at counters in the performance monitor will give specific data on performance issues and how many more users can be accommodated. If performance problems continue, engage Microsoft Consulting Services for tools that will allow user profile information to be extrapolated and that will gauge deployment.
Outlook Web Access may be used in many different ways for many different reasons. The roving user will typically have a slow link. A traveling user might connect through a modem. A dial-up user will typically connect in the evening and stay connected for a shorter session. A mixed-mode user, using Post Office Protocol (POP) or Internet Mail Access Protocol (IMAP) protocols as the primary client, will lead to a lot of abandoned sessions. Then, some users will be on Outlook Web Access all the time, opening several browsers and reading Public Folders or e-mail. Public kiosks, typically with anonymous access, are another heavy-use scenario.
These usage scenarios create different performance characteristics. A typical company will have a different mix of these profiles.
The key vectors characterizing user profile are length and number of sessions. This is the scalability limit of Outlook Web Access and is affected by how many times people log on and how long sessions last. If users are connecting and logging off, sessions will be significantly shorter. If users are connecting multiple times and abandoning multiple sessions, the total session time grows significantly. Under heavy loads—approaching the scalability limits of Outlook Web Access—session cleanup is deferred, which leads to problems. Objects on the server are not destroyed until a later time, which causes more memory usage on the server.
The frequency of actions will obviously affect the user profile. How many mail messages are people reading? How many times did they refresh? How many times are they checking mail? The Outlook Web Access features used are another variable impacting performance. The number of ASP and remote procedure call (RPC) requests vary per action. For example, Move Item is a multi-step action requiring many ASP requests that are costly in terms of MIPS.
Understanding the user profile is key. Look at total number of sessions per day, total number of reads (message bodies rendered), the average session duration, and the actions that are not exposed in the performance monitor. Some of these actions are Move Item, Find User, and Change View. Work with Microsoft Consulting Services, if necessary, to understand all Outlook Web Access activities.
The Outlook Web Access Capacity Model is a Microsoft Consulting Services tool used to assist customers with large Outlook Web Access deployments. It requires an understanding of the user profile and can give an idea of how large the Outlook Web Access server can scale based on a user profile. However, it is not a replacement for a trial deployment or careful performance monitoring.
After twenty Outlook Web Access servers are deployed, how does an Outlook Web Access server inform users which server to connect to? It can be done manually, but it makes the environment harder to administer. A better route is to redirect a user from a separate virtual root.
First create a virtual root—Outlook Web Access—on a server. Every user can point to that virtual root. There is no Outlook Web Access code inside; rather, it is simply a redirect mechanism. A file can exist to randomly redirect users to specific Outlook Web Access servers. Once redirected, all network and ASP traffic will happen on the redirected server. As users start to create shortcuts and save bookmarks to favorites, for specific Outlook Web Access servers, they will go back to the server to which they were redirected. Depending on the redirection code that is written, simple load balancing can be provided across Outlook Web Access servers by using a round-robin method.
If a more sophisticated method is preferred, a property in the DS schema called folder-pathname allows Exchange to send a URL to a POP3 mail user. Exchange inserts this URL into an e-mail when the recipient receives a meeting request and clicks on the contained URL. By using Lightweight Directory Access Protocol (LDAP) or Active Directory Services Interface (ADSI), this property can be queried from the directory and used to assign people to specific Outlook Web Access servers.
When deploying Outlook Web Access, avoid using round-robin domain name system (DNS), since Outlook Web Access maintains session states for the users on a specific IIS server. If the user is redirected to a different server, the new Outlook Web Access server will have to reauthenticate the user and reestablish the session state.
When monitoring an Outlook Web Access server, look at the following performance counters:
With respect to throughput, examine the ASP pages object. Look specifically at the requests-per-second counter. Ten to fifteen requests per second approaches the limit of an Outlook Web Access server. Requests queued is the next metric; if there are five to ten queued requests, the load is okay. Avoid anything above fifteen requests per second. The Microsoft Exchange Web object gives further useful metrics, such as messages rendered and messages attached.
The ASP object provides number of active sessions and number of sessions timed out. Again, this provides an idea of how much overhead is being consumed in creating and deleting sessions.
To determine general system health, look at the system object, percent of total processor time (useful if there are multiple processors in the server), and the memory object-available bytes. Windows NT Server ideally keeps 4 MB free at all times.
Outlook Web Access performance problems tend to fall into two categories: long client latencies (due to either the Exchange server or the Outlook Web Access server being overloaded) and unbounded queue growth. The latter occurs when the ASP's requests queue becomes overloaded. This can create context-switching and prevent the server from servicing any requests. Be sure to monitor for both of these in Outlook Web Access deployments.
In probing Outlook Web Access problems, performance-related or otherwise, check the status of Inetinfo or the W3SVC service. Is it serving HTML files? Is it serving ASP files? Can it be cleanly shut down? These vectors often provide an indication of the server's overall state and health.
The Event Viewer in the application log is where Outlook Web Access logs messages. Check there for information indicating that Microsoft Product Support will need to provide assistance.
IIS logs also provide information on specific requests made through Outlook Web Access. These logs help in narrowing down the precise train of events leading up to a problem. If a hang or crash occurs, the exact request that caused the problem can be located, which is again, a useful troubleshooting tip for Microsoft Product Support Services (PSS).
Last, performance monitor logs provide a good historical picture of what is happening on Outlook Web Access servers. Be careful about using Microsoft's perfmon tool to view live data. Loads fluctuate, making any particular snapshot an unreliable generalization. Use perfmon to record at least an hour or a day's worth of information.
Microsoft strongly recommends not trying to run all messaging components on a single server, unless it involves a small departmental Exchange server. Outlook Web Access works better if the IIS and Outlook Web Access loads come off the server running Exchange Server. When that is done, security concerns are raised.
The deployment shown in Figure 8 allows traveling executives to access their Outlook Web Access mailboxes. The firewalls between their laptop computers and the IIS and Exchange servers need to pass HTTP, and the only requests passing between the clients and the IIS server are HTTP requests. No other network traffic passes from the client to the server.
Figure 8. Planning for network security
If Windows NT Challenge/Response (NTLM) authentication is used for the browser, for example, users do not need to enter their user names and passwords. A pathway to the domain controller needs to be established, so users can get their credentials from the domain controller. If a pathway is not provided for this authentication, NTLM authentication will need to be disabled.
If a firewall is placed between the IIS server and the Exchange server, both Exchange RPC and Windows NT authentication must be passed, since the IIS server will need to connect to the Exchange Server through RPC through the firewall. In this scenario, RPC communications are allowed through the firewall. See Figure 9.
Figure 9. Firewalls between IIS server and Exchange server
The three primary authentication mechanisms are: basic, NTLM, and basic through SSL. Microsoft doesn't consider anonymous to be an authentication method.
The advantages of basic authentication are broad browser support and the ability to access all Exchange resources, no matter where they reside. The disadvantages are that basic authentication is relatively insecure, and it transmits user names and passwords over the wire in a weakly encrypted fashion. Somebody doing packet-sniffing or watching the packets through the wire could possibly capture a user name and password.
With NTLM authentication, no pop-up window asks users for a user name or password, which is less confusing to users. It is also relatively secure, since items are not sent in the clear. And, it is difficult to sniff any user names or passwords. However, NTLM authentication is not supported by all browsers, and it only allows access to local resources—the biggest drawback. Only one network hop exists between the computer gathering the information and the computer using the information; the requesting machine cannot proxy a request to another. This causes problems for many people; so in Outlook Web Access 5.5 installed under IIS 4.0, NTLM is automatically disabled. If NTLM authentication is preferred, everything must be placed on a single server.
Figure 10 shows an NTLM authentication setup. The user starts the browser, the browser grabs the credentials from the desktop, and hands them directly to the IIS and Exchange servers (everything is on one server). Four servers are shown, because the load-balancing strategy is to put an Outlook Web Access on every Exchange server and point users at specific instances of Outlook Web Access on specific mail drops. A number of administrative problems exist with this authentication method, not to mention the multiple points for potential performance bottlenecks that come when many resources try to compete for the same computer.
Figure 10. NTLM authentication
Basic through SSL is a good compromise between the other two authentication methods. SSL is not an authentication mechanism but rather a security mechanism for data transferred over the wire. The advantages are that it is supported by most browsers, it can access all Exchange resources, and it is very secure. The only downside is that it still presents the authentication pop-up that requires users to enter names and passwords. Also, basic over SSL comes at a price, because it involves a great deal of overhead in encrypting and decrypting packets. See Figure 11.
Figure 11. Basic authentication via SSL
Microsoft does not consider anonymous an authentication mechanism, but simply a strategy for letting users access Public Folder and Directory content. The issues discussed under the other authentication methods do not apply. Users may only access unsecured resources to which the administrator allows access.
For additional information on optimizing and extending Outlook Web Access, consult the following resources:
Microsoft Exchange Samples Site at TechNet Web Premium Area
http://technet.microsoft.com/reg/downloadhttp://msdn.microsoft.com/exchange
MSDN Online Web Workshop
http://msdn.microsoft.com/workshop/
CDO documentation and samples
www.microsoft.comhttp://msdn.microsoft.com/exchangedevelopers.htm
CDO community resources
http://cdolive.com/start.htm
http://www.outlookexchange.com/
Outlook Web Access deployment and troubleshooting
--------------------------------------------
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, the BackOffice logo, Outlook, Visual InterDev, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA