Universal client access is a big selling point for Exchange 5.0. With the new high-function Outlook client, support for shareware and commercial POP3 clients, and support for Web browsers, Microsoft has addressed a major weakness of Exchange by letting many new types of clients connect to an Exchange server. Microsoft will extend the range of clients with support for Internet Mail Access Protocol 4 (IMAP4) clients in the Exchange 5.5 (Osmium) release due at the end of 1997. (For more information about the Exchange Osmium release, see my news item, "Add the Osmium Element,")

With universal access, Web browsers can connect to mailboxes and public folders held on an Exchange server. Most browsers are potential Exchange clients. In this article, I'll look at how Microsoft has enabled access for Web browsers and investigate whether you should use the Web interface in your deployment.

Active Messaging
Let me begin by stating that the phrase "Web client for Exchange" is technically inaccurate, but it best conveys the sense of what happens. You can use any Web browser that supports frames and JavaScript to connect to a mailbox on an Exchange server. But the magic is not in frames or JavaScript. Instead, the magic is in a set of Active Server Pages (identified by the .ASP extension that differentiates them from standard HTML pages) that hold JavaScript or Visual Basic Script (VBScript) code. Active Server Pages don't use ActiveX controls because ActiveX doesn't run on platforms such as Apple Macintosh, IBM OS/2, and UNIX.

The server, not the Web browser, interprets and executes the code in Active Server Pages. You link a Web browser to Exchange through a server-side Active Messaging application. The Active Server Pages that link the Web to Exchange compose the Active Messaging application.

Supported Web Servers and Browsers
Only Microsoft's Internet Information Server (IIS) 3.0 supports Active Messaging. You can install IIS and Exchange on the same server, or you can keep them separate and connect them through the network. Also, Windows NT 3.51 does not support Active Server Pages, so you need to bite the bullet and upgrade to NT 4.0 Service Pack 3 (SP3) on at least one server to support browser access to Exchange. (You can use NT 4.0 SP2 with IIS, but the combination is buggy.) A server running NT 4.0 and IIS can provide intermediate passthrough access to Exchange mailboxes running on NT 3.51. In this scenario, the NT 4.0 server passes function calls to the Exchange server. The operating system version doesn't matter.

Although Microsoft doesn't support it, Active Messaging can access Exchange 4.0 mailboxes. However, many features, including directory access and the ability to create and send mail, don't work when a Web browser connects to an Exchange 4.0 server. You can use Active Messaging in a mixed Exchange 4.0/5.0 site. In this situation, IIS runs on a server that also runs Exchange 5.0. All the links between clients and servers take place over the network. However, Microsoft does not support Web access to Exchange 4.0 mailboxes, even in a mixed Exchange 4.0/5.0 site. If you're interested in Web access to Exchange, upgrade your servers to 5.0. The upgrade to 5.0 is simple and avoids an over complicated configuration.

Don't assume that you can connect any old browsers (even the most recent variety with stated support for frames and JavaScript) to Exchange. For instance, Netscape 2.02 supports both frames and JavaScript, but if you try to connect this browser to a mailbox, you'll get the error "JavaScript Alert: Failed to get inbox." Active Server Pages contain code that controls client logons to Exchange to block older browsers that can't provide the necessary support. Netscape 3.0 or Internet Explorer (IE) 3.02 (or later versions) work.

Configuring Connections
Exchange 5.0 installation creates a new root directory called \WEBDATA under the main Exchange server directory. Exchange allocates a subdirectory to each language. The \USA directory is the directory for English (US). All the Active Server Pages required to drive the Web client reside in a set of directories under this root. For example, the \WEBDATA\USA\PF directory holds all the Active Server Pages and graphics (.GIF) files necessary for authenticated access to public folders, and the \WEBDATA\USA\ANON directory holds the code for anonymous access to public folders.

After you install the Active Server Pages, check to ensure that the HTTP protocol is enabled on each Exchange site that will support Web browser access. Select the protocols container for the site configuration object and select HTTP. Click to see the properties for the protocol, as Screen 1 shows. On this screen, you can select whether anonymous users (people who don't have a mailbox on this server and can't establish an authenticated identity) can access public folders and browse the Global Address List (GAL).

The final step in establishing Web connectivity to mailboxes is to ensure that the Lightweight Directory Access Protocol (LDAP) is enabled on the Exchange server. Failure to enable LDAP will result in users seeing the message, "Sorry! The Microsoft Exchange Server is down or the HTTP Service has been disabled by an administrator. Please try your request again later," when they attempt to log on.

Allowing anonymous access to public folders is a three-stage process. First, you must adjust the properties for the HTTP protocol. Second, you must create a shortcut to each public folder you want to open for general viewing. Finally, you must change the permissions on each public folder to permit some level of access for anonymous users. By default, the permissions placed on a public folder allow no anonymous access. The shortcuts are an important part of the mechanism that facilitates anonymous access. Without shortcuts, each time an anonymous user attempts to access a public folder the server must navigate through a potentially very large public folder hierarchy to build a list of open folders.

