Microsoft Exchange Server 5.5, formerly code-named Osmium, joins Exchange 5.0 as a 1997 release. Two versions in one year is a snappy pace for a development team, especially when you consider that each release has significant developments.

Version 5.0 set the scene for Exchange to become a good Internet citizen, and Exchange 5.5 completes it. This newest version completes the support of all major Internet protocols, giving Microsoft strong leverage against competing products, such as Netscape's SuiteSpot family of server products.

Although increased Internet protocol support is a noteworthy development, the most important evolution in Exchange 5.5 is its upgraded internal structures. These structures begin to accommodate the demands of massive, robust, reliable messaging servers. In short, Exchange 5.5 provides the type of system you'd want to use for mission-critical applications.

Exchange 5.5 has a few weaknesses. For example, its groupware capabilities are still not as well developed or functional as those in Lotus Notes. In addition, out-of-the-box Exchange administration tools continue to focus on the needs of small- to mid-scale installations rather than large-scale distributed environments. Despite these weaknesses, Exchange 5.5 is a superior messaging server that third-party software developers can build on.

Exchange 5.5 runs only on Windows NT 4.0 Service Pack (SP) 3 or higher. So, if you're still running NT 3.51, you need to upgrade. (For information on upgrading, see the sidebar "Upgrading Is Relatively Easy," page 169.) In fact, because Exchange 5.5 supports only Windows NT 4.0, it is the first Exchange release that forces NT 3.x administrators to upgrade their operating system. This fact might delay some administrators from implementing Exchange 5.5.

Table 1 lists Exchange 5.5's new features. I examined these features when Microsoft provided Release Candidate 1 (RC1) build 1664.5 in early September 1997. I've been running RC1 on both Intel and Alpha processors since its release. I have been impressed by its reliability and relative freedom from bugs.

I compiled the features in Table 1 into several different categories: scalability, systems administration, interconnectivity, clients, enabling technology, and miscellaneous. Here's a detailed look at some of the features in these categories.

Scalability: Massive Information Stores
Vendors' claims about the number of users that a server can support often amuse me. If you want to truly assess a server's scalability, ask the vendor seemingly mundane, yet essential, questions, such as:

* How much disk space is available on the server?

* What happens when a server fails?

* How many users will a failure affect?

* How can I restore a user's mailbox or a deleted item from a private or public folder?

* How much time do system backups take?

The vendors' answers are much more useful than their claims about the number of users. For example, if you ask Microsoft these questions about Exchange 4.0 and 5.0, you learn that both support only a maximum 16GB of storage. If a server goes offline, users must stop working and cannot resume until it is back online. In addition, restoring a mailbox or memo takes many hours.

If Microsoft answers the same questions for Exchange 5.5, the answers are quite different. Exchange 5.5 has unlimited storage. If a server goes offline and the system is part of a cluster, users experience only a brief delay. And thanks to deleted-items caching, performing a system restore to retrieve a mailbox or deleted memo is a task of the past.

Exchange 5.5 has an information store that you can theoretically expand to a massive 16TB of storage. In fact, Microsoft stopped using the 16TB number because it's so vast that it's meaningless. Instead, Microsoft states that Exchange 5.5 has unlimited storage, which is an accurate statement given the disk technology available for NT today.

Although Exchange 5.5 has unlimited storage, I find it slightly disappointing that the information store remains one big physical file. I would prefer that the store be logically split across multiple arrays (especially as sizes move into the 50GB to 100GB range) because of the size of disks and limitations on I/O performance. Most large servers are not CPU-bound, which leads to bottlenecks in the I/O subsystem. But advocates of single-file databases hold that this architecture is more efficient than the alternatives. They contend that single-file databases support single instance message storage, whereas splitting the information store across multiple databases results in duplicate copies of messages.

Exchange 5.5 features an aggressive memory management scheme. Instead of statically allocating buffers, Exchange 5.5 releases buffers to the operating system as required. This approach makes the server more responsive to different system loads and removes many of the reasons for running the Exchange Performance Optimizer utility.

