OWA in Exchange 2000 - 10 Apr 2001

A reason to upgrade to Exchange 2000

Many people are asking why they should upgrade to Exchange 2000 Server. Aside from the tight integration with Windows 2000 Active Directory (AD), the reason I give most often for upgrading is Microsoft Outlook Web Access (OWA) 2000. OWA 2000 offers improved performance and a better user experience than OWA 5.5.

OWA gives users direct access to their mailbox, calendar, contacts, public folders, and the Global Address List (GAL) from any Web browser that supports HTTP 1.1 (i.e., Microsoft Internet Explorer—IE—3.02a or later, Netscape 3.0 or later, or any browser that supports HTML 3.2 and JavaScript). Unlike OWA 5.5, OWA 2000 provides better server-side scalability and an improved browser client interface. Let's look at how Microsoft has improved OWA and review some tips for configuring and using OWA 2000.

OWA 5.5 and Earlier Versions
To fully appreciate OWA 2000, you need to look back at earlier OWA implementations. Microsoft first released OWA with Exchange Server 5.0. The major complaint that many users had with earlier OWA versions was performance. Microsoft built OWA 5.5 and earlier OWA versions with Active Server Pages (ASP) and Collaboration Data Objects (CDO). Those versions relied on Messaging API (MAPI) function calls to retrieve messages from the Exchange Information Store (IS) and Directory Service (DS).

Figure 1A, page 2, represents a typical OWA 5.5 session. The client Web browser establishes a Web session with Microsoft IIS. The Exchange OWA ASP files, graphics, and associated DLLs reside on the IIS server. The ASP files intercept the client requests, convert the requests to MAPI functions, and use MAPI to retrieve the messages. After the IIS server retrieves the MAPI messages, it converts the messages into HTML and passes the messages back to the user's Web browser. The magic of OWA occurs within IIS, not Exchange. Regardless of the amount of hardware you use with OWA 5.5—even on a machine dedicated to IIS and OWA—many simultaneous users can cause performance problems as the number of ASP and MAPI sessions increases.

A New Approach
Rather than attempt to improve OWA's performance by tweaking the existing code, Microsoft developers built OWA 2000 from scratch to take advantage of new technologies. The first technological improvement that Microsoft added is the standardization of HTTP-DAV, or WWW Distributed Authoring and Versioning. WebDAV consists of a set of HTTP extensions that give developers additional tools when they're using HTTP. Standard HTTP 1.1 has a simple set of commands (e.g., Get, Post). WebDAV enhances HTTP with additional commands (called methods) for file locking, document management, document properties, and folders. These commands include Copy, Move, Lock, Unlock, Search, Mkcol, Propfind, and Proppatch. For more information about WebDAV, visit http://www.webdav.org or see the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2518. Microsoft also takes advantage of XML and Dynamic HTML (DHTML) to improve performance and provide additional advanced features by offloading some rendering tasks to the client and reducing the amount of client-to-server communication. The XML and DHTML features are available only with IE 5.0 or later.

To improve performance, Microsoft has eliminated the OWA 5.5 ASP scripts and replaced them with a DLL that handles communications between the IIS server and the Exchange server. This DLL is called davex.dll on a back-end server and exprox.dll on a front-end server. Davex.dll consists of components that handle Get and Post requests as well as a dynamic renderer, a rendering engine, a template renderer, and a template cache.

Figure 1B illustrates information flow in OWA 2000 between a browser client and the Exchange server. All requests from the browser client reach the IIS Web Server service (W3Svc), which passes the requests to davex.dll. Davex.dll confirms either that this Exchange server is the user's home server or that the public folder the user is requesting is on this server. Then, davex.dll requests data from the ExOLEDB database interface (part of the Store process) through the ExIPC (also called Epoxy) layer rather than using MAPI requests. ExIPC is a shared memory space between IIS and the IS that allows fast data transfer between the two applications.

The ExOLEDB database interface receives the requests from IIS, authenticates the user, determines the type of data the user is requesting, packages the requested information, and sends it back to davex.dll through ExIPC. Davex.dll takes the information, renders the information into either standard HTML or XML and DHTML, depending on the client browser type, then passes this information back to the W3Svc. The W3Svc sends the data back to the client browser.

Features and Limitations
Some users are disappointed the first time they use the OWA 2000 interface because they're used to Outlook 2000. Although this reaction is understandable (OWA has fewer features than Outlook 2000), you can minimize user disappointment by modifying users' expectations.

Users must understand that OWA contains only a subset of Outlook 2000's features. The trade-off for reduced features is access to their email, calendar, and contacts from any computer with a Web browser without additional software or special configurations. The computer OS can be Windows, UNIX, or Macintosh. The sidebar "OWA 2000 Features and Limitations" provides details about the differences between Outlook and OWA.

Friendly URLs
One of the best improvements in OWA 2000 is the use of friendly URLs. In Exchange Server 5.5, the URLs were unfriendly because part of the URL consisted of a 92-character globally unique ID (GUID). OWA 2000 uses a URL that specifies the path to the message folder (and message) in human-readable format. For example, if you want to open a public folder on the server owa.somorita.com in technicalexchange2000, you need to type only

http://owa.somorita.com/public/technical/exchange2000

in the browser path.

Even better, if you want to open a specific message in a folder, type the subject of the message along with an Exchange message link (.eml) extension. For example, my mailbox contains a message with the subject Meeting Agenda. If I type

http://owa.somorita.com/exchange/jmcbee/inbox/meetingagenda.eml

the Web browser opens the message I requested, which Figure 2 shows. Note that in the space between Meeting and Agenda, the Web browser automatically inserted %20 because Web URLs can't contain a space. Don't forget this stipulation if you're linking to the message, or you won't get to the correct message. If a message with the title Meeting Agenda already existed in my mailbox, the second message to arrive would have a URL with ­2 appended to the end of the message subject (e.g., http://owa.somorita.com/exchange/jmcbee/inbox/meeting agenda­2.eml).

In addition to being able to open a message directly from a URL, you can now create messages, create calendar entries, forward messages, reply to messages, and post items to public folders. To create a new entry in my calendar, I enter

http://owa.somorita.com/exchange/jmcbee/calendar/?cmd

If I want to forward my Meeting Agenda message, I type

http://owa.somorita.com/exchange/jmcbee/inbox/meeting agenda.eml?cmd=reply

If a message subject includes characters such as a number sign (#), question mark (?), or asterisk (*), you can't access the characters directly from a URL unless you enter the hexadecimal value for the special character. An easier approach is to select that message from a folder list or the Inbox list. Table 1, page 4, lists some of the URL suffixes you can use for creating and managing messages through OWA 2000.

Installation
Unlike OWA 5.5, OWA 2000 isn't an optional component. All Exchange 2000 servers have OWA 2000 enabled.

The OWA installation process creates four IIS virtual directories for use with OWA clients. These directories are

The M drive maps to the Exchange Installable File System (ExIFS). The SMTP address of the Default Policy in the Recipients Policies container provides the domain-name in the Public and Exchange paths.

Error Signs and Messages
One of the annoyances you might notice when Exchange starts is that IIS occasionally generates error messages in the System event log. The messages indicate that certain paths to the M:domain-namembx or M:domain-namepublic folders weren't available. Further, when you're viewing the MMC Internet Services Manager snap-in, the Exchange, Public, and Exadmin virtual directories sometimes have a stop sign icon on them, indicating an error.

The cause of this annoyance is that IIS starts before the Exchange 2000 IS and ExIFS; thus, these paths aren't yet available. After the IS has started, OWA works properly. If the stop sign icons annoy you, can you use Internet Services Manager to stop and restart the Web default server.

Configuration
OWA 2000 is ready to use as soon as you install Exchange 2000. You can further customize OWA 2000 from either Internet Services Manager or Exchange System Manager. To fully understand the ramifications of changing OWA configuration settings, you need to understand where Exchange 2000 stores configuration information. The IIS metabase stores all IIS configuration settings, not only for the Web server but also for SMTP, Network News Transfer Protocol (NNTP), POP3, and IMAP4 virtual servers.

But don't Exchange administrators use Exchange System Manager to make changes to these Internet services? And isn't Exchange System Manager storing these changes in AD? Yes, both statements are correct. So, if you're creating virtual servers, making changes to them, and storing the configuration in AD, how do the changes get into the IIS metabase on the appropriate server?

Every few minutes, the System Attendant on each Exchange server kicks off a process called the Directory Service to Metabase. DS2MB scans the AD configuration partition for changes that affect the local server's IIS metabase. If DS2MB finds changes, it updates the local metabase. If you've used Internet Services Manager to make changes directly to the metabase, DS2MB overwrites those changes in favor of the configuration found in AD.

You configure the HTTP server through the HTTP virtual server container in each server's Protocols container in Exchange System Manager. Although you can make some HTTP virtual server changes through Internet Services Manager, you must use Exchange System Manager to make most virtual directory configuration settings. These settings include

If you don't use Exchange System Manager to make these settings, DS2MB will overwrite the settings. Figure 3 shows the configuration dialog box for the Exchange virtual directory.

You can make all other configuration settings through Internet Services Manager because the configurations stored in AD and the metabase don't overlap. These other settings include

A good rule of thumb for deciding where to make changes is to first make the change through Exchange System Manager, if possible.

Disabling OWA
You can't delete or disable the OWA 2000 default virtual server. However, after the server starts, you can stop the virtual server through Exchange System Manager, or you can stop the entire default Web server through Internet Services Manager.

You can also disable HTTP access for individual users through the MMC Active Directory Users and Computers snap-in. Using the snap-in, enable the Advanced Features display on the View menu to see the correct property tab. Locate the user you want to disable, display the properties of that person's user account, and click the Exchange Advanced property tab. Select Protocol Settings, highlight HTTP, and click Settings. To disable HTTP access for that user, clear the Enable for mailbox check box (the check box is selected by default).

To create a front-end server, install Exchange 2000, then locate that server in the server list and display its properties, as Figure 4 shows. Select the This is a front-end server check box, and reboot. (The server reconfigures IIS to act as a front-end server, and a reboot is necessary.) After the server restarts, any mailboxes or public folders on that server will no longer be accessible. If you performed this step by accident, you can reverse the process, and the mailboxes and public folders will be available again.

Authentication
Figure 5 shows the Authentication Methods dialog box. On back-end servers, OWA 2000 supports Anonymous access, Basic authentication, and Integrated Windows Authentication (Windows NT Challenge/Response). On front-end servers, OWA supports only Anonymous access and Basic authentication.

To take advantage of Integrated Windows authentication, the client must be using IE 4.0 or later. Other browser clients use only Basic authentication. Basic authentication sends the username and password in clear text. To protect the usernames and passwords of clients that use front-end servers or non-Microsoft Web browsers, you need to implement SSL.

If the user account you're currently logged on to has a mailbox associated with it in AD, OWA 2000 automatically directs you to your mailbox when you access the http://server.domainname/exchange URL. If you want to access a mailbox other than your own, type

http://server.domain-name/exchange/mailboxname

If you aren't logged on with a domain account, OWA prompts you for a username, domain name, and password.

Hardware Recommendations
Microsoft and vendors such as Compaq are only beginning to get hard-core performance data about how well OWA 2000 scales and the maximum number of OWA users that one front-end or back-end server can support. OWA 5.5 supports, at best, no more than 600 simultaneous OWA clients on super-server-class hardware (quad processor machines with 2GB or more of RAM). Similar hardware should be able to easily support 1500 to 2000 simultaneous OWA 2000 clients.

However, each user community is different and thus places different demands on server hardware. You must carefully monitor each Exchange server's performance to determine whether the server's load is excessive. The MSExchange Web Mail object contains several performance monitor counters that you can use to plot against standard performance monitor counters such as available memory, processor usage, network activity, and disk activity to determine whether OWA is exceeding your server's demands.

From my experience, even the smallest Exchange 2000 server that supports OWA clients needs a minimum of a 500 MHz Pentium III processor and 512MB of RAM. OWA performance with only a handful (fewer than 10) of OWA clients on an Exchange 2000 back-end server with 256MB of RAM was unacceptable (i.e., sometimes taking up to a minute to send a message).

OWA 2000 and Exchange Server 5.5 Mailboxes
Although OWA 2000 is one of the biggest advantages of upgrading to Exchange 2000, it must be the last component that you upgrade. Exchange OWA 5.5 can access Exchange 2000 mailboxes, but OWA 2000 can't access Exchange Server 5.5 mailboxes. You must either upgrade the Exchange Server 5.5 OWA server last or reassign the users who have upgraded to a different OWA server.

Preventing Potential Problems
OWA 2000 has a few idiosyncrasies. Here are some tips for recognizing or avoiding those problems:

A Solid Product
Although OWA 2000 is essentially a version 1.0 product because Microsoft completely rewrote it, it has proved to be a solid product. More and more companies are using OWA 2000 as their solution for remote access to mail, calendars, and contact items; some companies are using OWA 2000 exclusively as their messaging client. This move toward stateless clients is becoming popular for users who move from one machine to another or for users whose situation makes maintaining a regular Outlook client configuration difficult. As Microsoft continues to enhance the OWA interface, look for OWA to become an increasing part of Exchange users' lives.