TechRepublic Tutorial: Understanding Exchange 2000 Server's Outlook Web Access

Learn how to use Outlook Web Access in Exchange 2000.

Microsoft introduced Outlook Web Access (OWA) in Exchange 5.0 to enable clients to access their Exchange Server mailboxes through a Web browser. Microsoft has made some significant improvements in OWA in Exchange 2000 Server to provide better performance, the ability to support a larger number of users, and improved functionality for clients. In this Daily Drill Down, I’ll explore OWA to give you an understanding of how it works and how to implement it. I’ll cover additional aspects of OWA in future Daily Drill Downs.

Overview of Outlook Web Access
OWA provides a means for clients to connect to an Exchange server through a Web browser to access their mailboxes. Clients can send and receive messages, manipulate their calendars, and perform many—but not all—of the tasks they can perform when connecting to mailboxes through an Outlook or Exchange client. Exchange 2000 Server includes some additional features not provided by OWA in Exchange Server 5.x. Some of these features are added through OWA itself and others in combination with Internet Explorer 5.0.

OWA isn’t meant to be a complete replacement for Outlook or the Exchange client, which provide full access to Exchange Server and its features. However, OWA is useful for enabling roaming users to access the most common mailbox features when they don’t have access to their personal Outlook installation. OWA can also be a useful means for giving UNIX, Linux, and Macintosh users the ability to access Exchange Server mailboxes and participate in workgroup messaging and scheduling. Finally, OWA is a good alternative for those users who don’t need the full range of features offered by Outlook and can save the administrative and support overhead—as well as licensing costs—to deploy Outlook.

OWA’s features
E-mail is inarguably the primary function of Exchange and Outlook, and OWA naturally supports e-mail access. Clients can connect to the Exchange server, view the headers in the inbox, read those messages, send new messages, reply, and forward or delete messages. Although giving clients access to the inbox without requiring an Outlook or Exchange client is certainly an important aspect of OWA, an added benefit is the ability to delete messages without downloading them. Outlook gives you this ability through its Remote Mail feature, which enables you to download only message headers and not message bodies. This is useful when you have a corrupted message that is causing your Outlook client to hang or you have a message with a large attachment that you want to delete rather than download. You can simply connect to the mailbox with your browser, select the message header, and delete the message, all without downloading it to your client computer.

OWA in Exchange 2000 Server adds a few new features for messaging. For example, both the current and previous versions support rich-text messages, but OWA 2000 supports HTML-based messages as well. You also can access embedded objects in messages, another feature not supported by 5.x. Two new features in OWA 2000 rely on Internet Explorer 5.0: drag-and-drop editing and shortcut menus.

In addition to its messaging features, OWA enables clients to access their Calendar folders. You can view and modify existing items as well as create new appointments. OWA doesn’t give you the same level of access to your Calendar folder as Outlook or the Exchange client, but the ability to view your schedule and add new appointments is certainly useful. OWA also lets you access your Contacts folder through the Web. You can view and modify existing contacts as well as add new ones. Other new features include support for ActiveX objects, public folders containing contact and Calendar items, multimedia messages, and named URLs—rather than globally unique identifiers (GUIDs)—for objects.

Even though OWA is a useful tool for accessing your Inbox, Calendar, and Contacts folders, it doesn’t offer all the capabilities provided by the Outlook client. For example, OWA provides access to your Tasks folder (and to all your other folders as well), but it doesn’t enable you to create new tasks. Likewise, you can view the Journal but you can’t add new Journal entries. OWA doesn’t provide the means to use your mailbox offline. Other features not supported by OWA that are available through Outlook and the Exchange client are timed delivery and expiration for messages, spelling checker, reminders, and Outlook rules for processing messages.

Client options
OWA supports any Web browser that supports JavaScript and HTML version 3.2 or higher. This includes Internet Explorer 4.0 or later and Netscape 4.0 or later. However, some features rely on Internet Explorer 5.x, including the previously mentioned drag-and-drop editing and shortcut menus, as well as native Kerberos authentication. In addition, browsers that support DHTML and XML offer a richer set of features than those that do not. For example, Internet Explorer 5.x offers an interface to OWA that is much closer to the native Outlook client, including a preview pane and a folder tree for navigating and managing folders.

