Exchange 2000 Outlook Web Access

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Published: May 1, 2002

Updated : June 14, 2001

On This Page

Introduction
Features and Limitations
Architecture
Usage Scenarios
Planning Considerations
Installation and Administration

Introduction

Microsoft has invested quite heavily in Web technology and the implementation of that technology in all product lines. Microsoft® Exchange 2000 Server marks another step in this journey by extending back-end and client applications to support the latest advances in Web technology.

Microsoft Outlook® Web Access is a tightly integrated component of Exchange 2000. The architecture of Outlook Web Access has been completely overhauled since its introduction in Microsoft Exchange Server version 5.0. Furthermore, enhancements to the Exchange 2000 architecture dramatically affect the way Outlook Web Access works. With these enhancements, Outlook Web Access offers significantly increased scalability and functionality.

This white paper addresses Outlook Web Access in Exchange 2000, focusing especially on the architecture and deployment of Outlook Web Access.

Features and Limitations

Exchange 2000 contains a newly designed version of Outlook Web Access for increased performance and scalability. Client performance and functionality are greatly improved. Exchange 2000 includes the following new features:

• Takes advantage of advanced features of Microsoft Internet Explorer version 5.0. When accessed through Internet Explorer 5.0, Outlook Web Access closely resembles the full client interface. Outlook Web Access is also more efficient for Internet Explorer 5.0 users because it does not require communication with the Outlook Web Access server for every mouse click in the interface, as it does with other clients.

  

  Figure 1: Outlook Web Access Using Internet Explorer 5.0

• Support for embedded items. Outlook Web Access now supports embedded items such as messages, appointments, and meeting requests, as well as contacts and posts.

• Support for public folders that contain contact and calendar items.

• Support for named URLs that reference items. Although previous versions of Outlook Web Access used globally unique identifiers (GUIDs) to reference items in the Information Store, items (messages, folders, and so on) are now accessed by using a plain-text address such as https://server/exchange/mailbox/inbox.

• Support for multimedia messages. Outlook Web Access makes it easy to add audio and video clips to a message and then send it.

Outlook Web Access is not intended to replace Microsoft Outlook 2000. Rather, it provides rich messaging with less network overhead. Outlook Web Access includes ample functionality for basic messaging components such as e-mail, calendaring, and contacts.

The following table provides a quick feature comparison among Outlook 2000, Outlook Web Access 2000, and Outlook Web Access 5.5.

Feature	Outlook 2000	Outlook Web Access 2000	Outlook Web Access 5.5
Basic features
E-mail	Yes	Yes	Yes
Calendaring	Yes	Yes	Yes
Contacts	Yes	Yes	Yes
Tasks	Yes	No	No
Access to embedded objects	Yes	Yes	No
Rich text	Yes	Yes	Yes
HTML	Yes	Yes	No
Drag-and-drop editing	Yes	Yes with Internet Explorer 5.0	No
Shortcut menus	Yes	Yes with Internet Explorer 5.0	No
Offline use	Yes	No	No
Journal	Yes	No	No
Printing templates	Yes	No	No
Advanced features
Timed delivery	Yes	No	No
Expiration	Yes	No	No
Spelling checker	Yes	No	No
Reminders	Yes	No	No
Outlook rules	Yes	No	No
Single sign-on	Yes	Yes*	No

* Not available with front-end and back-end server configurations.

Client Support

• Internet Explorer 5.0. This client uses Dynamic HTML (DHTML) and a combination of Extensible Markup Language (XML) to provide a rich set of functions for collaborative applications through the browser. Internet Explorer 5.0 provides a user interface that is much closer to the full version of Outlook and includes functionality such as drag-and-drop editing between folders and a tree control to open or create new folders. When creating a message, Internet Explorer 5.0 users can use rich-text editing features to add formatting to the text.

• Other browsers. Outlook Web Access is designed to work with any browser that supports HTML version 3.2 and JavaScript. However, browsers other than Internet Explorer 5.0 minimize the use of client-side scripting and thus cannot provide the same functionality as Internet Explorer 5.0. For example, they do not support drag-and-drop editing or native Kerberos authentication1.

