Microsoft's Exchange Server 5.5 Debuts

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.