A brief overview of the OWA architecture
OWA in Exchange Server 5.x uses Active Server Pages (ASP) to provide communication between the client and the Exchange server. The server uses the Messaging Application Programming Interface (MAPI) to handle messaging requests. The reliance on ASP essentially makes OWA a feature of Internet Information Server (IIS) rather than Exchange Server.

Under Exchange 5.x, OWA functions primarily as a Web site hosted under IIS that uses ASP to process client requests and then uses HTTP to communicate with the Exchange server (which uses MAPI to manipulate the message store). The combination of ASP and MAPI imposes a performance overhead that limits OWA’s capabilities in Exchange Server 5.x and reduces the number of users a server can support through OWA.

Exchange 2000 Server uses a different architecture that improves performance and thereby increases the number of users that a server can support. OWA in Exchange 2000 Server no longer uses ASP but instead relies on HTML and DHTML. The client browser still uses HTTP to connect to the site, but rather than having to process a client request, IIS simply passes the request off to the Exchange server and transmits replies back to the client. OWA, rather than residing on IIS, is now integrated within Exchange 2000 Server as part of the Web Store.

The Web Store provides a single store for multiple data elements, including e-mail messages, documents, Web pages, and other data. The Web Store supports several important features, such as off-line access and remote client access, and supports multiple protocols, including HTTP, WebDAV, and XML. The Web Store isn’t specifically targeted at supporting access through OWA. Instead, the Web Store offers a richer set of features and capabilities for storing and accessing data through means other than just Outlook. For example, Microsoft originally included Web Store access in Outlook XP (the next release of Outlook) to enable Outlook clients to use HTTP to work with their message store, but dropped it due to performance problems. Through its support for multiple protocols and APIs, the Web Store opens up additional avenues for developers to extend Exchange functionality and offers alternative means of accessing Exchange data.

Authentication options
OWA provides three options for authentication:
  • Basic: This option uses clear text and simple challenge/response to authenticate access. Although it offers the broadest client support, it also offers the least security because passwords are transmitted unencrypted.
  • Integrated Windows: This option uses the native Windows authentication method offered by the client. On Windows 2000 systems, for example, Internet Explorer uses Kerberos to authenticate on the server. Other Windows platforms use NTLM rather than Kerberos. Security is better than Basic authentication because passwords are encrypted. The browser uses the client’s Windows logon credentials to authenticate on the server, eliminating the need for the client to enter the credentials again when connecting to OWA.
  • Anonymous: You can use anonymous access on public folders to simplify administration.

In addition to these three authentication mechanisms, OWA supports the use of Secure Sockets Layer (SSL) to provide additional security for remote connections.

Topology considerations for deploying OWA
If you host only one Exchange 2000 Server computer, there really aren’t many considerations for deploying the server. In a multiserver environment, however, you need to give some careful consideration to how you will structure your Exchange environment. When you provide access to your Exchange servers through HTTP (OWA), IMAP, or POP3 to users on the Internet, you should use a front-end server/back-end server scheme. The front-end server sits on the Internet, either outside the firewall or inside a perimeter firewall. It accepts requests from clients on the Internet, uses Lightweight Directory Access Protocol (LDAP) to query the Active Directory for the location of the requested resource (mailbox, for example), and passes the request to the appropriate back-end server.

A front-end server is a specially configured Exchange 2000 server. A back-end server is just a normal Exchange 2000 server. You don’t have to do anything to configure a server as a back-end server. Any server not configured as a front-end server is by default acting as a back-end server.

One of the advantages to using a front-end/back-end topology is that you have to expose only one namespace to the Internet because that front-end server functions as the point of entry of sorts for your back-end Exchange servers. For example, users might connect to to access their mailboxes. If you didn’t have a front-end server, each user would have to know the name of the server hosting his or her mailbox and enter the appropriate URL. By providing a single point of entry, you make it much easier to expand and rearrange the back-end server configuration without affecting your users. In situations where you have a high volume of traffic through the front-end server, you can set up multiple front-end servers to handle the traffic.

Front-end servers also offer a performance advantage in situations where you need to use SSL to provide additional security between the client and server. The front-end server can be configured for SSL and perform the associated encryption and decryption, removing that load from the back-end servers. This frees up additional processor time for the back-end servers to process messaging requests from clients.