Microsoft also improved Exchange 5.5's data flow out of the store. Because speed is critical when you're dealing with very large databases, Microsoft wanted to reduce backup times. If you use the most powerful parallel tape backup drives available with Exchange 5.5 (for example, a Quantum 700 dual striped DLT device), you can expect to back up data as fast as 25GB per hour--a more than acceptable rate. Slower tape drives will inevitably struggle to match ever-expanding stores, so now is the time to look at the backup hardware you use.

Scalability: Support for MSCS
Resilience and redundancy are important in any server, especially in large ones that you can create with unlimited storage. To help ensure resiliency and redundancy, Exchange 5.5, Enterprise Edition (Exchange 5.5/E) supports Microsoft Cluster Server (MSCS­formerly code-named Wolfpack). No clustering software previously available for NT was totally compatible with Exchange 5.5's memory management scheme. MSCS is the first clustering software to support transparent clustering of two servers into a single cluster that Exchange 5.5/E can function on.

Microsoft is delivering MSCS in two phases. In Phase 1, which is now available with NT Server, Enterprise Edition (NTS/E), two servers, or nodes, can operate as an active/standby pair. If the active server fails, the standby partner takes the load. Users experience only a brief delay when the switchover occurs. Two-node clustering marks the start of the path toward resilient massive servers.