To take full advantage of Outlook Web Access features, use Internet Explorer 5.0. Any browser that supports HTTP version 3.2 will work, but certain features and functionality are only available with Internet Explorer 5.0. The following table compares the browsers.

Feature	Internet Explorer 5.0	Other
HTML text composition	Yes	No
Drag-and-drop editing	Yes	No
Preview pane	Yes	No
Tree control	Yes	No

In other browsers, much of this functionality is lost is a result of providing backward compatibility to browsers that do not support DHTML and XML.

Architecture

Outlook Web Access in Exchange 2000 is substantially different from the version introduced with Exchange Server version 5.0. Outlook Web Access 5.x used Active Server Pages (ASP) to communicate with the Exchange server that used Collaboration Data Objects (CDO) version 1.2 and Messaging Application Programming Interface (MAPI). The effective number of users per server was limited by the overheard needed to support interpreted scripts in ASP and to run MAPI sessions within ASP. In this context, Outlook Web Access was actually a part of Microsoft Internet Information Services (IIS).

Outlook Web Access in Exchange 2000 does not use MAPI to communicate with the mailbox store and no longer uses ASP for client access. Client access continues to use HTTP; however, Outlook Web Access is now built into the Microsoft Web Storage System and uses IIS only to receive requests and pass them to the Web Storage System.

IIS, which is integrated with the Microsoft Windows® 2000 operating system, handles incoming HTTP requests from Web browsers and sends HTTP responses from Exchange 2000 Server or Outlook Web Access. IIS receives a client request, looks at the namespace, and passes the appropriate information for the context of the URL back to the Web browser. If the server houses the Exchange 2000 database, Outlook Web Access uses a high-speed channel to access the mailbox store. If the server is a front-end server, Outlook Web Access directs the request to a back-end server using HTTP.

Accessing a Server

Clients direct specific requests to Outlook Web Access using named URLs. Often the URL, such as https://owa.microsoft.com/exchange, directs the client to the user's mailbox. However, named URLs are not limited to addressing a mailbox. You can address most functions and components of the client by defining a specific URL.

You can open a specific folder by typing the name of the folder after the mailbox name. For example, to open a calendar, type the path to the user's mailbox followed by /calendar, as in https://owa.microsoft.com/exchange/*juser*/**calendar**. Likewise, you can access the Contacts folder directly by typing the path to the client's mailbox followed by /contacts.

Named URLs are not limited merely to accessing folders. You can open any item and perform many functions by using explicit URL addressing. Many option and command verbs allow a wide range of actions. Leveraging the basic functions of named URLs can provide fast integration of Exchange with corporate intranet sites. For more information, see the Exchange 2000 Server Software Developer's Kit available at https://msdn.microsoft.com/downloads/sdks/exchange/beta.asp.

WebDAV

Internet Explorer 5.0 clients support an extension to the HTTP protocol known as WebDAV. WebDAV enables richer manipulation of data on the server than HTTP alone, allowing the client to work with data in a more intuitive manner. WebDAV can accommodate all types of content, so you can use it with many types of documents. You can potentially use WebDAV to create anything you store in a file. WebDAV includes these features:

• Overwrite protection (file locking). WebDAV allows users to write, edit, and save shared documents without overwriting another person's work, regardless of which software program or Internet service they use.

• Namespace management. Namespace management allows users to manage Internet files and directories; for example, users can move and copy files using a familiar paradigm. The process is similar to the way users manage word-processing files and directories on a local computer.

• Property (metadata) access. The WebDAV properties feature is an efficient means of storing and retrieving metadata. Metadata is information about a Web document such as the author's name, the copyright, the publication date, and keywords that Internet search engines use to find and retrieve relevant documents.

• Client side rendering. WebDAV uses XML to transfer the data from the server to the client, allowing it to move the task of HTML rendering from the server to the client. This essentially distributes the processing and, as a result, increases the capacity of the server.

• Backward compatibility. Exchange supports standard HTTP methods (GET, POST, PUT, DELETE, OPTIONS) and adds new methods for WebDAV-specific functionality. Because WebDAV is an extension of HTTP, existing methods are not changed.

You can find more information on WebDAV at https://www.webdav.org. WebDAV is defined in IETF RFC 2518.

Usage Scenarios

