Lesson 3: Upgrading Exchange Server 5.5 to Exchange 2000 Server

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.

After this lesson, you will be able to

  • Describe the advantages and disadvantages of direct and indirect upgrade strategies
  • Determine an appropriate upgrade strategy for your computers running previous versions of Exchange Server

Estimated time to complete this lesson: 90 minutes

Exchange Server 5.5 Upgrade Methods

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.

Direct Upgrade

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:

  1. Back up the entire server, including executable files, operating system, system state, and Exchange Server databases. If possible, restore the backup on a test machine and perform an offline integrity check using the ESEUTIL.EXE utility to ensure that the databases are free of corruption. After that, run the Exchange 2000 Setup program on the test system to see if problems arise during the upgrade. Never connect your test server to the production environment. It may be required to seize the schema master role on your test system to run the Setup program successfully. You can read more about database utilities and the preparation of an appropriate test environment in Chapter 11, "Designing a Disaster Recovery Plan for Microsoft Exchange 2000 Server."
  2. Check the Information Store/Directory consistency on the target Exchange server in the Exchange Administrator program. Enable the option to remove unknown user accounts from mailboxes and public folders. Removing unknown accounts helps to prevent permission-related upgrade problems, as explained in Lesson 2.
  3. Verify that the owners of public folders on Exchange Server 5.5 are in Active Directory. If this is not the case, access to public folders will be denied after the upgrade and owners will not be able to configure their folders. You would have to use the Exchange System Manager snap-in to correct the public folder settings.
  4. Run the MTACHECK.EXE utility on the target Exchange server. MTACHECK examines the message queues of the message transfer agent (MTA) and removes any corrupted messages that may cause problems during the upgrade.
  5. Document the configuration of any messaging connectors on the target Exchange server. Most of the connector configuration is preserved; however, some information, such as per-domain routing configurations of an IMS, is not upgraded. For connectors to foreign messaging systems, you will need to reconfigure directory synchronization schedules, address spaces, import and export containers for directory synchronization, and delivery restrictions. The Exchange 2000 Setup program will log details about lost connector settings in the setup log file.
  6. Document the configuration of any Internet access protocol services, such as the Post Office Protocol version 3 (POP3) and Internet Mail Access Protocol version 4 (IMAP4) services, on the target Exchange server. The Exchange 2000 Setup program will preserve values in the mailbox and public stores, but the actual configuration of the protocol interfaces is lost. In Exchange 2000 Server, you need to reconfigure the POP3 and IMAP4 services based on Internet virtual server instances. This is explained in more detail in Chapter 8, "Designing Hosted Services with Microsoft Exchange 2000 Server."

Direct Upgrade Limitations

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:

  • Address book views
  • Dial-up connections
  • PROFS/OfficeVision connector
  • SNADS connector
  • X.25 Eicon Stack
  • Remote Access Server (RAS) MTA stack
  • TP4 stack
  • RAS X.400 connector
  • Customized OWA solutions
  • Third-party components, such as gateways, not supported on Exchange 2000 Server

Note


Components not supported by Exchange 2000 Server will need to run on Exchange 5.5 servers. Dynamic RAS connectors can be removed before the upgrade and replaced with Exchange 2000 connectors using Routing and Remote Access Service (RRAS) to establish the dial-up connections in the network.

Indirect Upgrade

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


When you are moving mailboxes from Exchange Server 5.5 to Exchange 2000 Server, users will be disconnected from their mailboxes. It is advantageous to schedule upgrades for a period when few users are accessing their mailboxes, such as on a weekend. You do not need to move all mailboxes at once. In fact, moving mailboxes gradually will minimize the impact of unanticipated problems related to the new server. You can move mailboxes individually or in small groups, and you can move resources from different Exchange servers to the same Exchange 2000 server.

Indirect Upgrade Limitations

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


