Outlook Web Access (OWA) is a Web-based client that lets users access their Microsoft Exchange mailbox from a Web browser. Although OWA isn't a replacement for the Microsoft Outlook client, it is a feature-rich Web-based substitute for users who are connecting remotely over slower—than—LAN speed connections.
To ensure that your OWA implementation provides trouble-free Web-based connectivity to your Exchange 2000 Server environment, you need to understand OWA's features and limitations and know how to configure the product optimally for your situation. Let's review OWA for Exchange 2000's (OWA 2000's) features and limitations, what's new in this version, and the default configuration. The articles in the Web-exclusive "Related Reading" box provide a deeper look at some OWA features.
Features and Limitations
When Microsoft first released OWA for Exchange, the product was clunky at best and, to most users, downright unusable. However, with each Exchange service pack, OWA became more stable and feature rich. With Exchange 2000, OWA has reached the point at which most users will find it a valid alternative to the Outlook client when they're accessing their mailbox from a low-bandwidth, remote connection. For users who need little more than basic messaging or who move between workstations, OWA might even become the preferred client. OWA's features include an improved UI, a new architecture, direct URL access, better control over access, and the capability of using virtual servers and front-end servers.
User interface. OWA 2000 closely resembles the Outlook client interface, as long as the user is accessing it through the Microsoft Internet Explorer (IE) 5.x browser. Only IE 5.x supports the extensive use of client-side scripting, Dynamic HTML (DHTML), and XML that OWA uses to provide a rich and intuitive user environment. IE 5.x also provides drag-and-drop capability, right-click context menus, tree-based folder display, preview pane display, embedded items (i.e., contacts and messages within the email message), public folder access to Calendar and Contacts subfolders, and Kerberos authentication.
To maintain backward compatibility, OWA works with other browsers (e.g., Netscape, earlier IE versions). However, because these browsers don't fully support technologies such as DHTML and XML, the interface is a lot less rich. IE 5.x helps you minimize user training and complaints because users see a Web-based interface that closely resembles the messaging client they currently use. Figure 1 shows the interface difference between an IE 5.x and a Netscape browser. As you can see, the interface using IE 5.x has a look and feel like the desktop Outlook client, whereas the Netscape interface is so different and feature poor that most users will decline to use it. Some features that the IE 5.x interface has that Netscape lacks are drag-and-drop capability, folder views, and smart windowing for items such as the address book.
New architecture. Beyond the user experience, OWA 2000 is dramatically different from its Exchange 5.x predecessors. With Exchange 5.x, OWA uses Active Server Pages (ASP) scripts to communicate directly with the Exchange server, which runs Collaboration Data Objects (CDO) and Messaging API (MAPI). Versions earlier than OWA 2000 use the IIS server for most of the script and MAPI processing, which limits the number of users that can be serviced at one time because of the processor resources that the server needs. Larger organizations must load-balance several OWA servers to provide their users with reliable and timely access.
OWA 2000's new architecture is more streamlined and can host many more simultaneous user connections. OWA 2000 is no longer part of IIS; it now resides in the Microsoft Web Storage System (WSS) and uses IIS only to receive and forward user requests. Although IIS still uses HTTP, the elimination of ASP scripts and MAPI management greatly reduces server processing so that one server can handle many more client sessions.
Direct URL access. OWA 2000 now provides direct-named URL support for folders and resources within the Exchange Information Store (IS). OWA 5.x uses a long, complex globally unique identifier (GUID) embedded within the URL for direct folder support. This scheme in older OWA versions makes direct-resource connection difficult for most users and Web administrators. OWA 2000 has simplified this resource request by using an intuitive plain-text URL. For example, when test user Abraham Lincoln wants to connect directly to his calendar rather than go through the default main page, he now can type
http://exchange/alincoln/calendar
Figure 2 shows this type of resource access. This feature also helps Web administrators who want to provide direct access to public Exchange resources (i.e., public calendars and contact lists) by way of links on the corporate intranet.
Control over user access. OWA 2000 also gives you better security and control over user access. The Microsoft Management Console (MMC) Active Directory Users and Computers snap-in lets you allow or deny access user by user.
By default, all users have access to OWA, and you must manually deny access within the User object. Open the Active Directory Users and Computers snap-in, then choose View, Advanced Features to see the Exchange Advanced tab within the User object. To change access to OWA, select the user, click the Exchange Advanced tab, then click Protocol Settings. This action opens a window that shows the three default protocols*HTTP, IMAP4, and POP3 *which are all available to the user by default. If you want to disallow OWA use, select HTTP, click Settings, then clear the Enable for mailbox checkbox. Figure 3 shows this check box.
Virtual servers and front-end servers. In OWA 2000, you can use virtual servers to segregate users by creating separate Web server instances. Virtual servers let you provide different security and configuration settings for groups of users (e.g., internal versus external users, organizational groups, users with different security requirements based on the type of browser or authentication they use). Users connect to these virtual servers by entering the host header name that you configured within the IIS settings. Marnie Hutcheson's article in the Web-exclusive "Related Reading" box explains host headers.
Front-end servers in Exchange 2000 act as the first point of contact when users access OWA from the Internet. Front-end servers take the HTTP client requests, use Lightweight Directory Access Protocol (LDAP) queries to Active Directory (AD) to determine the correct Exchange server to proxy the request to, then forward that request to the appropriate server. This process helps secure the Exchange 2000 environment as well as distribute the load to multiple back-end Exchange servers. The environment is more secure because the back-end server accepts HTTP requests from the front-end server only over port 80, thus eliminating multiple-port connections to your front-end Exchange and OWA server. Furthermore, the IS resides on the back-end servers, thereby eliminating the security concern caused by having the stores exist on a public server residing in the demilitarized zone (DMZ). This configuration also speeds up transaction processing on the back-end server because Secure Sockets Layer (SSL) connections are processed only on the front-end server. In the next section, I discuss the IIS configuration requirements to ensure a secure and reliable OWA implementation.
Despite OWA's features, its limitations will keep most users from using it as their primary Exchange 2000 client. Some features that are available in Outlook but not OWA include reminders, spell check, printing templates, timed message delivery and expiration, rules (except for the Out of Office Assistant), offline use, and only limited right-click context menus.
OWA is an evolving Web application, and Microsoft continually provides updates through Exchange service packs. As I write this article, Exchange Service Pack 1 (SP1) is the most current *and the recommended*service pack. OWA updates in SP1 include attachments embedded in public folder postings, the ability to recover deleted items, the ability to display week numbers in the Calendar view, the ability to use a Fully Qualified Domain Name (FQDN) to access the OWA server, and support for additional languages. You can find detailed information about the OWA features in SP1 and installation notes in the Release Notes document that comes with SP1 and online at http://www.microsoft .com/exchange/downloads/2000/SP1_RN.asp. If you've deployed front-end servers, read the notes carefully when you upgrade, specifically the information concerning the order in which you install the OWA updates.
Default Installation and Configuration
You have many design choices when you install Exchange 2000 and OWA. Let's look at the default installation of OWA on the primary Exchange server within a corporate environment.
The typical Exchange 2000 server installation includes OWA by default. OWA 2000 requires Windows 2000 and IIS 5.0. Unlike earlier versions of OWA, OWA 2000 encompasses combined applications, and you install OWA and Exchange 2000 in one operation. The installation creates four virtual directories in IIS within the Default Web Site. Table 1 shows the virtual directories and their uses.
OWA is immediately available for use when the Exchange installation is complete. Users must only open their browser to http://servername/exchange to gain access to OWA. If the Default Web Site on the Exchange server won't be used by anything other than OWA, I recommend configuring the Default Web Site to automatically forward to the Exchange virtual directory. Alternatively, you can add a default.asp page to the root of the site that includes a response.redirect to the /exchange virtual directory. This redirect lets users access OWA from http://servername. To provide the redirection, simply enter
<%
Response.Redirect "/exchange"
%>
in a default.asp page in the root of your Default Web Site folder.
User Authentication and Data Security
The only problem with the automatic installation of OWA is that most administrators mistakenly think that their job is complete when the installation finishes. However, the installation doesn't configure authentication or address data security. By default, the /exchange, /public, and /exadmin virtual directories use Basic authentication and Integrated Windows authentication. You can view and change the default authentication settings by right-clicking the virtual server, selecting Properties, Directory Security, then clicking Edit within the Anonymous access and authentication controls section.
As Figure 4 shows, IIS 5.0 offers four types of authentication: Anonymous access, Basic authentication, Digest authentication for Windows domain servers, and Integrated Windows authentication. You can't use Anonymous access for OWA because OWA requires the username and password to locate and access the user mailbox. Basic authentication allows transmission of clear-text passwords and shouldn't be used except with SSL, which I'll discuss later. Digest authentication is rarely used because it requires a Win2K domain controller (DC) to hold a clear-text (i.e., reversible encryption) listing of user passwords and is an obvious security risk. The last authentication method, Integrated Windows authentication, is the most popular choice when you're not running SSL.
Integrated Windows authentication, when used in conjunction with Win2K and IE 5.x on the client, provides the potential for Kerberos authentication and ensures that the authentication information is encrypted between the client and IIS. If the client is using a non-Win2K system, the authentication information is encrypted through the NT LAN Manager (NTLM) protocol instead.
The most secure solution is to use SSL to encrypt the entire session. Although SSL increases CPU and bandwidth overhead for establishing, maintaining, and disconnecting SSL sessions, it ensures that your authentication and the data transmission are encrypted. When using SSL, you should select both Basic authentication and Integrated Windows authentication in the virtual directory's Properties dialog box. Although just Basic authentication will work fine with SSL, it requires that users enter their authentication information each time they log on. Integrated Windows authentication allows native authentication from Windows clients, eliminating the need for users to type in their username, password, and domain each time they access OWA, as long as they're logged on to their local machine as a domain user. Integrated Windows authentication also lets disparate Web browsers access OWA while maintaining a high level of security for authentication information and session data.
If you've chosen not to use SSL certificates to encrypt the entire session *either because of the overhead that SSL incurs or the hassle of generating a certificate*you need to ensure that your authentication settings provide the best security available. Although your data isn't encrypted without SSL, you need to make sure that passwords are encrypted. Therefore, you need to use Integrated Windows authentication. This authentication method lets you use Kerberos or NTLM to keep passwords from prying eyes, and it provides authentication security without additional overhead or cost.
The disadvantages of Integrated Windows authentication are that it requires IE 2.0 or later (IE 5.x is needed for Kerberos) and it's incompatible with proxy connections and front-end/back-end Exchange 2000 server configurations. These limitations might make this method unacceptable in your environment.
The Basics
The default OWA 2000 installation and authentication configurations I've presented will help ensure that your Exchange environment remains secure and stable while providing a feature-rich interface for remote users. Now, users can get Outlook client-like access to their messages and calendars no matter where they are.