Outlook Web Access offers a turnkey solution to many problems that businesses face when they attempt to provide messaging to all areas of an organization. The following sections provide a description of just some of the many scenarios in which users can benefit from the functionality of Outlook Web Access.

Light Messaging

Outlook Web Access provides an excellent alternative to the full Outlook 2000 client. There are times when the use of a full client is either not required or simply not practical, such as when you want to use Virtual Private Network (VPN) for messaging access. Outlook Web Access covers these scenarios in an efficient and cost-effective manner.

You can easily use Outlook Web Access to meet the goals outlined in the Zero Administration Kit for Windows. The basic concept is that not every user in an organization requires full messaging functionality. For instance, the deployment of Microsoft Office or Outlook 2000 may not be justified for computers that function as task stations or application stations. Nor would the users of these types of workstations require enhanced messaging functionality.

Knowing the limitations of the Outlook Web Access client can help you determine which users are candidates for light messaging. In short, those users who would not normally receive Office 2000 probably do not require Outlook 2000.

Furthermore, Outlook Web Access uses HTTP for transport, making it particularly well suited for use over high-latency networks.

Roving User Support

Supporting users who move from computer to computer has always been a challenge for messaging administrators. Normally, this issue is addressed using system policies and server-based profiles that can require onerous administration and performance overhead.

Using Microsoft Windows 2000 on both the client and the server solves issues surrounding roving user support with little administrative effort.

In those instances where it is impractical to implement Microsoft IntelliMirror® management technologies, you can implement Outlook Web Access. With no client to install other than the browser and no MAPI profile to consider, Outlook Web Access is an attractive solution for roving users within the office and over the Internet.

Kiosks

The kiosk scenario places computers in strategic locations such as factory floors, common areas, conference rooms, and so forth, providing users with access to e-mail, calendaring, and other basic messaging functions. This type of solution is particularly attractive if you want to provide general access to posted public folders.

Migration

Providing continuous functionality to users during a migration is another common challenge for system administrators. Migration should cause as little disruption as possible. To this end, you can migrate small groups simultaneously, and deploy custom client configurations to achieve a period of coexistence.

Outlook Web Access is a great solution to the problems that arise from client software coexistence. Although not suitable as a full client replacement, Outlook Web Access is easily deployed and allows users to begin experiencing the power of Exchange as soon as the back end server is operational.

When used in conjunction with Internet Explorer 5.0, the Outlook Web Access interface is so similar to that of the full client that users will adapt quickly to either client after deployment.

Migration from other messaging systems to Exchange 2000 Server involves deployment considerations not encountered during a Microsoft product upgrade. Outlook Web Access again provides a good interim client access solution, which mitigates the operational impact normally associated with extended migration periods.

Planning Considerations

Although Outlook Web Access is operational with very little administrative configuration, you must plan some strategic points before deployment. The points that you must address early on are logical and physical server placement, the client authentication method, and capacity planning.

Network Security

You can install Outlook Web Access in either a single-server or multi-server environment. In a single-server environment, the client connects directly to the Exchange server that houses the mailbox. An Exchange virtual root and a public virtual root are added to Internet Information Services (IIS). These virtual roots point to their corresponding directories in Exchange.

A multi-server topology involves front-end and back-end servers, offering several choices for server placement relative to the corporate perimeter network. Back-end servers almost always reside within the corporate WAN. Front-end servers can be placed on the perimeter network, in the demilitarized zone, or on the internal network. An upcoming white paper titled "An Overview of Exchange 2000 Front-End and Back-End Topology" will cover multi-server configurations in detail.

Authentication

A number of options are available for Outlook Web Access authentication. Choosing the appropriate mechanism is usually a matter of the capabilities of the client operating system and specific security policies.

The default authentication methods for Outlook Web Access in a single-server environment are Basic and Integrated Windows authentication. You set authentication on the HTTP virtual servers configured for Outlook Web Access.

Note: Outlook Web Access does not have a button for logging off. To log off the session, the user must close the browser.

The following are the available options for authentication:

Method 1–Basic: Uses clear text to perform a simple challenge and response.

Method 2–Integrated Windows: Leverages the native security attributes of the client.

Method 3–Anonymous: Provides access to public folders that are intended for general access.