Whenever you change the directory replication topology in an Exchange site, a full replication of the directory is performed to all other sites.

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:

  1. The Exchange Tasks Wizard connects to the Information Store of the source and target servers. If any of these connection attempts fails, the move operation also fails, and the mailbox remains on the source system.
  2. As soon as the connections are established, the Exchange Tasks Wizard copies the mailbox information from the source to the target Information Store. If this copy process fails, any data already copied is deleted and the mailbox remains on the source system. The complete set of private folders and messages is still available in the source mailbox.
  3. When the Exchange Tasks Wizard completes the copy process, the mailbox information in the recipient and user object is updated to reflect the mailbox’s new home server. This information is updated in both Active Directory and the Exchange Directory. If this process fails for any of the directories, the system rolls back the changes and the mailbox remains on the source system. The original mailbox is still available on the source server.
  4. When the copy process and directory updates complete successfully, the mailbox has been moved to the target server successfully. The Exchange Tasks Wizard now deletes the old mailbox from the source Information Store. The mailbox is now on the target system and contains the complete list of private folders and messages. If the deletion of the mailbox fails, it will be removed from the original Information Store database during the next maintenance cycles because the mailbox’s home server attribute now points to the new server.

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!

Decommissioning Exchange Servers

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):

  • Any server types In general, you should not uninstall any servers unless you are absolutely sure they are no longer required in the mixed-mode organization. Before decommissioning any systems, shut them down for an extended period of time (such as one week or more) and carefully test the system behavior. Should problems occur, start the old system again, correct the configuration, finish the directory and public folder replication, then shut down the services again and engage in another extended test. It is a good idea to obtain official approval from the project team, system administrators, and the project sponsor for the permanent removal of systems.
  • Directory replication bridgehead server Preferably, upgrade this system directly. However, if you intend to replace a replication bridgehead indirectly instead, wait for the configuration changes to replicate to all bridgeheads in the remote sites. As soon as the desired Exchange 2000 server running the SRS is displayed in the directory replication connector configuration on all remote replication bridgeheads, the old Exchange server is no longer considered a directory replication server and can be removed safely.
  • Mailbox server Make sure all mailboxes have been moved successfully to the new Exchange 2000 server. Wait until all users have reconnected to their mailboxes, as explained earlier.
  • Messaging bridgehead server Configure appropriate connectors on the new Exchange 2000 server and set the cost value for the connectors on the old bridgehead to 100. Connectors with a cost value of 100 are excluded from message routing, although they are still available and can empty their message queues. Use the message-tracking feature of Exchange 2000, diagnostics logging, and SMTP protocol logs to verify that the new system is performing message transfer properly. When the old server has emptied its message queues and no further messages are routed to the old connectors, the bridgehead server can be decommissioned. Keep in mind that you cannot remove bridgeheads that run connectors unsupported in Exchange 2000 Server. These servers must remain in the organization until they are no longer needed.
  • OAB server By default, the first server in the Exchange site assumes the role of the OAB server holding the OABs for all MAPI-based clients. As long as an Exchange server exists in the site, the OAB must be on an Exchange server. It is possible to move the OAB to any Exchange server in the site, as explained in Lesson 2.
  • Public folder server Make sure the replication of public folder hierarchy and contents is complete. Do not forget to replicate the system folders, such as the Schedule+ Free Busy folder to the new server. Remove any replicas from the old public folder server and make sure all users still have access. Verify that the public folders show a status of In Sync on the Exchange 2000 server and that all users have access to the public folders on the new server.
  • Routing recalculation server The routing recalculation server updates the GWART in the Exchange site. Directory replication will then propagate the new GWART to all other servers in the site. A routing recalculation server is required as long as there is an Exchange 5.5 server in the site. You can assign any server in the site this task, if necessary. Launch the Exchange Administrator program, display the properties of the Site Addressing object, which is in the Configuration container of the site, and then change the server in the General tab, under Routing Recalculation Server.

Switching to Native Mode

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


Switching to native mode irreversibly disables interoperability with previous versions. Do not switch to native mode if Exchange Server 5.5 may be needed in the foreseeable future, for instance, to run messaging connectors not supported in Exchange 2000 Server.