In Phase 2, which Microsoft plans to release in 1998, up to 16 servers will work together in a tightly coupled environment. The servers will share resources and balance work among them. (For more information about clustering, see Mark Smith, "Clusters for Everyone," June 1997.

MSCS's Phase 2 offers the prospect of scalable clustering for Exchange 5.5, but this prospect won't become a reality until next year. Fortunately, Exchange 5.5/E currently supports Phase 1. Two servers with similar hardware configurations that have NTS/E and Exchange 5.5/E installed can service the same set of mailboxes, public folders, and directories. However, the active server handles only user requests. The standby server remains passive until problems occur. MSCS defines both servers in a cluster group. MSCS ties user mailboxes to the group rather than to an individual member of the cluster.

The servers monitor each other over a pair of network cards that transmit a "heartbeat" between each other. When the standby server notices that its partner's heartbeat has stopped, Exchange 5.5/E redirects users to the newly activated server. The backup server must start all the Exchange services (such as the Mail Transfer Agent­MTA, store, and system attendant), a process that might take a few minutes. Redirection for Messaging API (MAPI) clients (such as Outlook) that use remote procedure calls occurs automatically. Web clients might need to log on again if the server outage affected the IIS connection. Post Office Protocol (POP) 3 and Internet Mail Access Protocol (IMAP) 4 clients need to log on again.

Together, Exchange 5.5/E and MSCS Phase 1 deliver a high degree of redundancy, especially for MSCS not being a finished product. This initial support for clustering can help you get closer to the goal of 100 percent uptime for email servers. Apart from helping you increase redundancy and resiliency, clustering can help you with systems administration tasks, such as managing an email system and recovering documents through deleted-items caching.

Systems Administration: Deleted-Item Caching and Recovery
Recovering deleted items was time-consuming with Exchange 4.0 and 5.0. You had to restore the last backup onto a server. Restoring several gigabytes of stored information not only takes a long time, but it requires additional hardware (unless you take the operational server offline, which is unacceptable in most environments).

Fortunately, Microsoft made restoring items much easier with Exchange 5.5's soft delete feature. Exchange 5.5 caches deleted items into a set of hidden folders inside the information store. Users can then use Outlook 8.03 to recover deleted items. (Only Outlook 8.03 has the necessary user interface to interact with the server.) Outlook 8.03 puts recovered mailbox items in the mailbox's Deleted Items folder and puts restored public folder items directly in the appropriate public folder.

Soft delete lets the systems administrator decide when to permanently erase the deleted items in the hidden cache by setting a default retention period. The retention period is in terms of days, as Screen 1 shows. Note the Don't permanently delete items until the store has been backed up option. If you check this box, Exchange 5.5 will keep deleted items in the cache until you have completed a successful backup, even if you exceed the retention period. You can set separate retention periods for public and private information stores. In addition, you can override the default retention period for users who need a special schedule, as Screen 2 shows.

Nothing comes for free, including soft delete. When users have deleted items in the hidden cache, those items occupy space in the information store. You can't easily quantify exactly how much additional space the hidden cache will use because that number depends on how often users delete items from their mailboxes and how long you want to keep deleted items in the cache. For initial planning, you can estimate that deleted items will occupy up to 10 percent extra space if you use a 30-day recovery period. Shortening the recovery period to 7 days will reduce the additional space requirement to well under 5 percent. These figures are just estimates. I based them on the assumption that the private information store grows at a rate of roughly 5 percent per week. You'll find that the additional load levels off after a couple of weeks as new items take the place of permanently deleted items. Each system will be different, so use these estimates as a guideline only.

Microsoft anticipates that deleted-items caching will eliminate the need for most system restores. Thus, the soft delete feature will likely be a welcome addition to Exchange implementations.

Systems Administration: Differential Download
Microsoft did not greatly enhance systems administration in Exchange 5.5. Some welcome changes occur with the infamous Directory Service/IS consistency checker. These changes restrain Exchange's ability to rehome public folders after you remove a directory replication connector. (Those who have been afflicted by this problem will know what I mean). Overall, you have much more control over homing public folders. For example, you can now move a public folder's home from site to site in a single step.

Save Window Contents is a hidden feature. Have you ever wanted to capture details of the information reported by the administration program, perhaps for later analysis? Well now you can. First, you populate the right-hand window, perhaps with information about the amount of space each mailbox uses. Then, you click on File.Save Window Contents to write the data out to a Comma Separated Values (CSV) file. This file is a great example of a feature slipped into the product by an engineer who thought it would be useful. In this case, it is!

My favorite new feature is differential download of the offline address book (OAB). I travel a lot and depend on the OAB when I'm disconnected from the network. I download the OAB often because I need accurate information. In the past, downloading this 55,000-user OAB took many minutes. But with differential download, I now receive only the changes that have occurred since my last download. My telephone bills are much lower!

Interconnectivity: New Connectors
Exchange has always offered a strong lineup of connectors. Microsoft's buyout of LinkAge Software in May further strengthened the lineup because the buyout led to the addition of Lotus Notes, IBM PROFS, and IBM SNADS connectors in Exchange 5.5.

The new connectors will likely satisfy your messaging and communication needs. Interoperability with Lotus Notes is good. You can send rich-text format messages, documents, and other attachments between the two systems without fuss. You can also receive delivery receipts and other status-type messages. Directory synchronization between Exchange and Lotus Notes is relatively straightforward and works much like the synchronization between Exchange and Lotus cc:Mail.

Although the Lotus Notes connector's messaging and communication functions are strong, some restrictions exist. For example, you cannot encrypt messages in either direction and you cannot synchronize Exchange public folders and Lotus Notes databases. (Microsoft will likely close these relatively minor gaps over time.)

You need to install some of the dynamic link libraries (DLLs) that Lotus Notes provides on the server to configure the Lotus Notes connector. But aside from the DLL installation, you can use Exchange 5.5's administration program to manage the connection.

Because Lotus Notes enjoys a high profile in the market, the Lotus Notes connector will likely receive most coverage. However, the PROFS and SNADS connectors are important, too, because they will ease the introduction of Exchange into corporate environments that use PROFS and SNADS email systems. Although PROFS and SNADS email systems are not at the cutting edge, they offer dependable service (albeit at a much-reduced level of functionality compared to Exchange).

The SNADS connector requires Microsoft SNA Server (2.11 or 3.0) and handles the popular SNADS messaging systems, such as Fischer TAO, Soft-Switch Central and Lotus Message Switch, and Software AG CONNECT. Directory synchronization is unavailable for PROFS and SNADS connectors in Exchange 5.5, but I wouldn't be surprised if this feature appeared in the future. PROFS calendaring is also unavailable.

Exchange 5.5 is not ignoring older connectors, either. Spamming and other nefarious acts are a fact of Internet life. You can prevent such acts with the Exchange Internet Mail Service, which lets you control incoming Simple Mail Transfer Protocol (SMTP) connections. For example, you can insist on authenticated incoming SMTP connections for the Internet Mail Service, effectively stopping spammers from sending your users unwanted messages. Screen 3 shows how to set an authenticated connection as properties of the Internet Mail Service.

Exchange 5.5 offers unrivalled connectivity to other messaging systems. The combination of a heavy-duty MTA and a wide set of connectors delivers functionality that major competitors can't match. For example, Exchange 5.5's MTA can increase its capacity to process messages by splitting a single MAPI queue into seven. Splitting queues lets servers process a much greater quantity of mail.

The Lotus Notes connector is available in both editions of Exchange 5.5, but you must buy the Enterprise Edition to get the PROFS or SNADS connectors. (For information about which Exchange edition to use, see the sidebar "Two Editions Are Available," page 170.) The new connectors are available for only Intel systems, but Microsoft promises to release Alpha versions soon, probably in a service pack, in early 1998. The connectors are available only in English, so for French, German, or Japanese versions, you'll have to wait for the service pack.

Clients: Better Support
A 16-bit version of Outlook is available for the first time. In addition, an Apple Macintosh version of Outlook is available to complete the Outlook lineup across client platforms.

Microsoft has upgraded Outlook in many ways. For example, you can now access Schedule+ and Outlook calendars from Web browsers. Outlook also supports deleted-items recovery and HTML forms. You can create and save a form in HTML format, much like what's possible with Word documents. You can also use a wizard to convert existing forms created with earlier versions of Exchange to HTML.

Secure MIME (S/MIME)-capable clients, such as Outlook Express or Netscape Communicator, can send encrypted messages to each other via Exchange 5.5. (Like the other previous clients, IMAP4 clients still need a client access license.) However, Exchange servers don't encrypt or decrypt messages--those tasks are left to the client. You can expect to see S/MIME capabilities in a future release of Outlook, but not when Exchange 5.5 ships.

Exchange 5.5 now supports IMAP4, as Screen 4 shows. This addition is part of Microsoft's continuing effort to have Exchange 5.5 support as many clients as possible.

Enabling Technology: The Exchange Scripting Agent
Exchange 5.5 introduces the Scripting Agent, also known as the Event Service, to invoke processing when changes (called events) occur in folders. If you add, change, or delete items in a folder, the Scripting Agent will trigger an application to run. However, you need to create the code that tells the Scripting Agent which application to trigger. As a result, the Scripting Agent is a diamond in the rough because it needs application developers to take advantage of its capabilities. Even so, the Scripting Agent is already laying a firm foundation for document management and workflow applications in Exchange 5.5. A future issue of Windows NT Magazine will supply more information about the Scripting Agent.

Chat Service
I'm not quite sure how people will use the new Chat Service. An Internet Locator Server supplements the Chat Service, letting users locate people in the Exchange directory and connect to them for an online discussion. Supposedly, you can combine the Chat Service with Microsoft NetMeeting to incorporate online communication into active pages so that companies and their customers can have realtime chats. I'm a little skeptical about the overall usefulness of these features, but I'm happy to wait and see.

Exchange's Journey Is Not Over
Keeping up with Exchange's rapid pace of development can be exhausting at times. Exchange 5.5, with its many new developments, is no exception. Exchange 5.5 now supports all the major Internet protocols, helping it to achieve client universality. You can reasonably argue that Exchange 5.5 is at least as pure an Internet citizen as any of its competitors. In addition, you can use Exchange 5.5's massive information store, two-node cluster support, and deleted-items recovery to build large, cost-effective servers.

But Microsoft will face several challenges in 1998. The next version of Exchange will need to support NT 5.0, which will involve a move toward a unified directory based on the Active Directory. At the same, Exchange will need to support true clustering in MSCS Phase 2 and take advantage of new hardware developments in disk, tape, and CPU. Most important, Microsoft will need to address manageability. Exchange 5.5 provides many administration features and tools for small to midsize deployments but provides relatively few for large implementations. Given the drive and pace behind Exchange, I'll be interested to learn how Microsoft engineers meet these challenges.