Osmium has many new developments
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.
Previous
Register