Developing an Upgrade Plan

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:

  • Which Exchange site should you upgrade first? Answering this question is a matter of personal preference. Quick and visible success is vital to any upgrade project. For this reason, you may want to upgrade the largest Exchange site first. If you feel uncomfortable starting with a highly visible location, provide appropriate system training and practice the upgrade steps repeatedly in a test lab until you are confident that your project team has the required competency to accomplish the job professionally. However, production environments often contain surprises not accounted for in the test lab. For this reason, many administrators prefer to start with small or low-priority servers.

    Note


    Many large organizations have implemented a central site dedicated to directory replication and message transfer. Typically, this site does not contain mailboxes or public folders. For this reason, you may want to upgrade this site last.

  • Which server do you plan to upgrade first? Generally, you can upgrade your servers in any order. Due to interoperability issues, however, it may be advisable to start with public folder servers. Make sure that all users can work with the public folders on Exchange 2000 Server, and then upgrade the mailbox servers. This approach results in immediate deliveries because your users and administrators will then be able to use all Exchange 2000-specific features right away. This approach also mitigates the risk of interrupted message transfer. The legacy Exchange connectors are available to all users in the organization and ensure that all users can communicate with each other.

    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.

  • Do you want to replace the existing server hardware? Answers to this question will help you estimate the required budget for the upgrade project as well as the appropriate upgrade procedures. If you intend to replace the existing server base, for instance, the indirect upgrade method is most appropriate. In-place or leapfrog upgrades are possible if you intend to reuse the existing server hardware.
  • Are you running any applications or connectors on the Exchange servers that are not supported in Exchange 2000 Server? If this is the case, you cannot upgrade the system to Exchange 2000 unless the unsupported components are no longer needed and can be removed. Consider concentrating all unsupported components on a separate Exchange server. Keep in mind that as long as a server running a previous version exists in the organization, you cannot switch to native mode. Your upgrade plan should also outline required steps to update unsupported applications or connectors with versions supported in Exchange 2000. Third-party connectors based on the Exchange Development Kit (EDK) may need new versions to support Exchange 2000 Server.
  • Do you want to consolidate multiple Exchange servers on one Exchange 2000 server? If you plan to consolidate server resources, consider implementing a powerful new machine and upgrading to Exchange 2000 using the indirect upgrade method.
  • Do you want to consolidate sites into one administrative group? This is an important question that you need to answer before installing the first Exchange 2000 server in the organization. If you determine that your organization requires components not supported in Exchange 2000, making it impossible to switch the organization into native mode, you will not be able to move mailboxes across administrative group boundaries. In other words, it will not be possible to consolidate sites into one administrative group unless you use the Move Server Wizard to bring all servers into the same site before the first Exchange 2000 server is installed. Resource consolidation is discussed in Lesson 2.
  • Which method should you use to upgrade Exchange servers? The in-place upgrade is perhaps easier to accomplish, but also more risky than the indirect upgrade methods. If you intend to reuse your server hardware, consider leapfrogging as an interesting alternative to direct upgrades. Refer to Table 6.3 to determine the best possible upgrade strategy.

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.

