Deployment Changes in Exchange Server 2003 SP1


Topic Last Modified: 2007-12-20

Published: July 15, 2004

By Nino Bilic

Reprinted with permission of You Had Me At EHLO...aka the Microsoft Exchange Team Blog.

Microsoft Exchange Server 2003 Service Pack 1 (SP1) brings us a lot of new features that customers have been requesting as well as updates made since Exchange Server 2003 was released. This page describes the major features of SP1. This is not a complete list of features. For more documentation, visit the Exchange 2003 Technical Documentation Library page.

This is probably the biggest change that we are getting. This functionality enables you to do cross-site moves of mailboxes, distribution lists, custom recipients, and public folder directory objects between sites while your Exchange organization is still in mixed mode and is intended to be used when moving objects from Exchange Server 5.5 sites.

Previously, you were able to move mailboxes between administrative groups only when your organization was switched to native mode, so no servers running Exchange 5.5 could be present.

There are several things that we must have to perform a good cross-site move, such as:

  • Active Directory Connector (ADC) must be upgraded to Exchange 2003 SP1.

  • The May 2004 Update Rollup for Exchange Server 5.5 must be installed on Exchange 5.5 servers. You can download the update from Microsoft Knowledge Base article 836489, An update is required for mixed-mode site consolidation with Exchange Server 5.5.

  • Directory replication between Exchange 5.5 servers and Site Replication Service (SRS) must be functioning correctly. There are more details about all this but—it is absolutely essential that ADC and directory replication work correctly or else the cross-site move will fail. Large environments have to wait until all of the replication after the cross-site move settles.

In case there is a question about distribution group memberships and e-mail addresses, the cross-site moved objects preserve the distribution group memberships and their original e-mail addresses. Yeah—that is very cool :)

This is a new tool that we have created to make the updating of Microsoft Outlook profiles easier after the mailbox has been moved cross-site. This is a command-line tool that can then be deployed and scripted as such to make it easier to touch the registries on multiple clients (the client registry is where we keep the client profile information). The use of the profile update tool is required for proper and supported configuration that will actually work after mailboxes have been cross-site moved. If the tool is not run, the clients must create new Outlook profiles.

The major advantage with the recovery storage group in the Exchange 2003 released version is that it provides greater flexibility when restoring mailboxes and mailbox stores, because you are no longer required to set up a separate Active Directory and recovery server. You can now simply recover to the same server or to any server in the administrative group.

In Exchange 2003 released version, after you restore a mailbox store to the recovery storage group, you must use the Exchange 2003 ExMerge tool to move the recovered mailbox data from the recovery storage group to the regular storage group.

This could be confusing because it requires a separate tool. The Recover Mailbox Data feature in Exchange 2003 SP1 Exchange System Manager replaces the necessity to use ExMerge in the majority of recovery cases.

The new functionality enables you to either merge or copy the data from mailboxes restored to the recovery storage group while using a user interface very similar to Move Mailbox. You select the mailboxes from within Exchange System Manager.

Even though the Recover Mailbox Data functionality (the new way) can be compared with ExMerge functionality (the old way), Recover Mailbox Data does not use the ExMerge engine. So, there are no personal folder (.pst) files involved and there is subsequently no 2-gigabyte (GB) limitation that you have with .pst files. Also, there are still a few scenarios where ExMerge would be a better tool than Recover Mailbox Data.

For more information, see Exchange Server 2003 SP1 Recover Mailbox Data Feature.

In the initial release of Exchange 2003, a common concern about using the ADCTools functionality to generate connection agreements for large or complicated environments was the lack of control over what connection agreements would be created. Whatever connection agreements were created by ADCTools would replace existing connection agreements. Additionally, whatever connection agreements it created would immediately begin to replicate without providing any opportunity to review the new connection agreements first.

Changes to ADCTools in Exchange 2003 SP1 enable better control over the connection agreements that are created, including the ability to postpone initial replication until after connection agreements have been reviewed by the administrator. We are providing an XML file (that ADC will look for when creating new connection agreements) that configures the behavior of new agreements—if they will be enabled for replication immediately or not. We are also providing a script that can be used to bulk-enable all connection agreements for replication at the later time.

As far as ADC itself goes—there are multiple changes that went into ADC that make the cross-site resource move possible, too, because ADC has done a bunch of work in that area.

In the released version of Exchange 2003, configuring the remote procedure call/secure Hypertext Transfer Protocol (RPC/HTTPS) front-end and back-end topology involved a lot of manual registry editing and was very hard to maintain as new servers were added or removed.

Exchange 2003 SP1 includes an Exchange System Manager integrated user interface (UI) that you can use to easily select RPC/HTTPS front-end and back-end servers. The new UI is in the Properties dialog box of the server selected in Exchange System Manager.

In versions previous to Exchange 2003 SP1, no matter how many nodes in the cluster you had, you could only have one instance of public folder store that was associated with the MAPI folder tree. In Exchange 2003 SP1, we have added the ability to have multiple MAPI public folder databases on the single multinode cluster. Considering that Outlook 2003 cached mode puts a greater strain on folders like the Outlook Address Book, providing the ability to spread the load across multiple public folder stores in a cluster creates a better client experience.

There have been several changes in the database engine:

  • Improved transaction log replay   This has been greatly improved, especially in the speed of transaction log replay. This obviously does depend on the hardware quite a bit, too, but the gains are significant on any hardware when comparing with database engines in versions earlier than Exchange 2003 SP1.

  • Built-in correction of -1018 errors   Because of the different checksum model that has been introduced in Exchange 2003 SP1, the database engine is now able to correct a single bit database page checksum errors. In our experience, a lot of the -1018 errors we have seen were single-bit errors, so this should help.

The updated domain rename script, released in the Exchange 2003 SP1 time frame, enables a domain with Exchange servers in the organization to be renamed. In order to make the tools easier to update, the tools are not included on the CD anymore but can be found on the Downloads for Exchange Server 2003 page.

Make sure you read the documentation included with the new Domain Rename script.


Community Additions