Method 4–Secure Sockets Layer (SSL): Although not an authentication method, SSL provides a secure communications channel that can be used in combination with any of the above methods.

The upcoming white paper "An Overview of Exchange 2000 Front-End and Back-End Topology" will provide more information on authentication methods in a front-end and back-end server configuration,

The following sections describe Outlook Web Access authentication in more detail.

Method 1–Basic

Basic authentication is commonly used on intranets. Unlike the NTLM protocol, which accepts established users' identification through the access token, Basic authentication relies on users to enter their user name, domain, and password to authenticate to Outlook Web Access.

Pros

Basic authentication is independent of the browser, which makes it independent of the platform.

Basic authentication allows the use of a front-end server.

Cons

Basic authentication results in the transmission of unencrypted passwords over the network, which makes it a relatively insecure method of authentication.

Users must enter their user name, domain, and password each time they log on.

Method 2–Integrated Windows

Integrated Windows authentication covers several scenarios. The optimal authentication takes place when the client is running Windows 2000 and Internet Explorer 5.0. This configuration uses Kerberos and offers the best security, efficient communication, and transparency. Integrated Windows authentication uses the NTLM protocol instead of Kerberos with other non-Windows 2000 networking clients.

Pros

Integrated Windows authentication encrypts the client's password, which provides excellent security.

Integrated Windows authentication provides native authentication from Windows networking clients and allows browser access without prompting the user for user ID and password.

Windows 2000 clients running Internet Explorer 5.0 use Kerberos.

Cons

Integrated Windows authentication does not work with browsers other than Internet Explorer 4 and 5.

Integrated Windows authentication is not available in a front-end and back-end server configuration.

Method 3–Anonymous Access

IIS allows you to create a user account that can connect anonymously. Anonymous access allows limited access for specific public folders and directory information.

Pros

All browsers support Anonymous access; it is an easy way to provide insecure access to public folder data.

A single point of configuration makes administration simple.

Cons

Anonymous access does not identify users uniquely. Consequently, you cannot track usage by user.

Method 4–Secure Sockets Layer (SSL)

SSL provides the best level of security because the entire communications session is encrypted. SSL is not an authentication mechanism itself. Rather, SSL provides a secure channel for any authentication mechanism. Although any authentication mechanism can be used with SSL, the most common implementation is Basic with SSL.

Pros

The entire communications session is encrypted.

Most browsers support SSL communication.

Cons

SSL requires a substantial amount of overhead for creating and dismantling sessions. Thus, SSL communications reduce the overall performance of the authenticating server.

With Basic, users must enter their user name, domain, and password each time they log on.

Additional Information on SSL

The widespread use of SSL and Transport Layer Security (TLS) encryption with HTTP leads many to believe that SSL and HTTP are related. In fact, SSL has nothing to do with HTTP. SSL is a transport-layer protocol developed to secure TCP/IP-based protocols such as Internet Message Access Protocol (IMAP), Network News Transfer Protocol (NNTP), and HTTP.

Basic authentication has the disadvantage of sending the user's password in clear text. SSL, however, establishes a secure communications channel between the client and the server, which allows the password to be sent securely. The drawback of SSL is the latency caused by session overhead and the additional processing required to encrypt and decrypt the session.

Capacity Planning

Although the improved performance of Outlook Web Access in Exchange 2000 eases the load on servers, planning the number of users per Outlook Web Access server can be difficult due to the high dependence on client usage behaviors. For example, calendar functions require more server processing than message functions.

Outlook Web Access is often used as a complement to full client access. In this case, a prudent figure for planning concurrent Outlook Web Access usage is approximately 10 percent of the user population.

The following sections give other suggestions for Outlook Web Access planning.

Usage scenarios

Will Outlook Web Access be used in complement to Outlook, or will all clients use Outlook Web Access? A limited Outlook Web Access deployment has fewer concurrent users and thus requires fewer resources. A full Outlook Web Access deployment expands the requirement to a multi-server environment that uses separate front-end servers to distribute the client load to several back-end servers.

Calculating resource requirements for Outlook Web Access is similar to capacity planning for a conventional Exchange deployment. Start with a pilot, and monitor usage and performance.

Performance counters in System Monitor can provide useful data about:

• Logon attempts per day

• Number of messages read

