Microsoft Exchange Server 5.0 Smoothes the Rough Edges

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+.