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.
Previous
Register