• Number of messages sent

• Session time

• Outlook Web Access connections

Note: Outlook Web Access does not have a button for logging off. To log off the session, the user must close the browser.

Topology

The topology affects the number of users served by a particular server.

If you are using multiple servers in your organization, Microsoft recommends using front-end and back-end server architecture to deploy Outlook Web Access. With this topology, the front-end server sends HTTP requests to a back-end server running Outlook Web Access. All front-end servers appear as one computer to Internet clients. The front-end server first performs a lookup in Microsoft Active Directory™ to determine which back-end server receives the request, and then relays the request to the appropriate server.

The primary advantage of front-end and back-end server architecture is the single consistent namespace. Users do not need to remember which servers their mailboxes are on, and you do not need to notify users when moving their mailboxes. The alternative to a single namespace is to provide each user with a specific server name, as you do in a single-server scenario. This complicates administration and compromises flexibility because each time you move mailboxes to another server, you must inform each user. With a single namespace, you can add and remove servers and move mailboxes from server to server, and users can still use the same URL. Creating a single namespace also ensures that Outlook Web Access remains scalable as your organization grows.

Front-end and back-end server architecture provides an additional advantage when using SSL encryption. Front-end servers can handle all encryption and decryption processing, which improves network performance by removing processing tasks from back-end servers.

Load Balancing

When you deploy multiple Outlook Web Access servers, you can balance their load manually by assigning groups of users to a particular server. Compared with other techniques, this has a substantial amount of administrative overhead because the administrator must adjust these groupings manually and monitor the results.

Round Robin Domain Name System (DNS) can degrade performance on servers that use SSL because session state information is maintained on the server. If DNS redirects the request to another server, that state information is lost and the session must be rebuilt.

The recommendation for load balancing between Outlook Web Access front-end servers is to use Network Load Balancing available in Windows 2000 or, if very high performance is required, hardware load balancing.

With Network Load Balancing, all participating server nodes receive client requests. Each Network Load Balancing server or Outlook Web Access front-end server uses a special algorithm based on the IP address of the connecting client to determine if the front-end server should handle the incoming request. If so, it passes the request up the network layer. If not, it discards the request.

Separate network interface cards (NICs) are recommended for inter-server communication in a Network Load Balancing environment. Using this private network, a heartbeat is sent between Network Load Balancing server computers so that they can adjust their algorithm for determining which requests to handle if a Network Load Balancing server comes online or goes offline.

If the heartbeat of one of the computers dies, Network Load Balancing servers are automatically taken out of rotation and others pick up their load. This provides a degree of fault tolerance for certain types of hardware and software failures.

You can use Windows 2000 Server Resource Kit utilities, such as HTTPMON, and third-party tools to monitor applications like Outlook Web Access. Upon detecting an application failure, you can take the failing computer out of the Network Load Balancing server rotation programmatically.

Installation and Administration

The installation, configuration, and administration of Outlook Web Access are straightforward tasks. Because some of the concepts in Exchange 2000 Outlook Web Access are new, gaining a solid understanding of the entire process and the relationships between the components before deployment is recommended.

Setup

Outlook Web Access is installed as part of the default setup of Exchange 2000; it requires Windows 2000 and IIS 5.0 to be installed.

The following table describes the directories relevant to Outlook Web Access installed during Exchange 2000 setup.

Directory	Contains
\exchsrvr\bin	Wmtemplates.dll, which defines the default templates used to render Outlook Web Access.
\exchsrvr\exchweb\bin	Exwform.dll, which handles form processing.
\exchsrvr\exchweb\controls	Internet behavior script and client Microsoft JScript®. This code is separated from the Outlook Web Access ISAPI application for caching by IIS and the client.
\exchsrvr\exchweb\lang	Localized versions of Outlook Web Access Help files.
\exchsrvr\exchweb\img	Graphics used by Outlook Web Access.

Exchange 2000 setup creates four virtual IIS directories that are used by Outlook Web Access.

Web virtual directory	Function
/exchweb	Stores graphics and other ancillary files used by Outlook Web Access.
/exadmin	Is used by the Exchange Administration tool to administer public folders.
/exchange	Stores the mailbox root.
/public	Contains the default public folders tree.

Server Configuration