Making the Connection
To access your mailbox, point your browser to a universal resource locator (URL), such as http://<server_name>/Exchange. The same URL works locally and across the wider network. Screen 2 shows a logon dialog box in progress to let a user access my mailbox.

You can insert a URL pointing to Exchange/Active Messaging in any HTML page. When someone accesses the page, IIS looks at its list of services to locate the root directory for Exchange. Typically, the root is \EXCHSRVR\WEBDATA, which contains the GLOBAL.ASA file. GLOBAL.ASA initializes the application and calls LOGON.ASP, the Active Server Page controlling the logon process. To connect, a user must enter the mailbox name (the alias or directory name is enough) and click the link to Exchange to get a password prompt. Depending on the browser, you have a choice of basic (clear text) authentication or NT challenge/response (the type of logon MAPI clients use to connect to Exchange). NT challenge/response (sometimes called NTLM) protects passwords by encrypting the client/server exchange during the authentication process. Out of the box, Netscape Navigator supports only basic authentication, and IE (2.0 or later) supports both types of authentication. You can update Navigator to support NTLM with Microsoft Authentication Proxy for Netscape Navigator (MAPN), available for download at http://backoffice.microsoft.com/DownTrial/mapn.asp. Make sure you set the IIS password authentication properties appropriately, as Screen 3 shows.

If you want to use NTLM, you must install and run IIS on every Exchange server that supports browser access to mailboxes. If you want to run IIS on one system to provide access to many Exchange servers, you're limited to basic authentication. Also, domain users need the right to log on locally to the system hosting IIS.

Communications between browsers and the Active Messaging application use standard HTTP. Active Messaging interprets the commands coming from the browser (i.e., open a folder, read a message), translates the requests into MAPI function calls, and sends them to Exchange for processing. Exchange sees the Web client as just another client and doesn't differentiate how it responds to requests. Exchange sends the results of the MAPI function calls to Active Messaging, which translates MAPI into HTML and dispatches the resulting data to the browser for display.

