Software

Decision Support: Internal Exchange 2000 preparation

Prepare your Exchange 5.5 servers before upgrading to Exchange 2000.


Your Exchange 5.5 servers will require significant preparation before you upgrade them to Exchange 2000. To help you cover all the bases, our series on migration planning continues with a look at the following:
  • Loading service packs
  • Installing IIS
  • Mailbox preparation
  • Database consistency
  • Expansion servers
  • Running ForestPrep and DomainPrep
  • Installing and configuring the Active Directory Connector

This discussion assumes you’re running Exchange 5.5 on Windows 2000 servers in an Active Directory forest.

Carol Bailey's series on Exchange 2000 planning


Loading service packs
Make sure that all your Exchange 5.5 servers are running at least Service Pack 3 (SP4 is the latest). Strictly speaking, this service pack requirement is necessary only on those servers that will be upgraded to Exchange 2000 or that will be used with the Active Directory Connector. But it’s easier and safer to ensure the same service pack level across the network. Don’t forget that all Windows 2000 domain controllers should be running a minimum of SP1.

Installing IIS
Before installing or upgrading to Exchange 2000 on a server, make sure that the server has IIS installed with SMTP and NNTP (note that NNTP doesn’t install by default). Then, as with any server running IIS, patch it with any necessary security hot fixes and harden the server appropriately.

If your server has IIS installed with SMTP domains configured, these will be deleted when you install Exchange 2000, and you’ll have to manually recreate them, so be sure that they are well documented.

Mailbox preparation
Unlike Exchange 5.5, Exchange 2000 has a one-to-one relationship between user and mailbox. Because there isn’t a straight conversion between the Exchange 5.5 directory and Active Directory (which is used for Exchange 2000), you will need to do some work to ensure that if you are merging the two, all of the mailboxes are still accessible.

This means that you need to make sure that each user has only one mailbox associated with his or her username. Previous versions of Exchange allowed users to have more than one mailbox and allowed “resource mailboxes,” which were mailboxes without an associated user. This configuration is not supported with Exchange 2000 because mailboxes become a property of an Active Directory user account, and it’s not possible to have more than one mailbox per user. In Active Directory, you cannot have a property (mailbox) without the original object (user account).

If you don't have a direct one-to-one relationship between mailbox and user, and you leave it like this, Exchange 2000 will attempt a best effort to create a new suitable configuration. As a result, resource mailboxes without an associated user account will have a user account created but disabled. Users with more than one mailbox will have one mailbox associated with their account (based on the mailbox that most closely matches the username), and any additional mailboxes will be associated with new, disabled accounts.

If users have more than one mailbox associated with their account and cannot access their primary mailbox after the upgrade to Exchange 2000, it’s possible that the account has been associated with the wrong mailbox. You can rectify this by deleting the mailboxes in Active Users And Computers and then connecting the user to the right account with the Exchange System Administrator, but it’s best to prevent this from happening in the first place.

For proactive rather than reactive measures, either go through all of the mailboxes manually and configure a one-to-one relationship of usernames and mailboxes or have the NTDSNoMATCH utility identify resource mailboxes in advance by using the mailbox’s custom attribute 10. This utility with documentation can be found in the latest Exchange 2000 service pack (SP2) under \Support\Utils\i386\Ntdsatrb.

Once you have created your one-to-one relationships, you’ll need to keep the same functionality as before. You can enable the new user account with what used to be the resource mailbox and log on as that user to view or forward e-mails. But the recommended way is to give the original user Full Mailbox Access permission on the user account. Use the Advanced view with Active Directory Users And Computers and the Mailbox Rights button in the Exchange Advanced tab of the user Properties. The user can then access this mailbox from his or her own e-mail client.

You can also use the Active Directory Cleanup Wizard (which installs with Exchange 2000) to help identify and merge multiple mail accounts in Active Directory that refer to the same user, which is particularly useful if you are migrating users across multiple domains.

Database consistency
It’s a good idea to run the Exchange 5.5 DS/IS Consistency Adjustment on the databases (public folders and mailbox stores) to remove any “zombie” Access Control Entries. This refers to a user who has deleted mailboxes. These zombie accounts can prevent access after upgrading to Exchange 2000, although this was fixed in Exchange 2000 SP1. Make sure that you tidy this up before migrating the database.