Outlook Web Access is configured by default to allow access to users' mailboxes and the default public folder tree. However, you can configure the server to provide customized access for HTTP/WebDAV clients. You can specify items such as:

• Which users can access the server from a Web browser.

• Which authentication method(s) to allow.

• Which public folders are exposed to users.

To perform this configuration, you use the System Manager console and the Active Directory Users and Computers console in Microsoft Management Console (MMC). The changes you make are stored in Active Directory and then applied by the appropriate Exchange server.

Note: The virtual Web servers and directories that you create with the Exchange Administration tool also appear in the Internet Services Manager console. Configuration changes made in the Exchange Administration tool overwrite changes made to similar items with Internet Services Manager. Use only Internet Services Manager to make changes to items that are not available in the Exchange Administration tool.

Outlook Web Access User Management

Web access to Exchange 2000 is enabled for all users by default. To enable or disable this value you must use Active Directory Users and Computers. When View Advanced Features is enabled, you can see the Exchange Advanced tab in the user properties. On this tab is the Protocols Settings button, which allows you to modify the HTTP, Post Office Protocol version 3 (POP3), and IMAP4 access settings for the user.

Virtual Servers and Directories

Virtual servers allow you to create separate Web server instances for internal and external users, for different departments within a company, or for users with different security requirements.

When you create an HTTP virtual server, there are three areas of configuration:

• General. This configures the virtual server identification (host header, IP address, port), number of connections available to content (private mailboxes or a specific portion of the public folder tree), and logging.

  Note: The combination of identification values for each virtual server must be unique.

• Access. This configures the type of authentication used for access to secure content and whether or not the server allows Anonymous access to shared content.

• Security. This configures administrator permissions to the virtual server; it does not affect client connections.

Connecting to a Virtual Server

A browser connects to a specific virtual server by specifying https://IP Address:Port or https://host header name:Port. The port does not need to be specified if it is the default TCP port 80. The host header name should be registered as a host record in DNS, or added to the client's host file, or match the server's computer name if the connection occurs on an intranet.

When the server receives the request, it looks at the server name in the URL to determine which virtual server receives the request. If the server name specified matches the host header of a virtual server, the request is directed to that server. Otherwise the default Web server handles the request.

Disabling Virtual Servers

Outlook Web Access in Exchange Server 5.5 allowed you to enable or disable all HTTP access for Exchange on the General tab. Exchange 2000 has similar functionality. You can now stop, start, or pause each virtual server by right-clicking the virtual server object in System Manager and clicking the appropriate option. Note that you can only administer the default Exchange virtual server from Internet Services Manager.

Note: If you stop the default Exchange virtual server, you are stopping the IIS default Web server. If you want this Web server to be available but you want to eliminate Exchange access, you can remove the Exchange, Exadmin, and public virtual directories. You can also configure security to disable access. Removing virtual directories effectively disables management of public folders on that server.

For each virtual server, you can configure multiple virtual directories to point to different public folders or to the private mailbox store2. In Exchange 2000, virtual directories can be created within other virtual directories, allowing you to create your own Web-accessible hierarchy. This hierarchy can then be traversed through Web folders or used by your Web applications.

Virtual directories are similar to the public folder shortcuts used in previous version of Exchange.

Front-End Servers

To configure a front-end server in Exchange 2000, you must select the This is a front end server check box in the server's Properties dialog box, and then restart the Exchange and IIS services or restart the computer.

By making this change, you are instructing the HTTP, POP3, and IMAP4 components of Exchange to redirect all traffic to a back-end server that contains the user's mailbox. The Information Store remains intact on the server and is available to MAPI clients; however, it is not accessed by these three protocols.

It is recommended that you configure front-end servers immediately after the installation of Exchange 2000 Server.

Multilanguage Support

Outlook Web Access in Exchange 2000 supports nine languages natively: English, French, German, Japanese, Italian, Spanish, Chinese (Traditional), Chinese (Simplified), and Korean. Support for 13 additional languages will be available from Microsoft shortly after the release of Exchange 2000 Server.

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

1 Kerberos authentication can be used only with Internet Explorer 5.0 and Windows 2000.

2 Each virtual server should have a corresponding DNS alias to provide named access to the virtual server.