Exchange 2000 worth the wait
- By Jeff Symoens
- Feb 06, 2001
The recent release of Microsoft Corp.'s Exchange 2000 Enterprise Server — some three years after the release of Exchange 5.5 — is an upgrade that many agencies will find worth the wait.
This version greatly expands the product's capabilities as a distributed messaging and collaboration platform. The result is greater deployment flexibility, improved administration tools and greater scalability.
Exchange 2000, in short, solves many of the problems IT managers complained about with Exchange 5.5. Be aware, however, that moving to Exchange 2000 will not be without challenges.
Although Microsoft has provided tools and features that ensure compatibility between Exchange 5.5 and Exchange 2000, migrating to the new product requires several well-planned steps. And, due in large part to integration with Windows 2000, the migration is anything but elegant.
Old Tricks, New Tricks
Microsoft brings many enhancements to Exchange 2000, such as universal messaging capabilities, full-text indexing of the data store, and Simple Mail Transfer Protocol performance and efficiency enhancements.
Several new features bring the platform up to date with competing products, as many have long been available on other messaging platforms, such as Sendmail, Novell Inc.'s GroupWise and Lotus Development Corp.'s Domino. A few others features, such as Active Directory integration and the new Web Store, forge ahead on the competitive landscape.
With that said, the final product represents a strong collection of capabilities that maintain Microsoft's competitive position in the messaging marketplace.
Many of the new attractions, such as the product's new Web Store and enhanced Internet protocol support, are directly tied Windows 2000 features. As a result, Windows 2000 is an absolute requirement for the deployment of Exchange 2000.
However, among the product's ties to Windows 2000 features, perhaps none is more profound than its link to Active Directory, which completely replaces the underlying directory service found in previous versions of Exchange. Although there are some key benefits to this migration from the Exchange directory to Active Directory, this change provides interesting challenges.
If you have Exchange 5.5 widely deployed, you must carefully map your migration strategy to Exchange 2000 to maintain synchronization between the Exchange directory and Active Directory.
Microsoft provides tools and services to assist you with the task. But ultimately, restrictions in these tools may require you to either mold a temporary Active Directory organizational unit model around your current Exchange 5.5 site model or maintain duplicate user accounts in Active Directory until migration is complete.
In this latter approach, Microsoft does provide a tool for cleaning up duplicate user accounts, but it still does not make for an elegant migration strategy.
Several new features in Exchange 2000 focus on bringing greater scalability to the messaging platform. Among these are the additions of Active-Active clustering, database partitioning (the ability to partition or break up the back-end Exchange databases across multiple database files), and the implementation of multiple storage groups.
These new capabilities pave the way for reducing the number of servers in your environment through consolidation, as they permit a single server to more safely host larger numbers of users while keeping the size of any single Exchange database within reason.
Exchange 5.5 offered fail-over support when running on Microsoft Cluster Server (MCS) clusters. But the product supported this feature through Active-Passive clusters — meaning that your standby server in a cluster cannot operate as an Exchange server in its normal operation mode. As such, one of the servers in your Exchange cluster operates in "passive" mode until the "active" server actually fails-over to the passive.
Some agencies may have found this fail-over approach better than nothing, but it is at best a waste of a server resource for the majority of time.
The key limitation in clustering Exchange 5.5 was due to limitations in the product's database engine — Extensible Storage Engine 97 (ESE 97) — which could only support one instance each of the private (mailbox) and public (public folders) stores on a single server. In Exchange 2000, Microsoft has significantly enhanced the database engine — released as ESE 2000.
This new version of the database engine includes the capacity to partition the private and public data stores across multiple physical files. This enables Exchange administrators to set different global properties, such as storage limits, maintenance intervals or deleted-item retention time, for each database partition.
In addition, ESE 2000 also can run multiple instances of the database engine, a feature termed storage groups, which enable administrators to define logical groupings of databases and associate each grouping as a unit of fail-over to other servers in the cluster.
One other scalability feature in Exchange 2000 Server with exciting potential is the implementation of front-end servers, enabling administrators to separate the protocol access functions (SMTP, POP3, IMAP, NNTP and HTTP) of the product from the database back-end functions.
This feature is generally aimed at Internet service provider-level customers, but it may also appeal to larger government and corporate installations that wish to isolate these functions for load balancing and redundancy, or sites that wish to separate functionality to tune specific hardware configurations to fit the task.
The Web Store
Perhaps the most innovative feature in Exchange 2000 is the evolution of the Exchange Information Store into what Microsoft terms the Web Store.
The Web Store leverages Windows 2000's Installable File System (IFS) architecture to create a new virtual file system called the Exchange File System (ExFS), which allows for many points of access to the underlying Exchange databases, such as through a common Web browser, the Windows Explorer or even the command line.
This feature is significant because it opens the platform for new uses, including being a fairly robust, semi-structured data store platform for Web-based applications.
The Web Store also is significant because it fundamentally changes the architecture of the underlying database. The end result for users is faster data-search capabilities.
Nevertheless, administrators need to be aware that in mixed protocol environments, the disk space consumed by the Web Store could rise dramatically because message contents — large file attachments, for example — could be stored in both the property store and the streaming store, requiring twice the amount of disk space.
Some new features and changes will enable Exchange administrators to manage the platform more efficiently. Among the features bound to attract the most attention from Exchange administrators are administrative groups, routing groups and policy-based administration.
One of the benefits of Exchange 2000's integration with Active Directory is that the restrictive site architecture of previous Exchange versions virtually disappears.
In Exchange 5.5, the site construct was a boundary for directory replication, mail routing and administration. In Exchange 2000 the site construct for directory replication is handled by Active Directory, leaving a bit more flexibility with respect to doling out administrative privileges and designing your mail-routing architecture. Exchange 2000 handles these latter two issues with its implementation of administrative groups and routing groups.
With administrative groups, we were able to create logical groups containing a collection of servers, based on how we wanted to apply administrative rights. For example, we could create various administrative groups to represent different geographic sites or regions. Next we were able to delegate administrative control within the context of each administrative group. Within each administrative group, we were also able to create one or more routing groups and define routing group connectors between different routing groups.
Alternatively, many Exchange shops will want to create a separate administrative group specifically for managing routing groups, since you might want to separate management of the mail routing architecture from server resource management.
The bottom line, though, is that Exchange 2000 yields much greater flexibility in administration and message routing.
By and large, Exchange 2000 is a huge upgrade over Exchange 5.5. The product is packed with new technology and offers many new capabilities over the prior release.
However, most shops evaluating the new platform will find that only some fraction of the new feature set actually appeals to their environment. For example, most agencies should find that Exchange 2000 has some nice administration benefits. Large Exchange 5.5 shops will focus some attention on scalability enhancements.
Ultimately, you will want to focus your migration case around that subset of new features that meets your agency's needs. But you will be well served if you take pains to really understand the underpinnings of this product, particularly in its integration with Active Directory.
The implications of deploying Exchange 2000 without proper insight into how the product works could produce some fairly negative effects, particularly in larger deployments. So take your time on this one.
Jeff Symoens is a freelance analyst and a senior IT systems engineer at a large, Silicon Valley-based high-tech company. He can be reached at firstname.lastname@example.org.