Are you the type of administrator who refuses to upgrade to a new point release until the first service pack appears? If so, you might finally be evaluating whether to upgrade to Microsoft Exchange Server 2003. After a wait of nearly a year, Microsoft released Exchange 2003 Service Pack 1 (SP1) in May. The pace of development for Exchange 2003 service packs promises to be more measured than that of earlier Exchange versions, the theory being that the extra time Microsoft spent developing the base product has resulted in a more stable and feature-rich release—thus Microsoft won't have to rush out service packs in response to flaws.
Exchange 2003 SP1 includes a mixture of bug fixes, updates to existing features, and some new UIs that simplify deployment and management. (The sidebar "The Rundown on Exchange Server 2003 SP1," page 73, gives a quick overview of what's new in SP1.) If you like what you see in Exchange 2003 SP1 and decide that the time has finally come to upgrade from Exchange Server 5.5 (as indeed it has), you'll be pleased to learn that SP1 includes new tools to make migration easier. If you're already running Exchange 2003, I think you'll find two improvements—easier configuration of Remote Procedure Call (RPC) over HTTP and self-healing capabilities for the Store—particularly useful.
Making Migrations Easier
The support deadline for Exchange 5.5 expires in December 2004. True, you can buy extended support from Microsoft and keep using Exchange 5.5 until December 2005, and many Exchange 5.5 supporters argue that it's still stable, works, and offers all the features they need from an email system. But the computing world has changed since Microsoft set the fundamental architectural principles for Exchange 5.5 in 1996. Exchange 5.5 might be able to support communities of several thousand mailboxes on one server, but today's messaging environment requires so much more than that. Exchange 5.5's scalability is limited to a single mailbox store, its SMTP connectivity is basic, it can't take advantage of newer client features (e.g., Microsoft Office Outlook 2003's on-the-wire compression), its administrative model is poorly suited to larger organizations, its implementation of Outlook Web Access (OWA) is rudimentary, and it supports only two-node, active/passive clusters. Exchange 2003 running on Windows Server 2003 is simply a more secure and robust messaging platform.
Furthermore, Exchange 2003 offers a solid platform for consolidation. Exchange 2003 and Outlook 2003 are an especially good combination to implement when you want to consolidate servers. Improvements in how the client and server work together across low-bandwidth networks make it easy to remove servers from branch offices, for example, and cached Exchange mode lets Outlook clients work during network interruptions. Exchange 2003's SMTP connections require less network bandwidth than Exchange 5.5's Messaging API (MAPI)-based site connector or X.400 connectors need, letting you consolidate Exchange 5.5 sites into fewer Exchange 2003 administrative and routing groups and thus reducing the complexity of your administrative and routing topologies. SP1 improves Exchange 2003's Move Mailbox Wizard and makes the notion of site consolidation even more compelling.
The biggest change is that you can now use the Move Mailbox Wizard to migrate mailboxes in a mixed-mode organization from an Exchange 5.5 server in one administrative group (or site, in Exchange 5.5 terminology) to an Exchange 2003 SP1 server in a different administrative group. Without SP1, the wizard lets you move mailboxes between mixed-mode servers only when the servers are in the same administrative group. This new capability might seem unimportant, but it will save a lot of work if you opt to deploy Exchange 2003 by installing brand new servers rather than by upgrading older servers.
The Move Mailbox Wizard also now preserves mailbox rules and updates folder ACLs, instead of merely moving mailbox contents, to ensure the preservation of the complete mailbox environment. Users who have accumulated rules to process incoming messages will be happy to learn that they won't have to recreate all those rules after you move their mailboxes to a new server.
Note that before you can use the updated Move Mailbox Wizard to migrate mailboxes across administrative groups, you need to update your Active Directory Connector (ADC) to the version included in SP1. This version includes new code that lets users continue to use distribution groups (DGs) and access public folders after the migration. There are a few other requirements, which you can find (along with a brief discussion of other SP1 deployment improvements) in the Microsoft article "Deployment Changes in Exchange Server 2003 SP1" (http://www.microsoft.com/technet/prodtechnol/exchange/2003/deploysp1.mspx).
Simplifying RPC over HTTP Configuration
Exchange 2003's RPC over HTTP feature lets users take advantage of a standard HTTP connection (rather than a VPN) to transfer MAPI RPCs between Outlook and Exchange. The idea is simple, but the implementation turned out to be complex, largely because of the need to upgrade all the servers that serve specific roles (e.g., Global Catalog—GC—servers) to Windows 2003 and because of the amount of manual intervention (e.g., tweaking the infamous ValidPorts registry setting) necessary to configure network components to handle the RPCs en route between clients and servers.
Changes in Exchange 2003 SP1 simplify the feature somewhat. A successful RPC over HTTP implementation still requires your domain controllers (DCs) and Exchange 2003 servers to run on Windows 2003. But SP1 updates the System Attendant service to use the DSProxy service, rather than a direct link to a GC, to refer Outlook clients to the Exchange server. This change eliminates the need to upgrade all your GC servers to Windows 2003 (although doing so is still a good idea). Also, SP1 adds a tab to the Exchange server Properties dialog box that you access through Exchange System Manager (ESM); this tab lets you configure the server's role in RPC over HTTP transactions. (An Exchange 2003 server can fulfill one of three roles in an RPC over HTTP scenario. It might not handle RPC over HTTP connections, it might be a front-end server that proxies connections onward, or it might be a back-end server that hosts the mailboxes to which clients connect.) You now can also configure ESM to show the RPC-HTTP field, which displays the server's role.
Commentators often criticize Microsoft for adding features that require manual configuration via arcane command-line utilities or numerous registry changes, so it's good to see that the company has updated the ESM UI to make things easier. Now, if it would just eliminate the need to run Eseutil and Isinteg from the command line to fix database problems ...
Self-Healing Single-Bit Errors
Manufacturers of memory modules commonly implement Error-Correcting Code (ECC) algorithms that automatically detect and correct single-bit memory errors (aka bit flips). These errors occur when a single bit of data that should contain a 0 changes to 1, or vice versa. When ECC detects that a bit has an unexpected value, the code can correct the value and proceed.
Microsoft data indicates that as many as 40 percent of -1018 errors are simple bit flips, so implementing an ECC algorithm for the Exchange Store was a no-brainer. Exchange 2003 SP1 does just that and updates the format of pages inside the Exchange database (EDB) from a 4-byte header to an 8-byte header consisting of two 32-bit checksums. The first checksum is an exclusive OR (XOR) checksum that the Store uses to read the correct page off disk or commit the right page into memory. The Store uses the second 32-bit checksum as an ECC check to correct single-bit errors on the page.
Together, the extra intelligence in the Store and the expanded checksum processing lets the Store self-heal some -1018 errors as they occur. To help you track this activity, Exchange uses several event log events. Event ID 474 reports multiple-bit-1018 problems. Event ID 399 indicates that the Store encountered a single-bit error that it was able to correct in memory. (The error might still exist on disk because the Store only corrects a problem on disk when it updates a page and commits that page back into the database.) Event ID 398, which Microsoft believes will be rare, signals a more serious error that occurs when the Store corrects a single-bit error but subsequently believes that the page is still invalid, perhaps because of a checksum failure.
Of course, like any change to the Store, the introduction of ECC slightly complicates the SP1 upgrade procedure. When you apply SP1 to a server, the upgrade process doesn't attempt to upgrade the entire Store at once; doing so would take too long for anything but small servers. Instead, the Store upgrades its page format to accommodate ECC as users access and update individual pages. Over time, the Store will update all the pages to the new checksum format, thus completing the database update. This phased approach means that you can't restore a backup of an SP1 server to a pre-SP1 server because the pre-SP1 Store won't understand the ECC data that SP1 adds to each page and will therefore consider the pages to be corrupt. If you want to update a database completely after installing SP1, you can run Eseutil with the /D parameter to rebuild the database and update each page. Be sure to take a full backup before and after the rebuild, however, because this operation renders invalid any transaction log generated beforehand.
Speaking of backups, Exchange 2003 SP1 also includes a subtle change in the way that the Store processes online backups. The Exchange backup API includes code to validate each page as it streams out of the database into the backup saveset. If you aren't running SP1 and the backup encounters a -1018 error, the backup API terminates processing to avoid a flawed backup. When an online backup is successful, you know that the Exchange database has no detectable problems. Starting in SP1, if a backup finds a single-bit error, it reports the problem but continues with the backup. Therefore, a backup saveset can contain known errors. If you restore the backup, the Store will deal with these errors as it updates the pages. (A multiple-bit error will still cause the backup to fail.)
Worth the Wait
Exchange 2003 SP1 builds on a solid initial release, making some features easier to use, fixing deficiencies in others, and generally tidying up the base product. If you've been waiting for the service pack before you'll upgrade to Exchange 2003, wait no longer. If you're already running Exchange 2003, the decision to upgrade should be straightforward. (The upgrade from Exchange 2003 to SP1 is easy, fast, and requires only one change to the underlying Windows infrastructure—a Microsoft IIS hotfix that affects OWA. The Microsoft article "FIX: IIS 6.0 compression corruption causes access violations," at http://support.microsoft.com/?kbid=831464, explains the problem.) And as an added plus, you can download and use several new tools that offer even more functionality for Exchange 2003 SP1 servers (see the Web-exclusive sidebar "Exchange 2003 SP1Related Tools," http://www.windowsitpro.com, InstantDoc ID 43599, for details). As always, try out the service pack in a test environment and be sure to take a full backup before you upgrade your production servers.