Designing an Upgrade Plan for Wide World Importers

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.

  1. The central HUB site will not be upgraded until all locations have moved to Exchange 2000 Server. Daily, full online backups will be scheduled for all servers in the site New York. A full restore of all server systems must be accomplished on a test server before launching the upgrade.
  2. Because Wide World Importers intends to consolidate the user data on a single Exchange 2000 server, implement a new and very powerful machine (NYC-2001-EX), and use the indirect upgrade method to migrate mailbox and public folder resources:

    1. In a first step, replicate all public folders to NYC-2001-EX and verify that all permissions are upgraded properly.
    2. Next, remove all public folder instances from the legacy Exchange servers and verify that all users still have access to all the data.
    3. Move the mailboxes from NYC-02-EX and NYC-03-EX to NYC-2001-EX. Keep both servers running to ensure that all users in New York are automatically redirected to the new Exchange 2000 server.

  3. Configure a new SNADS Connector on NYC-02-EX with parameters matching those of the existing connector on NYC-01-EX. Move the directory synchronization with Fisher TAO to the new connector. Set the cost factor of the original connector to 100 to exclude it from message routing. After one month, review the system state and decide whether it is safe to remove the SNADS connector from NYC-01-EX.
  4. As soon as the SNADS connector is removed from NYC-01-EX, directly upgrade this server to Exchange 2000 Server using the following steps:

    1. Upgrade the server on a weekend. The upgrade will take the server offline for a period of time, which affects the intersite message transfer.
    2. Back up NYC-01-EX, verify that the backup can be restored, and then temporarily set the replication schedule of the directory replication connector to the HUB site to Never to avoid the replication of possibly incorrect directory information to other bridgeheads. Also, shut down the SRS and Exchange Directory services on all other servers in the site of New York. This will not affect the users. Only the SNADS Connector will be out of order for the duration of the upgrade.
    3. Troubleshoot the upgrade procedures in a test lab using an exact duplicate of NYC-01-EX. After you have the complete upgrade procedure documented, upgrade NYC-01-EX and then examine the information in the SRS database on this server to ensure that the upgrade was accomplished properly. In the event of problems, restore the old server from the most recent backup, restart the Exchange Directories and SRS on all other servers, and check the accuracy of the replication schedule to the HUB site.
    4. If the upgrade was successful, adjust the SMTP Connector parameters to ensure reliable message transfer to the HUB site, to all other sites, and to the Internet.
    5. Restart the Exchange Directories and SRS on all other servers, and reconfigure the replication schedule to the HUB site. Verify that the directory replication propagates the new configuration of NYC-01-EX to all other servers in the site and the replication bridgehead in the HUB site.
    6. Perform a full backup of NYC-01-EX, being careful not to overwrite the pre-upgrade backup.

  5. After one month, shut down NYC-03-EX. Keep the server for another month, and then, if no problems are reported, obtain formal approval from the project team and project sponsor to decommission NYC-03-EX.
  6. Examine options for SMTP-based connectivity to Fisher TAO to replace the SNADS Connector on NYC-02-EX with a connector supported in Exchange 2000 Server. Do not decommission NYC-01-EX as long as SNADS-based connectivity to TAO is required.

Activity: Designing Upgrade Plans

In this activity, you will develop an upgrade strategy for Adventure Works’ global messaging organization.

Tip


You can use Figure B.19 in Appendix B as a guideline to accomplish this activity.

Scenario: Adventure Works

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:

  1. Adventure Works has upgraded VAC-02-EX and is now planning to consolidate the remaining mailbox resources on a single Exchange 2000 server. Which upgrade strategy should Adventure Works use?
  2. Adventure Works plans to keep the management of mailbox resources separated for each geographical location. How can you separate the mailbox resources for Canada and the United States if they are all on a single Exchange 2000 server?
  3. Adventure Works intends to use VAC-02-EX for the purposes of message traffic only. What do you need to accomplish to configure VAC-02-EX as a dedicated bridgehead server?
  4. Adventure Works uses a dual-processor system with 512 MB of RAM in the location of South Africa. Which upgrade method would you recommend for the server JHB-01-EX?
  5. Adventure Works uses a dual-processor system with 512 MB of RAM in the location of Australia. Which upgrade method would you recommend for the server MLB-01-EX?
  6. For security reasons, the server DMZ-01-SMTP is not part of the internal Exchange organization. Do you need to upgrade DMZ-01-SMTP to switch the Exchange organization into native mode?

    Figure 6.20 - The messaging environment of Adventure Works after the implementation of the first Exchange 2000 server

Lesson Summary

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.



MCSE Microsoft Exchange 2000 Server Design and Deployment Training Kit(c) Exam 70-225
MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)
ISBN: 0735612579
EAN: 2147483647
Year: 2001
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net