Special Delivery: Exchange 2000 Service Pack 1

Bug fixes and new features straight to your server

No software company releases commercial software in a perfect state, so the release of Microsoft Exchange 2000 Server Service Pack 1 (SP1) comes as no surprise. (As of this writing, SP1 was scheduled for release in May 2001.) True to Microsoft form, SP1 combines bug fixes and new functionality—a sort of spring-cleaning for Exchange 2000. And although many companies haven't yet deployed Exchange 2000, the release of SP1 might signal the start of more migrations (as the sidebar "Easy Does It," page 78, explains).

SP1 doesn't require an Active Directory (AD) schema update, which simplifies the process of introducing the service pack in a Windows 2000 forest. Keep in mind, however, that installing a service pack isn't simply a matter of sticking the CD-ROM into a server and seeing what happens after the installation program finishes. Always test a service pack (i.e., install the pack on a test server and monitor its progress for a minimum of 1 week) before you let the software anywhere near a production server.

Old Bugs, New Features
SP1 represents a consolidated set of all the bug fixes that Microsoft has released since the debut of Exchange 2000. (A full list of bugs was unavailable at the time of this writing, but Microsoft should have published such a list in the Knowledge Base by the time you read this article.) Many of these fixes involve the Store, the SMTP Routing Engine, the Message Transfer Agent (MTA), clustering, and other components, which isn't surprising, considering that these components underwent the most work during the evolution of the Exchange 2000 architecture. You can't expect to partition the Store into multiple storage groups (SGs) and databases without a great deal of effort and thus an increased potential for errors. And transferring responsibility for message routing from the tried-and-tested X.400-based MTA (which still provides a communication path with Exchange Server 5.5 and earlier connectors) to the new SMTP-based Routing Engine is a major achievement. Such changes worked surprisingly well, but several glitches appear when you work the code hard in production. SP1 clarifies and improves failover conditions and routing decisions and improves the interaction between the Routing Engine and the MTA.

Like most software companies, Microsoft emphasizes delivery of quality products at preset dates. This methodology means that developers are likely to remove features from the final build if they can't complete the features on time or if the code contains too many bugs. Often, such features reemerge in the product's service packs. In addition to bug fixes, SP1 includes five new features that deserve attention:

Welcome Back, Mailbox Manager
Mailbox Manager lets administrators automatically clean up user mailboxes according to criteria such as message age or size. (For example, you can prevent users from keeping more than a month's worth of messages in their Inbox and Sent Items folders. For information about how to use Mailbox Manager, see "Mailbox Management," October 2000.) Mailbox Manager first appeared in Exchange Server 5.5 SP3 and is popular with administrators (and much less popular with users).

Microsoft failed to ship an upgraded version of the utility in Exchange 2000. The tool's original code used Messaging API (MAPI)—an API that Microsoft is keen to move away from—so developers needed additional time to rewrite Mailbox Manager to use ADO and OLE DB, both of which Exchange 2000 supports. Also, a great deal of testing was necessary to ensure that the tool still performed adequately. (Because of a small but potent bug, a similar utility written for another messaging system back in 1990 did a fine job of deleting every message on a server. No one—least of all those of us who take the phone calls from distraught users—would thank Microsoft for a utility that produced such a well-cleaned server, so care and attention during testing are mandatory.) Mailbox Manager's reappearance is welcome, but take some time to ensure that you are completely familiar with the way the new version of the utility works before you launch it into production.

Virus Scanning API
Exchange Server 5.5 SP3 also marked the appearance of VS API, Microsoft's answer to third-party antivirus vendors' requests for controlled and functional access to the Store. (For information about the successes and shortcomings of antivirus products for Exchange Server, see "The Great Antivirus Crusade," April 2001.) Microsoft intended VS API to provide a documented and supported API that all antivirus vendors could use, but the API's first version wasn't very functional and most third-party vendors continued to use their old approaches.

The API's lack of functionality and subsequent lack of vendor support caused many heated discussions between Microsoft and the antivirus vendors. The result is the new version of VS API (also known as the Antivirus API), an updated and more functional release. Time will tell whether Microsoft has succeeded in providing the type of interface that the antivirus vendors need and whether third-party products will be able to use the API successfully. Microsoft's stance is that it has done its job and now expects the third-party vendors to support the initiative. I suggest that you talk with your antivirus vendor about its plans to support VS API. Products that use older solutions will probably coexist with VS API-enabled products for some time. However, the long-term road seems obvious: VS API is available, and Microsoft fully supports the new API and will develop it further in future releases of Exchange Server, so third-party products will no doubt support VS API as well. VS API also appears in Microsoft Sharepoint Portal Server, so antivirus products that support VS API in Exchange 2000 should also work with Sharepoint Portal Server.

Calendar Connector
Without SP1, you can use Exchange 2000's Microsoft Exchange Novell GroupWise Connector to send email and calendar requests freely between Exchange 2000 and GroupWise. However, the only way for an Exchange 2000 user to view the foreign messaging systems' free and busy information is to maintain Calendar Connector on an Exchange Server 5.5 machine. (The Microsoft article "XFOR: How to Configure the Exchange Server 5.5 Calendar Connector to Use the Exchange 2000 Router for Novell GroupWise" at http://support.microsoft.com/support/kb/articles/q258/0/95.asp explains the procedure.) SP1 makes this functionality native in Exchange 2000—a relief if you're nearing the end of a migration from Exchange Server 5.5 and are ready to move into a native-mode Exchange 2000 organization.

Migration Wizard Enhancement
Migrations come in many flavors. The simplest choice is to upgrade an Exchange Server 5.5 organization to Exchange 2000 one server at a time. This type of migration creates a mixed-mode organization that transforms into a native-mode Exchange 2000 organization when you upgrade the last Exchange Server 5.5 machine. At the other end of the spectrum, some companies want to rebuild their Exchange Server organization during migration (perhaps to combine several Exchange Server 5.5 organizations into one Exchange 2000 organization or to restructure the administrative and routing models through a direct move to a native-mode Exchange 2000 organization). In this more complex type of migration, the two organizations (i.e., Exchange 2000 and Exchange Server 5.5) run in parallel and use connectors to exchange email.

SP1 extends Exchange Server's standard Migration Wizard with interorganization functionality that helps you move mailbox contents from an Exchange Server 5.5 organization to a separate Exchange 2000 organization. The wizard's new features don't work in mixed-mode organizations, perhaps because you can use Exchange Server's standard Move Mailbox feature to transfer mailboxes within such organizations. Keep in mind that the wizard moves mailboxes' contents, but it doesn't clean up (i.e., remove) the mailboxes from the source Exchange Server 5.5 organization, nor does it transfer membership information for distribution lists (DLs) or public-folder permissions. You still have some work to complete after the mailboxes reach Exchange 2000.

Datacenter Support
Datacenter systems comprise a Microsoft-validated hardware and software configuration and specialized support from the hardware vendor. These systems carry a substantial price tag. Datacenter targets large user populations that need to access mission-critical applications. (When Datacenter first launched, it primarily supported Microsoft SQL Server.) However, few organizations run only Exchange Server on any system; most machines that house Exchange Server also house third-party products that need to run alongside the messaging system (e.g., backup software, antivirus checkers, fax connectors). For this reason, few people might have considered running Exchange Server on Datacenter. After all, would you deploy an expensive system to support thousands of mailboxes that were totally unprotected against a virus such as Worm.ExploreZip?

Nevertheless, SP1 marks Exchange 2000's arrival on the Datacenter scene. The ability to support as many as 32 processors might be exciting, but the most important feature from an Exchange Server perspective is the support for 4-way clusters, which enable highly resilient mail systems. If you want to support 10,000 mailboxes on a 4-way cluster, SP1 and Datacenter can do the job. Note that some limitations exist in configuring Exchange 2000 to run on a Datacenter system. Documentation of these limitations is incomplete, so consult with your local Microsoft office to get the latest information.

You can't build Datacenter systems from any old hardware. Consult with your hardware vendor to determine which of its systems (including Storage Area Networks—SANs—and other hardware components) are Datacenter-certified, then determine whether the third-party software you need to run on the system is also certified. Even if you get the go-ahead from your hardware and software vendors, the cost of Datacenter is so high that only a small section of the Exchange Server community is likely to purchase such systems. If you aren't in that section, you might be able to get by with 2-way clusters running Exchange 2000 on Win2K Advanced Server.

On Second Thought
The most notable item missing from SP1 is the server-side code to support the local store that Microsoft originally designed as part of Microsoft Outlook 2002 (an element in Microsoft Office XP). The company originally intended the local store to replace personal store (PST) and offline store (OST) storage and provide a more efficient method of replicating data to a client. However, Microsoft removed the local store from Outlook 2002, and the server-side code has therefore disappeared from SP1. According to Microsoft, the local store is still in the works as the company pushes to move away from client-server remote procedure calls (RPCs)—unfortunately, the work couldn't be completed in time for SP1.

Regardless of the absence of this expected code, SP1 has plenty to offer. Mailbox Manager is probably the most welcome and compelling feature, but the consolidated set of bug fixes isn't bad either. Take time to perform the proper diligence testing, deploy SP1, and enjoy.