You’ll find the Consistency Adjuster in the Exchange 5.5 administrator utility under File | Properties | Advanced tab. Click on Consistency Adjuster and then click Remove Unknown User Accounts From Public Folder Permissions and Remove Unknown User Accounts From Mailbox Permissions. Clear all other check boxes and then select All Inconsistencies.

Invalid characters
Check for characters in your Exchange 5.5 organization name or site names that will be invalid in Exchange 2000. Valid characters are alpha/numeric and a hyphen. Common examples of invalid characters are the period (.) and underscore. The names also cannot exceed 64 characters. If you have any invalid characters, you will not be able to successfully extend the schema for Exchange 2000 (installing Exchange with the ForestPrep switch). If you find invalid characters, change the display name with the Exchange 5.5 Administrator.

Expansion servers
Make sure that all distribution lists are configured for Any Server In Site before an in-place upgrade. Expansion servers contact Global Catalog servers to retrieve membership information, and then the Global Catalog server looks up the users’ home servers, so good connectivity to Global Catalog servers is necessary.

Running ForestPrep and DomainPrep
The Active Directory schema needs extending to accommodate Exchange 2000, and to do this, you’ll need to run the Exchange 2000 Setup with the /ForestPrep switch:
F:\Setup\i386\SETUP.EXE /ForestPrep

The account you use must have membership in the Schema Admin and Enterprise Admin groups. You’ll also need access to the Exchange 5.5 Service account and password, plus local Administrator rights on the server where you’re running the command. To upgrade your existing Exchange 5.5 Organization, select Join An Existing Exchange 5.5 Organization and follow the prompts. Note that you’ll need to enter the 25-digit Product Identification number at this point, so make sure that you have it handy.

As part of running ForestPrep, you’ll be prompted to supply the Exchange 2000 Administrator Account, which will be the user who will install Exchange 2000 later. This user will be granted Full Exchange Administrator rights and will be able to delegate Exchange permissions throughout the forest to other administrators.

Because ForestPrep modifies the schema as well as the configuration partition of Active Directory, it’s recommended that you run it on a Windows 2000 domain controller that is also a Global Catalog server and at a time when the network has a lull in activity. Be prepared for replication latency if you have multiple domains. You should run it when you have time on your side—for example, last thing on a Friday.

Once ForestPrep has run successfully, you’ll need to run the DomainPrep command (the Exchange 2000 setup command with the \DomainPrep switch) in all your domains to modify the Active Directory domain partition. You need to do this even in the domains that don’t have Exchange servers. The account you run this command with should be a member of that domain’s Domain Admins group and should have local administrator rights on the machine.

This installation switch creates two additional groups (a domain local group called Exchange Enterprise Servers and a global group called Exchange Domain Servers), plus a user account called Euser_exstoreevent (for the script host event).

For more information on ForestPrep and DomainPrep, see the relevant sections on these in Microsoft's Knowledge Base article "XADM: How to Set Up Exchange 2000".

Install ADC
To merge your Exchange 5.5 and Active Directory databases, you’ll need to install the Exchange 2000 Active Directory Connector (ADC). You install this from the latest Exchange service pack. Once installed, configure it with Connection Agreements (CAs). CAs are responsible for replicating recipient and folder configuration information between Exchange 5.5 and Active Directory.

When it comes to replicating users between the two databases, you can have either one-way replication, which will be sufficient if you’re simply upgrading one server from Exchange 5.5 to Exchange 2000, or two-way, which you'll need if you're going to continue to run Exchange 5.5 servers. For more information on how to configure the ADC, see the Knowledge Base article "XADM: Understanding Connection Agreements in Exchange 2000 Server".

If you’re running Exchange 5.5 on a Windows 2000 domain controller, remember to check with the Exchange 5.5 Administrator to see which alternative port number you’re using for LDAP (it won’t be the default of 389) because you’ll also need to specify this number in the Active Directory Connector.

Summary
That takes care of the tasks needed to prepare your existing Exchange 5.5 servers for an upgrade to Exchange 2000. The next article in this series will look at Exchange server placement and roles, including planning for connectors, routing groups, and deploying front-end servers. We'll also look at whether to use Outlook Web Access and clustering, and which additional ports you may need to open on intervening routers and firewalls.

 

Editor's Picks