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

In comparison with the Microsoft Exchange or Outlook client, Web and POP3 clients have a passive relationship with Exchange: Such clients always request information from the server. The server never updates them about changed circumstances such as a new message. For this reason, Microsoft placed a Check for new messages button in the Web client interface.

Although the new POP3 and Web clients are free or shareware, Microsoft licensing policy clearly states that all clients must possess a Client Access License (CAL) before they can connect to a server. The Microsoft Exchange and Outlook clients are far more functional, so influences such as available hardware or platforms drive the choice to deploy POP3 or Web clients. You'll never get a Microsoft Exchange client running on a Solaris or Digital UNIX workstation, but you can run Netscape. If you don't have large amounts of free system resources on a low-end 386, a POP3 client such as Pegasus or Eudora Pro will certainly let users communicate with everyone connected to Exchange.

Public Folder Replication

The Active Server melds Web resources with Exchange. The Internet News Service lets feeds from Internet newsgroups come directly into a public folder, or has Exchange act as a newsgroup server. Maintaining a single subscription to a newsgroup and using public folder replication to distribute the information will usually reduce the amount of data that Internet links must handle, so you gain an immediate advantage. Also, using products like Fulcrum Find! for Exchange or Verity's Search97, you can index anything in a public folder easily for full text retrieval.

SMTP Support
Microsoft has renamed Exchange 4.0's capable Internet Mail Connector (IMC) to Internet Mail Service (IMS) for Exchange 5.0 and bundles it with all variants of Exchange server. The IMS can now act as a smart relay host and route new SMTP messages that are presented to the IMS to other, non-Exchange destinations. This point is important in large messaging environments where you typically operate a single point of contact (in association with a firewall) between an enterprise and the Internet. The single point of contact must be able to process messages on behalf of other systems, routing them to their final destination. The Exchange 4.0 IMC did not do this processing, so organizations had to operate another computer, usually a UNIX system, in that role. Acting as a smart relay, the IMS simplifies operations for all concerned.

SMTP mail systems are less functional (but easier to configure) than their X.400 equivalents. ESMTP (Extended SMTP) is an attempt by the Internet Engineering Task Force to close the gap, and Exchange 5.0 includes support for RFC 1869 (Delivery Status Notification) and RFC 1870 (Notification of Message Size). Knowing that a message has reached its destination is clearly important, and Exchange can now fulfill that need if messages are sent to other SMTP mail systems that support ESMTP.

Setting up IMS is easy with the Internet Setup Wizard. It looks as if the Exchange engineers reviewed all the user complaints about the old IMC and attempted to solve the problems by making sure that systems are configured correctly. Anything that sorts out common problems, without a lot of effort from systems administrators, is welcome.

Wait, There's More
Exchange 5.0 includes many other changes, so the new version fully justifies the new version number (the number allocated to the new version went from 4.1 to 4.5, and then to Exchange 5.0, as Microsoft added new features). I'll highlight a few of the more interesting ones.

The Administration program is now easier to use. Common properties (such as the current logons to the server or the amount of space users occupy in their mailboxes, as Screen 4 shows) are available with one click, and information is generally available faster.

Corporate mail directories can rapidly become so large that knowing where to look for someone is difficult. Exchange 5.0 supports address book views, virtual containers in the directory that you can create based on different attributes. For example, if you create a view based on the department attribute, Exchange creates containers for each department, such as sales and marketing.

A competent connector is now available for Lotus cc:Mail. To the cc:Mail environment, the connector appears to be just another cc:Mail post office, but the connector can seamlessly pass messages and directory information between cc:Mail and Exchange. Interestingly, the cc:Mail connector also lets cc:Mail users access any other connector Exchange operates, so cc:Mail users can use Exchange to route messages to the Internet or X.400, without installing any other gateways specific to cc:Mail.

Exchange 4.0 included migration utilities to help users of various mail systems move their data to Exchange. Exchange 5.0 provides new migration utilities for Netscape Collabra and Novell GroupWise. Some unsupported utilities to help migrate UNIX sendmail-type systems are included in the new Microsoft BackOffice Resource Kit for Microsoft Exchange.

The Exchange 5.0 RC1 requires NT 3.51 SP5 or NT 4.0 SP1. If you want to use the Active Server to link Web clients, you need IIS 3.0 with the Active Server components, which in turn requires NT 4.0 SP2. The final version of Exchange 5.0 will be out by the time you read this, and these requirements might change. If your installation runs Exchange, I recommend you keep up to date with service packs for Exchange and NT so you don't have quite so much work when you upgrade.

Beyond Exchange 5.0
The changes in Exchange 5.0 increase the power and flexibility of Exchange as a messaging platform, chiefly by an impressively seamless integration of numerous Internet protocols. Microsoft did not address the weaknesses of Exchange 5.0 groupware capabilities, which make up Exchange's acknowledged Achilles' heel in comparison to its major competitor, Lotus Notes. Exchange electronic forms, for example, are still based in Visual Basic (VB), a language that results in slow forms that you can execute only on a Windows platform. The introduction of HTML in Exchange 5.0 and the impressive implementation of the Web client provide a pointer to the future. Microsoft plans to replace VB forms with platform-independent forms built around HTML and ActiveX components, possibly by the end of 1997.

Microsoft sources say we can expect the next version of Exchange in late 1997. After all the work to accommodate Internet technologies in Exchange 5.0, the focus of the next release will shift toward the demands of building very large servers, those capable of supporting many thousands of users. Some Exchange servers support thousands of users: Digital produces an Alpha server that supports 2700 mailboxes. But the challenge is to scale up to 10,000 to 20,000 mailboxes. Changes (such as clustering) to achieve truly massive scalability, the ability to support and manage a 16TB information store (Exchange database), and the unification of the Exchange directory with the NT Active Directory (NT 5.0) are needed from both Exchange and the operating system. These developments will help corporate implementation teams, but require a close eye on what's happening in Exchange and NT over the next few years.