And expands the range of available clients and embraces many protocols
The first release of Microsoft's enterprise messaging server, Exchange 4.0,
was in March 1996. Exchange Server 5.0 seeks to eliminate some rough edges in
the original release, radically expand the available clients, and embrace all
sorts of Internet protocols. Too much to do in a single release? Well, if
Release Candidate 1 (RC1), the currently available beta of Exchange 5.0, is any
indication, Microsoft has done a pretty good job, and the upgrade to Exchange
5.0 won't require too much effort.
Microsoft released RC1 in December 1996. It was available from Microsoft's
Web site, and the company issued several thousand kits. I've run RC1 in a
production environment since early January and am happy with the code's
stability.
An Internet-Friendly Exchange
Exchange has always supported multiple protocols. The product's core is
designed around a multiprotocol architecture, enabling support for new protocols
without dramatic redesign or internal conversions. Exchange 4.0 was equally
happy to dispatch messages via Messaging API (MAPI), X.400, or Simple Mail
Transfer Protocol (SMTP), but the increasing success of the Internet meant that
more work was required to make Exchange Internet friendly. Microsoft has done
that work in Exchange 5.0, which supports Network News Transfer Protocol (NNTP),
Secure Sockets Layer (SSL), Lightweight Directory Access Protocol (LDAP), HTML,
HTTP, and POP3 for the first time.
The Internet protocol expansion achieves two major goals. First, it allows
a higher degree of interconnectivity with sources of information commonly used
on the Internet. (I'll discuss Exchange 5.0 interconnectivity later.) The second
goal is to expand the range of Exchange clients and allow more choices. Up to
now, the only available Exchange clients came from Microsoft. These clients were
elegantly engineered and highly functional, but they were often resource-hungry.
The need to upgrade desktop hardware to accommodate the Exchange clients impeded
large implementation projects, where the cost of replacing hundreds or thousands
of low-end Windows PCs or Apple Macintoshes surpassed any benefits of installing
a new mail system. The problem of how to handle UNIX workstations in an Exchange
environment also needed a solution. Microsoft's solution? Use Internet protocols
to enable lightweight clients to connect to Exchange Server.
If you need to cater to low-end hardware bases, you can now deploy POP3
software or Web browsers as desktop mail clients. POP3 software, traditionally
available as freeware or shareware, gives you many choices on different
platforms but is limited in functionality: POP3 doesn't recognize concepts such
as server-based folders, public folders, and inbox assistants. (For more on
Exchange 5.0 support for POP3, see Spyros Sakellariadis, "POP3," March
1997.)
The connection between Web browsers and Exchange is much more interesting
from a technical perspective than the capabilities of the POP3 client and
delivers far more functionality than a POP3 client. You can use any Web browser
that supports HTML frames (e.g., Netscape Navigator 2.0 or Microsoft Internet
Explorer--IE--3.0 onwards) to access Exchange and get more than just messages.
You can view any private or public folder that you can access and see messages
created and sent. The LDAP protocol gives Web clients access to the Exchange
directory. You can execute but not set Inbox assistant rules.
The client interface in Screen 1 is a work of art, built of HTML formatting
instructions, frames, and Java applets (used to create messages or execute
directory look-ups). Although the amount of data that must be transmitted
between server and client to build such a complete interface can result in
sluggish responses across congested or low-bandwidth networks, the Web client
certainly works and delivers lots of functionality.
Active Server Is the Key
The magic connecting Web browsers and Exchange is the Exchange Active
Server, a new Exchange 5.0 component. The Active Server components layer on top
of Internet Information Server (IIS) 3.0, which requires that you install
Windows NT 4.0 Service Pack 2 (SP2) on any computer you use to connect Web
clients to Exchange. You can run IIS and Exchange on the same computer or
distribute them across multiple systems. The Exchange Active Server is an
intermediary between Web clients and Exchange, translating client requests from
HTML into MAPI before transmitting them to Exchange, and then translating the
results back from Exchange into HTML before sending formatted pages back to
clients.
The Active Server supports authenticated and nonauthenticated (anonymous)
access. Authenticated access is, of course, necessary for users to access the
contents of their private mailbox. Such authentication occurs through an
ordinary logon procedure. You can use SSL to encrypt the mailbox name and
password information while the message is en route between client and server.
Anonymous access is restricted to public folders, and you can set them up to
have read-only or read-write access for people outside your organization.
Anonymous access is not a default privilege. You must adjust the access control
list on each folder to make the contents available to anonymous users and define
a shortcut to each folder, as Screen 2 shows. Once you establish the appropriate
access control, you can publish URLs pointing to documents or other items in
public folders.
LDAP Support
Exchange 5.0 supports LDAP, but only in query mode, and you cannot use LDAP
to connect directories. This function is enough to let the lightweight clients
validate mail addresses against anything in the Global Address List (GAL), or
search the Exchange directory, as Screen 3 shows. System administrators can
customize LDAP to provide a subset of attributes from the GAL to clients, or to
ensure the return of a limited number of addresses at any one call. Both steps
mean that clients won't get into trouble when requesting vast quantities of
directory data. High-end clients continue to use MAPI for their interaction with
the Exchange directory.
The Clients
The high-end Exchange clients are not immune from change. A new version of
the standard Exchange client comes with Exchange 5.0, and 32-bit clients can now
consider installing Outlook, which comes bundled with Office 97 or separately.
Outlook and the Exchange clients offer different functionality. For example, the
Outlook client can recall an unread message, and the Exchange client can't. If
you haven't begun client software deployment for Exchange, your best choice is
Outlook because it offers more functionality. However, if you're halfway through
a deployment, you have no compelling reason to start over and replace clients
with Outlook. Wait until you're ready for Office 97, and install Outlook then. A
slightly different version of the Outlook client is in the Exchange 5.0 kit
because Microsoft fixed bugs between the release of Office 97 and Exchange 5.0.
If you installed Outlook from the Office 97 kit, upgrade to the Exchange
version, just to make sure that you're running the latest code. The Exchange
client for Apple Macintosh is updated, too, and now supports Schedule+.
Previous
Register