You can use Secure Sockets Layer (SSL) to encrypt the byte stream passing between browsers and Active Messaging. However, you must conFigure SSL before you can use it. IIS Help has configuration details. Part of the configuration process involves acquiring a key from a certification authority, such as VeriSign (for instructions, see http://www.verisign.com/microsoft).

The link between Exchange and Web browsers is usually fast. Web clients initially exchange more data with the server because the Web client must download graphics and mailbox data. Over a session, the demands that either client makes are broadly equitable, although clearly this situation varies from user to user and depends on the work done in a session. My experience with dialing in to Exchange around the world shows that HTTP is often more reliable than remote procedure calls (RPCs) across extended telephone links. RPCs tend to time out when you encounter network problems, and you can use a browser to read and send mail when the Exchange or Outlook clients show that the server is unavailable.

What Can You Expect to Do?
Table 1 summarizes the features you can expect to use with MAPI and Web clients. This table is only an overview and doesn't include all the features available in the MAPI clients.

Although Table 1 shows that the Web client lacks several features. Microsoft will address the missing features as development resources allow. For example, Exchange 5.0 SP1 (released at the end of June 1997) supports move/copy items and uploading attachments. You'll need to upgrade your server to NT 4.0 SP3 and upgrade the Active Server Pages to version 1.0b to support these new features. All the necessary code is on the SP3 CD-ROM. A hot fix is available for NT 4.0 SP3 to cure a memory leak that occurs in Active Messaging applications. Install this fix if you want to use Web clients for anything more than casual access. Hot fixes for NT are available from ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes.

Microsoft plans to include calendaring for Web browsers in the Exchange Osmium release. You can read Microsoft's public position on calendaring at http://www.microsoft.com/Outlook/documents/OWA/Web_Acc.htm. Microsoft's Exchange development group demonstrated Web-based scheduling as long ago as the Exchange Deployment Conference in September 1996. However, Microsoft wrote the prototype Web integration with Schedule+ as one large Internet Server API (ISAPI) application. Now Microsoft has rewritten the calendaring application into a set of Active Server Pages. When released, the calendaring application will support both Schedule+ and Outlook-style calendaring.

With respect to electronic forms, Microsoft intends to move from the current Visual Basic-style implementation toward HTML-based e-forms. When this change occurs, we'll have platform-independent e-forms.

The Look of the Client
By definition, the Web client's appearance is limited to what you can do with graphics, frames, and data arranged within a browser's display area. Browsers can operate under Windows but cannot take advantage of any one operating system. So independent scrolling of folders and folder contents is not possible, and the display doesn't have a menu bar. Microsoft originally called the Web connection Outlook WebView, but changed the name to Outlook Web Access in Exchange 5.0 SP1. Associating browser connections with the Outlook name is a good indication that Microsoft plans to create a family resemblance (as far as possible) across all client email software. Screen 4 shows the Web interface to Exchange.

Microsoft isn't the only company building browser interfaces for email. Screen 5 illustrates the interface for a free mail service at http://www.mailcity.com. With these services, the POP3 protocol capabilities limit the client's functionality.

Processing Mail
You use separate windows to create new messages, read mail, set options (the only option available in this release is the Out of Office Assistant), and search the directory. The windows share a common appearance and are functional. Again, some of the more extended features aren't available. For example, MAPI clients can use Ctrl+K to check addresses in a message header against the Exchange directory. The Web client waits to check address data until you attempt to send a message.

Suppose, for example, that I send a message to Daragh Morrissey, and Daragh has two addresses in the Exchange directory. The Web client detects multiple address entries, flags an error, and displays the addresses to let the sender select the correct entry, as Screen 6 shows. Ideally, the sender clicks the correct address to place it in the message. Unfortunately, with the current browser interface, you must copy the address into the message header.

The Web client correctly handles attachments and the Rich Text Format (.RTF) text in messages MAPI clients send. The Web client translates the .RTF text into HTML and displays it in the usual manner, as Screen 7 shows. The Web client retrieves attachments from the server and launches the appropriate application to process them, assuming the application is installed on the PC. In common with other Microsoft desktop applications, IE 3.0 supports Object Linking and Embedding (OLE) in-place editing, so you can view Word, Excel, and PowerPoint documents within a browser window.

Anonymous Access
Anonymous access is a method for publishing the contents of public folders to people who don't have Exchange mailboxes (e.g., during deployment projects, when people are migrating to Exchange). You can store lots of great information in public folders, and you'll want everyone to have access. You can direct users to the default logon that Screen 2 shows and tell them to click the Public Access link, or you can create your own links to specific public folders.

Exchange stores public folders in the public information store, one of the three major databases Exchange uses. The link pointing to a specific folder doesn't make much sense. But Exchange knows how to use the link to navigate through the public information store to the right folder. For example, the Exchange server I use has a public folder that holds all the messages posted to the Internet mailing list for Exchange. To create a link on a Web page to this folder, I changed the client permissions for the folder to permit read access for anonymous logons. Then I used the administration program to modify the site HTTP object and create a shortcut to the folder. I logged on with anonymous access to the server and verified that I had access to the folder. I clicked Update Page Address to retrieve the complete link for the folder. The information appeared as a URL at the top of the browser, and I copied it to the clipboard. Next I opened the HTTP source of the page where I wanted to create the link and added the following text:

<a href="http://dbo-exchangeist.dbo.dec.com/
exchange/anon/root.asp?obj=000000001A447390AA6611CD9BC800A
A002FC45A0300E181F44FDB37D011A5480020AFF54A230000000331810000
">InternetMailing List for Microsoft Exchange</a>

This address is specific to a server. The link is cumbersome, but it works.

Think of the possibilities of this functionality. You can easily publish marketing information to the Web or make technical support hints and tips from your Help desk available to users through a link on your company's home page.

Static and Dynamic Connections
Today's connections between Web clients and an Exchange server are static. The connections have none of the dynamic interaction that you see between the MAPI-based Outlook or Exchange clients. A Web browser requests data from a server and displays the information in a graphical layout. The browser then waits for the next instruction. Client-driven rules, signals that new mail has arrived, or dynamic refreshes of folder contents do not happen with today's technology. However, this situation might change soon as the HTML standard evolves. Microsoft is pushing Dynamic HTML, an extension that lets you cache data to manipulate it on a local client. The first iteration of Dynamic HTML is in IE 4.0, and although it won't immediately change the passive nature of the Web client, the advent of Dynamic HTML points to the future.

Other developments will help, too. Request for Comments (RFC) 1867 details how to perform file uploads from Web browsers to a server. (For another solution to file uploads, see Michael Otey and Kent Empie, "Using VB and HTTP to Securely Upload Files," August 1997.) Netscape Navigator was the first browser to support this standard, but a bug in the IIS scripting engine caused uploads to fail most of the time. Microsoft has fixed the IIS bug and added the client upload capability to IE 3.02 (you can get an add-on for IE 3.02 at http://www.microsoft.com/ie/download). An update to Active Messaging in Exchange 5.0 SP1 supports adding attachments to messages.

Web Browsers Deliver
Active Messaging is a neat application. Microsoft has fully exploited the potential of browsers to deliver real information in a useful manner. At the same time, the availability of a Web client provides answers to some of the problems you can experience in large deployment projects. I'm curious to see how Microsoft continues to develop Active Messaging. A dynamic, full-featured Web client is not too far away.