Connecting Web Clients to Exchange

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

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

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. Youcan use any Web browser that supports frames and JavaScript to connect to amailbox 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 .ASPextension that differentiates them from standard HTML pages) that holdJavaScript or Visual Basic Script (VBScript) code. Active Server Pages don't useActiveX controls because ActiveX doesn't run on platforms such as AppleMacintosh, IBM OS/2, and UNIX.

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

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

Although Microsoft doesn't support it, Active Messaging can access Exchange4.0 mailboxes. However, many features, including directory access and theability to create and send mail, don't work when a Web browser connects to anExchange 4.0 server. You can use Active Messaging in a mixed Exchange 4.0/5.0site. In this situation, IIS runs on a server that also runs Exchange 5.0. Allthe 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 mixedExchange 4.0/5.0 site. If you're interested in Web access to Exchange, upgradeyour servers to 5.0. The upgrade to 5.0 is simple and avoids an over complicatedconfiguration.

Don't assume that you can connect any old browsers (even the most recentvariety with stated support for frames and JavaScript) to Exchange. Forinstance, Netscape 2.02 supports both frames and JavaScript, but if you try toconnect this browser to a mailbox, you'll get the error "JavaScript Alert:Failed to get inbox." Active Server Pages contain code that controls clientlogons to Exchange to block older browsers that can't provide the necessarysupport. 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 underthe main Exchange server directory. Exchange allocates a subdirectory to eachlanguage. The USA directory is the directory for English (US). All the ActiveServer Pages required to drive the Web client reside in a set of directoriesunder this root. For example, the WEBDATAUSAPF directory holds all theActive Server Pages and graphics (.GIF) files necessary for authenticated accessto public folders, and the WEBDATAUSAANON directory holds the code foranonymous access to public folders.

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

The final step in establishing Web connectivity to mailboxes is to ensurethat the Lightweight Directory Access Protocol (LDAP) is enabled on the Exchangeserver. 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 byan administrator. Please try your request again later," when they attemptto 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 mustcreate 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 somelevel of access for anonymous users. By default, the permissions placed on apublic folder allow no anonymous access. The shortcuts are an important part ofthe mechanism that facilitates anonymous access. Without shortcuts, each time ananonymous user attempts to access a public folder the server must navigatethrough a potentially very large public folder hierarchy to build a list of openfolders.

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

You can insert a URL pointing to Exchange/Active Messaging in any HTMLpage. When someone accesses the page, IIS looks at its list of services tolocate the root directory for Exchange. Typically, the root is EXCHSRVRWEBDATA,which contains the GLOBAL.ASA file. GLOBAL.ASA initializes theapplication and calls LOGON.ASP, the Active Server Page controlling the logonprocess. To connect, a user must enter the mailbox name (the alias or directoryname 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) authenticationor NT challenge/response (the type of logon MAPI clients use to connect toExchange). NT challenge/response (sometimes called NTLM) protects passwords byencrypting 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 Navigatorto 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 authenticationproperties appropriately, as Screen 3 shows.

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

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

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

The link between Exchange and Web browsers is usually fast. Web clientsinitially exchange more data with the server because the Web client mustdownload graphics and mailbox data. Over a session, the demands that eitherclient makes are broadly equitable, although clearly this situation varies fromuser to user and depends on the work done in a session. My experience withdialing in to Exchange around the world shows that HTTP is often more reliablethan remote procedure calls (RPCs) across extended telephone links. RPCs tend totime out when you encounter network problems, and you can use a browser to readand send mail when the Exchange or Outlook clients show that the server isunavailable.

What Can You Expect to Do?
Table 1 summarizes the features you can expect to use with MAPI and Webclients. This table is only an overview and doesn't include all the featuresavailable 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. Forexample, Exchange 5.0 SP1 (released at the end of June 1997) supports move/copyitems and uploading attachments. You'll need to upgrade your server to NT 4.0SP3 and upgrade the Active Server Pages to version 1.0b to support these newfeatures. All the necessary code is on the SP3 CD-ROM. A hot fix is availablefor NT 4.0 SP3 to cure a memory leak that occurs in Active Messagingapplications. Install this fix if you want to use Web clients for anything morethan casual access. Hot fixes for NT are available fromftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes.

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

With respect to electronic forms, Microsoft intends to move from thecurrent Visual Basic-style implementation toward HTML-based e-forms. When thischange 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 dowith graphics, frames, and data arranged within a browser's display area.Browsers can operate under Windows but cannot take advantage of any oneoperating system. So independent scrolling of folders and folder contents is notpossible, and the display doesn't have a menu bar. Microsoft originally calledthe Web connection Outlook WebView, but changed the name to Outlook Web Accessin Exchange 5.0 SP1. Associating browser connections with the Outlook name is agood indication that Microsoft plans to create a family resemblance (as far aspossible) across all client email software. Screen 4 shows the Web interface toExchange.

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

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

Suppose, for example, that I send a message to Daragh Morrissey, and Daraghhas two addresses in the Exchange directory. The Web client detects multipleaddress entries, flags an error, and displays the addresses to let the senderselect the correct entry, as Screen 6 shows. Ideally, the sender clicks thecorrect address to place it in the message. Unfortunately, with the currentbrowser 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 .RTFtext into HTML and displays it in the usual manner, as Screen 7 shows. The Webclient retrieves attachments from the server and launches the appropriateapplication to process them, assuming the application is installed on the PC. Incommon with other Microsoft desktop applications, IE 3.0 supports Object Linkingand Embedding (OLE) in-place editing, so you can view Word, Excel, andPowerPoint documents within a browser window.

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

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

InternetMailing List for Microsoft Exchange

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

Think of the possibilities of this functionality. You can easily publishmarketing information to the Web or make technical support hints and tips fromyour 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 theMAPI-based Outlook or Exchange clients. A Web browser requests data from aserver and displays the information in a graphical layout. The browser thenwaits for the next instruction. Client-driven rules, signals that new mail hasarrived, or dynamic refreshes of folder contents do not happen with today'stechnology. However, this situation might change soon as the HTML standardevolves. Microsoft is pushing Dynamic HTML, an extension that lets you cachedata to manipulate it on a local client. The first iteration of Dynamic HTML isin IE 4.0, and although it won't immediately change the passive nature of theWeb client, the advent of Dynamic HTML points to the future.

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

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