The ability to place the back-end servers behind a firewall is another extremely important reason to use a front-end server. The front-end server hosts no mailboxes and therefore doesn’t expose the mail system to intrusion. By configuring the front-end server to perform authentication prior to relaying requests to the back-end servers, you considerably reduce the risk of denial-of-service attacks on your back-end servers.

When a request comes in to a front-end server, the server uses LDAP to query the Active Directory to determine the location of the requested data. The front-end server then passes the request to the appropriate back-end server using HTTP port 80. Because the front-end server always uses port 80, SSL and encryption are never used between the two, even though the client might be using SSL to communicate with the front-end server. It also means that back-end servers that listen on a nonstandard port can’t function with front-end servers. Instead, clients must connect to these servers directly, specifying the appropriate port number.

The back-end servers handle the traffic from the front-end server like any other HTTP traffic, sending responses back to the front-end server. The front-end server then passes the traffic back to the client, acting as a proxy for the HTTP traffic. Clients never know that a server other than the one they specify in the URL when they connect is actually handling the messaging requests.

Clients can use one of two methods to connect to their mailbox through a front-end server: either authenticate on the server (providing implicit authentication on the back-end server), or use explicit logon at the back-end server. In the former, clients can specify the URL of the front-end server without their account name. In the latter, clients add their account name, as in You would also use explicit logon when you need to access a mailbox that isn’t your own but for which you have access permissions. In the case of explicit logon, the front-end server extracts the user portion of the URL and combines it with the SMTP domain name to construct a fully qualified SMTP address. The front-end server then looks up the address in the AD and forwards the request to the back-end server for the user based on the information it finds in the AD.

As you begin planning how you will deploy and manage your Exchange servers in light of OWA, keep the front-end/back-end topology requirements in mind. Decide what strategy—including placement of front-end servers to firewalls—makes the most sense for your organization. I’ll cover front-end/back-end Exchange topology in detail in a future Daily Drill Down.

Configuring OWA
You configure OWA using the Microsoft Exchange Manager and Active Directory Users And Computers consoles. You also can configure certain aspects of OWA through the Internet Services Manager console, although changes you make through the Exchange System Manager overwrite changes you make through the IIS console. In general, you should use the Exchange Manager and Users And Computers consoles for most configuration tasks, using the IIS console only for those tasks not available through the other consoles. Typical configuration tasks you would perform include specifying which users can access their mailboxes through OWA, which authentication methods to allow, and which public folders are exposed to clients.

Controlling user access
By default, all users are enabled for OWA when you install Exchange 2000 Server. In many situations, you might want to limit the users who can use OWA. You do so through the Active Directory Users And Computers console. Open the console and choose View, Advanced Features.

Expand the Users branch and locate a user for whom you want to deny access through OWA. Click the Exchange Advanced tab and then click Protocol Settings. Select HTTP, click Settings, and deselect the Enable For Mailbox option. Configure any other settings as needed for the user and close the user’s property sheet.

Configuring a front-end server
If you intend to use a front-end/back-end topology, you need to tweak one setting on the front-end server to make it function as a front-end server. Open the Exchange System Manager and locate the server in the Servers branch under the server’s administrative group. Right-click the server and choose Properties to open its property sheet and then click the General tab. Select the option This Is A Front-End Server and click OK. You need to restart the Exchange and IIS services or restart the server for the change to take effect. Because the back-end servers handle requests from the front-end server like any other request, there is no configuration needed at the back-end server to enable it as such.

Keep in mind when you designate an Exchange server as a front-end server as explained above that you are directing the server to forward all HTTP, POP3, and IMAP4 traffic to the back-end server(s). The front-end server can still host an information store and even user mailboxes, but these mailboxes are accessible only through MAPI. Because the server forwards all HTTP, POP3, and IMAP4 traffic, you can’t access the front-end server’s store through any of these protocols.

Sometimes your users need to access e-mail on the network but don’t have access to Outlook or Outlook Express to do so. To solve this problem, Microsoft created Outlook Web Access in Exchange 5.0. As with most things, Microsoft improved the feature in Exchange 2000. In this Daily Drill Down, I’ve given you a quick look at OWA in Exchange 2000.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks