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 \technical\exchange2000, 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 agenda2.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.