An important question in any upgrade project is which servers to replace first, which next, and which last. Exchange 2000 Server does not impose many restrictions on you. Theoretically, you can upgrade existing Exchange servers in your organizations in any order. In practice, however, certain restrictions may apply. As a matter of fact, it may not be possible to upgrade all servers if, for instance, a system is running a component not supported by Exchange 2000 Server. You should carefully review the configuration of the target server prior to its upgrade because Exchange Server 5.5 and Exchange 2000 Server are not fully compatible, as explained in Lesson 2.
This lesson discusses both the direct and indirect upgrades of Exchange Server resources. You will read about the advantages and disadvantages of both approaches and their particular requirements. The information from this lesson can help you determine the best upgrade strategy for each server in your organization.
You can upgrade to Exchange 2000 Server in two possible ways: You can upgrade servers directly or you can integrate new servers and then move existing resources, such as mailboxes, public folders, and connectors, to the new system in a second step. The first approach may be easier. Of course, it is a cost-effective strategy because you do not need to purchase new hardware, and software license costs are minimized. Remember, for indirect upgrades, which require both servers to run simultaneously for a period of time, you need to purchase a new server license. However, the second method also has advantages. Among other things, an indirect upgrade allows you to modernize the server infrastructure and consolidate resources from different servers on a single system.
The direct, or in-place, upgrade is simple and promises quick results. You only need to ensure that the server is running Windows 2000 Server Service Pack 1 and Exchange 5.5 Server Service Pack 3, and that the SMTP und NNTP services are installed. The upgrade is straightforward indeed. When you launch the Exchange 2000 Setup program directly on the server, the previous version is detected automatically and Setup switches into upgrade mode. The installation requirements for Exchange 2000 Server are discussed in Lesson 2.
The simpler an upgrade procedure, the less control you have over the actual upgrade process because most of the work is accomplished in the background automatically. For instance, the Exchange 2000 Setup program does not allow you to add additional components or change the existing configuration in any respect. If you want to add or remove components you need to launch Setup again after the upgrade. Less control also means that you have to prepare the target system carefully beforehand to ensure that the upgrade proceeds smoothly.
A careful preparation for an upgrade to Exchange 2000 Server should include the following steps:
In spite of its simplicity, there are several situations in which the direct upgrade does not deliver the desired results. For instance, the specific business situation of your organization may demand a high availability of messaging resources in your environment, but the in-place upgrade stops the Exchange Server services to convert the Information Store databases. This process works with approximately 8 GB per hour, which can be considered extremely fast; however, for a server with 32 GB of mailbox and public folder data, this still means that the system is unavailable for approximately 4 hours.
Furthermore, when you upgrade an Exchange server to Exchange 2000, you lose connector configuration settings, as outlined earlier. This can lead to a situation where message transfer is inefficient or interrupted, in which case you would need to manually correct the system configuration. Several components not supported under Exchange 2000 Server will become completely unavailable after the upgrade.
It is not possible to upgrade the following features of Exchange Server 5.5 using the in-place approach:
Note
The principle of the indirect upgrade is simple: You join an existing site with a new Exchange 2000 server, move all resources from legacy servers to this computer, and, as soon as all resources have been moved, the old systems can be decommissioned. This upgrade strategy is a perfect opportunity to replace outdated server hardware, but you can also reuse the old hardware for subsequent Exchange 2000 server installations, which is known as a leapfrog upgrade (see Figure 6.16).
Figure 6.16 - The leapfrog upgrade method
Perhaps the most significant advantage of the indirect upgrade method is the minimization of system downtime during the upgrade process. Databases are not directly converted and all server systems are always active. For instance, you can replicate public folders to the new server and fix permission inaccuracies without interrupting any existing business processes. All users still reside on legacy Exchange servers, and while you are correcting the permission settings in Exchange 2000 Server, users can continue to work with the contents in Exchange Server 5.5.
When you move a mailbox to a new server, downtime is minimal. The client will be disconnected for the time of the operation, but the user can immediately reconnect as soon as the mailbox is on the Exchange 2000 server. On the next connection attempt, the old server will redirect Outlook 2000 to the new server automatically. You do not need to reconfigure any client settings. Until you inform them, your users may not even be aware that they are now using Exchange 2000.
Note
The limitations of the indirect upgrade method are primarily related to server-based configuration settings and messaging connectors. This is not necessarily a disadvantage. For instance, legacy Exchange servers may contain several registry keys altered by the legacy Performance Wizard (PerfWiz). Exchange 2000 Server uses a different and more dynamic method to optimally utilize the server hardware, but critical registry settings may cause Exchange 2000 to malfunction. The indirect upgrade avoids this problem. PerfWiz is not part of Exchange 2000 Server.
Likewise, you cannot use the indirect upgrade method to convert existing messaging connectors. Upgrading messaging connectors indirectly means manually configuring new connector instances on the new server and then deleting the existing instances on the old system. Again, this is not necessarily a disadvantage. In fact, it may be an advantage because old connectors may coexist with new connector instances, providing fault tolerance for each other. At your own pace, you can carefully establish the new routing group topology (within mixed-mode constraints), test the new connectors for reliability and performance, and then decommission the old connectors. If a particular Exchange server runs connectors not supported in Exchange 2000, such as a PROFS, SNADS, or third-party connector, you can move all supported resources and components away from this bridgehead and let it focus on connectivity to the foreign systems. As explained in Lesson 2, Exchange 2000 users can use connectors running on Exchange servers and Exchange users can use Exchange 2000 connectors.
Clustered Exchange Server systems are also best upgraded indirectly, as it is not simple to upgrade an Exchange Server cluster directly. You would have to back up the existing Information Store databases and then remove the clustered Exchange Server 5.5 installation from the cluster. After that, you would have to install Exchange 2000 on all cluster nodes and configure a virtual server.
Because of Information Store dependencies, it is important to use the same name for the virtual Exchange 2000 resource group (virtual server) that the former virtual Exchange server was using. You must not bring this virtual server online yet. You need to delete the contents of the Exchsrvr\MDBData directory, restore the databases, and rename the PRIV.EDB and PUB.EDB files to PRIV1.EDB and PUB1.EDB. At this point, you could take the virtual Exchange 2000 server online.
In contrast, the indirect upgrade is much less complex: Just move the resources away from the cluster to a nonclustered Exchange 2000 server, remove the Exchange Server 5.5 installation, install Exchange 2000 Server on all cluster nodes, configure your virtual servers, and then leisurely move the resources back into the cluster. You can read more about clustered Exchange 2000 installations in Chapter 10, "Designing Fault Tolerance and System Resilience for Microsoft Exchange 2000 Server."
Perhaps the only system that you should not upgrade using the indirect approach is the directory replication bridgehead. Moving a directory replication bridgehead to another server is quickly accomplished in the Exchange Administrator program. However, changing the configuration of a directory replication connector resets the intersite directory replication. The result is a full replication of the entire Exchange Directory database to all other sites. This may dramatically increase the traffic in your corporate backbone. To avoid this, upgrade directory replication bridgehead servers directly. If your replication bridgeheads run any components not supported by Exchange 2000 Server, consider moving these components to other servers instead of the replication connectors (see Figure 6.17).
Figure 6.17 - Upgrading a directory replication bridgehead with components not supported in Exchange 2000 Server
Note
More Info: Rollback of Indirect Upgrades
The direct upgrade does not provide much room for rollback mechanisms. If the upgrade fails for any reason, you have to restore the old system from the most recent backup. If you need to rollback after users have connected to the Exchanger 2000 Server, data may be lost. Indirect server upgrades are more flexible. For instance, if the replication of a public folder to Exchange 2000 Server fails, a folder replica still exists on the old system. You only need to remove the failed replica from the Exchange 2000 server and the upgrade is rolled back.
Likewise, automatic rollback mechanisms help prevent trouble if the upgrade of mailboxes (that is, moving mailboxes to the new server) fails. The mailbox move upgrade may fail, for instance, if the mailbox owner’s user object in Active Directory does not have correct msExchMailboxSecurityDescriptor or msExchMasterAccountSID information. This can happen when the ADC creates disabled user accounts for resource mailboxes. Enabling all user accounts with mailbox information in Active Directory avoids this problem. You can disable the user accounts again after the mailboxes have been moved.
To move a mailbox to Exchange 2000 Server using the Active Directory Users and Computers console, the following steps must occur:
Following a successful upgrade, you should immediately perform a full online backup of the Exchange 2000 Information Store. Otherwise, if a disaster strikes before you back up the system, you have to restore the old Information Store databases on the Exchange server, adjust the Directory/Information Store consistency, and then repeat the entire upgrade process. Be sure not to overwrite your final Exchange 5.5 upgrade!
Exchange 2000 Server, like its predecessors, relies on directory replication to propagate configuration changes to all servers in the organization. The servers, in turn, provide their clients with vital information about the location of information in the messaging organization. Directory replication takes time. Impatiently over-configuring the system does not bring faster results, but can cause serious trouble.
Applied to the indirect upgrade method, this means that you should not decommission your legacy servers as soon as all resources are moved to an Exchange 2000 server. The old server still holds valuable information in its directory and information store. For instance, when you move a mailbox between servers, the clients are disconnected, but the users’ MAPI profiles are not immediately updated. Consequently, the clients will attempt to reconnect to the old server. The old server knows the new location of the mailbox because this information is available in its directory, and it can redirect MAPI clients accordingly. If you remove the old server too quickly from the organization, clients cannot reconnect automatically and you must reconfigure the clients manually. To users it will seem that the entire messaging environment is out of order. You can avoid this unnecessary trouble if you wait until all users have reconnected to their mailboxes to continue with server removal.
The same is true for public folders. When moving public folders to Exchange 2000, you can remove the old replica in the Exchange System Manager snap-in without waiting for the contents to replicate. The old replica remains on the Exchange server until the contents are entirely transferred to the new server. However, if you remove the old Exchange server too quickly, users might end up with an empty folder in Exchange 2000. Unfortunately, no feature exists to replicate public folder contents on demand. Furthermore, you should wait until all Outlook users have accessed the public folders on the new server before proceeding with the server removal. Outlook may cache the names of public folder servers in the MAPI profile, and, if a server has been removed, the client may hang when it is attempting to access public folders. Again, be very patient if you want to remove a server after its public folders have been moved to avoid unpleasant Outlook 2000 issues.
Figure 6.18 - Redirecting MAPI-based clients to a new home server
It is safe to remove Exchange servers under the following conditions (if there are multiple resources on one server, more than one criterion may apply):
It is advantageous to switch the Exchange organization into native mode as soon as all Exchange servers are upgraded. This eliminates mixed-mode limitations and allows you to consolidate resources across administrative group boundaries. However, as long as computers running previous Exchange Server versions exist in your organization, changing to native mode is impossible. Consequently, in the Exchange System Manager snap-in, the Change Mode button in the General tab of the organization object is deactivated.
Indirectly upgraded Exchange servers require manual cleanup. Launch the Exchange Server 5.5 Setup program directly on the server you want to remove and select the Remove All option. After that, launch the Exchange Administrator program and connect to another Exchange server to delete the server reference from the Exchange Directory. The Exchange Directory replicates the configuration changes to the SRS, where the configuration CA causes the ADC to incorporate the changes into Active Directory.
The last Exchange 5.5 server must be deleted from the SRS database manually because no other Exchange directory service exists in the site to accomplish this via directory replication. Use the Exchange Administrator program and specify the Exchange 2000 server that runs the SRS as the server to connect to. Once the last Exchange server is removed from Active Directory, you can switch the organization into native mode, which irreversibly removes the SRS. You need to remove the ADC environment manually.
Note
The most important questions that your upgrade plan must address relate to the order in which you plan to upgrade the systems in your organization and the desired upgrade methods. This usually requires a review of the existing network infrastructure and administrative topology. You also need to check the documentation about available server hardware to determine whether existing systems can be reused for Exchange 2000 Server.
Your project plan should provide answers to the following questions:
Note
When all public folders and mailbox resources are on Exchange 2000 Server, upgrade the directory replication bridgeheads to shift the intersite directory replication to Active Directory. If possible, perform an in-place upgrade of the directory replication bridgeheads. In a last step, establish the new routing topology by either upgrading the existing messaging bridgeheads or installing new bridgehead servers and messaging connectors.
Table 6.3 Exchange Server Roles and Preferred Upgrade Methods
Server Type | Preferred Upgrade Method | Comments |
---|---|---|
Any server with hardware not capable of running Exchange 2000 Server | Indirect upgrade | Use the Performance Monitor utility to determine the resource utilization on the current machine. Choose the hardware for the new Exchange server based on the utilization of the server being replaced, and be sure to accomodate for growth. |
Directory replication bridgehead | Direct upgrade | The Exchange 2000 Setup program will activate the SRS on replication bridgeheads automatically. Existing directory information is incorporated into the SRS database. The existing directory replication configuration is not affected. You do not need to replicate the entire directory replication with remote replication bridgehead servers. |
Exchange Server cluster | Indirect upgrade | A genuine direct upgrade is not possible for clustered Exchange servers, although the databases may be converted directly in a complex procedure that relies on database backups. It is less risky and more convenient to upgrade clustered Exchange servers indirectly. |
Mailbox server | Direct or indirect upgrade | Similar to public folder servers, the decision depends on various factors, such as availability requirements, and whether server hardware should be replaced. Many organizations choose the indirect upgrade method to minimize system downtime or consolidate server resources on a powerful Exchange 2000 server. |
Messaging bridgehead (connector server) | Indirect upgrade | New connector instances can back up existing connectors. You can establish the new routing topology independent of the existing infrastructure. It is possible to prevent message routing over legacy connectors (cost factor = 100). This also minimizes the risk of broken message paths. The direct upgrade has no advantages over the indirect upgrade because many connector settings must be reconfigured after the direct upgrade, as well. Furthermore, unsupported connectors may effectively prevent the direct upgrade. |
Public folder server | Direct or indirect upgrade | The decision depends on several factors, such as the required system availability (if no other replicas exist in the organization), the amount of data to be upgraded, and the desirability of new public folder servers. |
Wide World Importers’ Exchange organization consists of roughly 60 sites with an average of approximately two servers per site: One server is usually responsible for message transfer and intersite directory replication, and the other server holds the mailboxes and public folders. Small sites have only one server that assumes all responsibilities. The Exchange organization is fully integrated with Active Directory. Wide World Importers plans to replace the existing hardware with new and more powerful computers that can guarantee sufficient system response times after resource consolidation.
To keep global directory replication and message transfer under control, the company has implemented a central hub site called HUB, which contains two servers for directory replication, message routing, and Internet connectivity. The hub site is located in New York, and so is the largest site in the Exchange organization, which is called New York. The site New York contains one replication and messaging bridgehead and two servers that each hold 1000 mailboxes and approximately 500 public folders. Several public folders are replicated between both servers.
It is important to note that the messaging bridgehead also connects the site to a Fisher TAO messaging system running on an IBM S/390 mainframe. For historic reasons, some users in New York still work with Fisher TAO, although they also have a mailbox in the Exchange organization. It is not possible to decommission Fisher TAO at this point. The architecture of the central site New York is shown in Figure 6.19.
Figure 6.19 - Wide World Importer’s messaging environment in New York
Peter Waxman, Head of Communications Technology, decided to use the following strategy to upgrade the server systems in New York.
In this activity, you will develop an upgrade strategy for Adventure Works’ global messaging organization.
Tip
Adventure Works has globally deployed Exchange Server 5.5, is synchronizing Exchange recipient information with Active Directory, and does not operate any foreign messaging systems. The company has already upgraded the server VAC-02-EX, which now runs Exchange 2000 Server in the site of North America (see Figure 6.20). Adventure Works does not heavily utilize public folders. All public folders have been moved to VAC-02-EX, and the server also runs an SMTP Connector to DMZ-01-SMTP. Furthermore, VAC-02-EX is the directory replication bridgehead for the site of North America.
It is your task to recommend an appropriate upgrade strategy:
Figure 6.20 - The messaging environment of Adventure Works after the implementation of the first Exchange 2000 server
You can upgrade Exchange Server 5.5 resources to Exchange 2000 Server either directly or indirectly. The direct method is simple: Simply run the Exchange 2000 Setup program directly on the server. This program takes care of the remaining tasks. The indirect upgrade, on the other hand, is more labor-intensive than the direct approach, but also less risky. Incorrect configuration settings, for instance, are not retained, all server services remain active, and resources can be migrated individually and from different servers. The indirect upgrade is most suitable if you plan to replace existing servers with new hardware, if you plan to consolidate resources from different Exchange servers, or if you intend to upgrade a clustered Exchange server.
To determine the best upgrade approach, carefully review the server configuration. Several components, such as PROFS or SNADS connectors, are not supported in Exchange 2000 Server and therefore cannot be upgraded. If your Exchange organization requires any unsupported components, not all servers can be upgraded. Furthermore, specific server configurations, such as directory replication bridgeheads, may require a specific upgrade approach. Generally, directory replication bridgeheads should be upgraded directly to avoid resetting the intersite directory replication.
When upgrading mailbox and public folder resources using the indirect upgrade approach, remember that the legacy servers still fulfill an important role in the organization. They are required to redirect MAPI-based clients, such as Outlook 2000, to the new servers. If you decommission the old servers too quickly, you will have to reconfigure MAPI profiles manually, which can be a very time-consuming job if there are many affected users. Before permanently removing any systems, shut down the Exchange services and verify that this does not cause problems in the messaging organization. You should obtain official approval from the project sponsor and the project team before removing a server.