10 Tips for a Painless Exchange 2000 Migration

Given that Microsoft will no longer support Exchange Server 5.5 starting January 1, 2004, many Exchange 5.5 administrators are planning to upgrade to Exchange 2000 Server or Exchange Server 2003 in the near future. Exchange 2000 migrations are often problematic because administrators make one or more of the following mistakes:

Here are 10 tips to help migrate from Exchange 5.5 to Exchange 2000. These tips focus on Exchange 2000 but apply to Exchange 2003 as well.

Tip 1: Learn About the Migration Process
Knowing what to expect during the migration process can ease the burden of moving to Exchange 2000. Over the past few years, Exchange & Outlook Administrator has featured some great articles about Exchange 2000 migrations. The Web-exclusive box "Related Articles About Migration Planning" (http://www.exchangeadmin.com, InstantDoc ID 38522) lists some of those articles. Before you begin planning your migration, you should read these articles in the order that I have them listed. They can help you find your way through the onerous migration process.

The Microsoft TechNet Web site also features articles as well as job aids and tools to help with migration planning. Go to http://www.microsoft.com/technet, and navigate to Products & Technologies, Exchange Server, Exchange 2000 Server, Deploy, Upgrade/Migrate.

Tip 2: Make Several Decisions at the Outset
One of the first decisions you need to make is which migration method is best for your organization. Your decision will be influenced by whether you have new hardware for Exchange 2000 and whether you want to change your existing organization structure. The Microsoft article "XADM: Description of Exchange Server Migration Methods" (http://support.microsoft.com/?kbid=327928) is the best source of information about migration methods. If you have new hardware, the Move Mailbox method provides the smoothest, most flexible, and safest migration path. However this migration method takes longer than the others because it moves each mailbox to a new Exchange 2000 server.

Depending on the migration method you choose, you also need to choose the right tools for the job. The Microsoft article "XGEN: Exchange Tools for Migration" (http://support.microsoft.com/?kbid=281584) is a great starting point for finding and learning about the tools that Microsoft makes available to you. If these tools don't provide you the flexibility or features you need during your migration, third-party tools are available, such as NetIQ's Exchange Migrator (which is part of the Migration Suite), Aelita Software's Exchange Migration Wizard, and AutoProf's Profile Maker.

Tip 3: Get Training
To administer an Exchange 5.5 system, you don't need to know about Windows NT. With Exchange 2000, you must have at least some knowledge of Win2K and AD because all the Exchange 2000 configuration information and all Exchange user attributes are in AD. And if AD isn't already in place, migrating to Exchange 2000 means installing AD. Thus, if you aren't knowledgeable about AD, you need AD training so that you understand how the Exchange servers, AD domain controllers (DCs), and Global Catalog (GC) servers interact with one another.

You also need to know how to use several utilities: the ADC, ADSI Edit, and LDP. You should treat these utilities with the same respect you treat electric power tools because like power tools, these utilities are powerful and useful but dangerous if used incorrectly. The ADC is one of the most important tools because it synchronizes information between Exchange 5.5 and AD. You can find this tool on the Exchange 2000 Service Pack 3 (SP3) CD-ROM. A good starting point for learning about the ADC is reading the adcadmin.chm Help file that's installed with the ADC. ADSI Edit and LDP are Win2K Support Tools, which you can find on the Win2K Server CD-ROM. ADSI Edit lets you view AD in raw mode, whereas LDP lets you query and browse Lightweight Directory Access Protocol (LDAP)­compliant directories. You can find more information about ADSI Edit in the w2rksupp.chm Help file. For information about LDP, see the Microsoft article "XADM: Browsing and Querying Using the LDP Utility" (http://support.microsoft.com/?kbid=255602).

If you aren't knowledgeable about Exchange 2000, you should get Exchange training. Being a Microsoft Certified Trainer (MCT), naturally I'm fond of the Microsoft Official Curriculum (MOC) courseware, but any Exchange training is better than none. I recommend Course 1572: Implementing and Managing Microsoft Exchange 2000 (5 days) for all future Exchange 2000 administrators. If you're migrating from Exchange 5.5, I also recommend Course 2355: Upgrading from Microsoft Exchange Server 5.5 to Microsoft Exchange 2000 (2 days), which covers essential skills required to configure and use the ADC. If you're the systems architect for an Exchange 2000 organization with more than 1000 to 2000 mailboxes, I suggest Course 1573: Designing Microsoft Exchange 2000 for the Enterprise (4 days).

Tip 4: Don't Rush the AD Deployment
Don't rush your AD deployment because you're trying to deploy Exchange 2000. If you don't have your AD infrastructure (i.e., DCs and GC servers) in place or you haven't migrated all your users from NT 4.0 domains, you're opening up your Exchange 2000 system to potential problems. For example, if the AD infrastructure isn't ready, you might send too many LDAP queries from Exchange servers to DCs or GC servers. If you have users on NT 4.0 and AD, you might end up with duplicate AD accounts. At the least, make sure that you have a sufficient number of DCs and GC servers deployed and that your AD replication architecture is working well. If possible, try to have all the domains in native mode so that you don't need to deal with any accounts in NT 4.0 domains.

Tip 5: Change Names Before the Migration
If you're unhappy with your current Exchange organization's or sites' names, you're in luck. During an Exchange 2000 migration, you can change these names. However, you must change them at the right point in the migration: before you run the ADC and Exchange 2000's Forestprep utility. Because the ADC uses display names and not directory names, you change the Display name value in the site's or organization's Properties dialog box by right-clicking the site or organization name in Microsoft Exchange Administrator.

Tip 6: Eliminate Duplicate NT Accounts
Exchange 2000 stores mailbox information in user-account attributes in AD, whereas Exchange 5.5 stores mailbox information in mailbox attributes in its own directory. In Exchange 5.5, one of the mailbox attributes is the Primary Windows NT Account Name. Before beginning a migration, you must make sure that you have a one-to-one mapping between mailboxes and user accounts because Exchange 5.5 organizations sometimes have several resource or shared mailboxes that use the same NT account. In addition, resource and shared mailboxes might have no NT account listed.

Exchange 2000 SP3 contains a utility called NTDSAtrb (formerly known as NTDSNoMatch) in the supportutilsi386tdsatrb directory. NTDSAtrb uses LDAP to scan the Exchange 5.5 directory and create a file called ntdsnomatch.csv. This file lists all the mailboxes that have duplicate NT accounts. When NTDSAtrb finds a duplicate account, it marks the Extension-Attribute-10 attribute with the string NTDSNoMatch.

You can use ntdsnomatch.csv to import data directly into the Exchange 5.5 directory. The ADC looks for this string in the Extension-Attribute-10 attribute and creates a user account for each duplicate NT account. However, I recommend that you eliminate duplicate NT accounts before using the ADC, just to be safe. For each mailbox with a duplicate NT account, create a unique user account in the domain. When you change the NT account, you must also assign that user permission to the mailbox on the Permissions property page in Exchange Administrator.

NTDSAtrb doesn't include in the .csv file those mailboxes that don't list an NT account. To locate these mailboxes, you can use Exchange Administrator to export the directory to a .csv file, open the file in Microsoft Excel, then sort the column that contains the NT accounts. For more information about the NTDSAtrb utility, see the Microsoft article "XADM: Documentation for the NTDSNoMatch Utility" (http://support.microsoft.com/?kbid=274173).

Some organizations might have associated mailboxes with a group. You must also locate and fix these mailboxes. You can use the .csv file­and­Excel method to determine which groups have been associated with a mailbox.

Tip 7: Configure and Test the ADC
I highly recommend that you build a lab and test various configurations in which you might want to use the ADC. Because you can use AD attributes in a variety of applications, the ADC can produce unexpected results. For example, when the ADC matches an AD user account with an Exchange 5.5 mailbox, the ADC automatically replaces the common name (CN) in AD with the display name in Exchange 5.5. If you have an application that uses AD's common name, the application will no longer work.

Fortunately, you can configure the ADC to work around this problem. Use ADSI Edit to change the default value of the ADC's connection agreement (CA) so that the ADC doesn't make this replacement. The Microsoft article "XADM: ADC Overwrites Display Name with Exchange Server 5.5 Display Name" (http://support.microsoft.com/?kbid=269843) details the steps for changing the default value.

I recently encountered a similar problem in a company in which someone had developed an Active Directory Service Interfaces (ADSI)­based application that used AD's employeeID attribute. ADC mapped AD's employeeID attribute to Exchange 5.5's employeeID attribute. When the Exchange administrator ran the first recipient CA, the initial direction of replication was from Exchange 5.5 to AD. Because these attributes were empty in Exchange 5.5, the ADC cleared the employeeID attribute in AD, and the ADSI-based application no longer worked.

How can you avoid this type of migration problem? Using the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and Exchange Administrator to search for similar attributes doesn't work well because these tools don't show every attribute. For example, the employeeID attribute isn't visible in the Active Directory Users and Computers snap-in or Exchange Administrator. Instead, check with fellow administrators and users to make sure no AD-enabled applications are using data in AD. If such applications exist, try to ascertain which attributes the applications are using. You can then block these attributes from replicating from Exchange 5.5 to AD by right-clicking the Active Directory Connector Services object at the top of the ADC MMC hierarchy and selecting Properties. In the Active Directory Connector Management Properties dialog box, click the From Exchange tab. You should see a dialog box similar to the one that Figure 1 shows. Locate the attributes you don't want to replicate, and clear those check boxes. After you've made the changes, you need to test the ADC in a lab environment.

Tip 8: Deal with the DLs
Exchange 5.5 distribution lists (DLs) can cause problems in migrations. When you configure the ADC to replicate Exchange 5.5 DLs to AD, the ADC creates Universal Distribution Groups (UDGs) in AD. UDGs work fine as long as you use these groups only to send email messages. However, problems can arise if you also use these groups to assign Exchange users permissions to public folders and Windows network resources (e.g., printers, shared folders, NTFS files and folders).

If the AD domain is in native mode, Exchange 2000 automatically converts UDGs to Universal Security Groups (USGs) if a copy of the public folder content is replicated to an Exchange 2000 public folder store. If the domain isn't in native mode, the groups remain UDGs and public folder permissions granted to these groups won't work.

To work around this problem, you can segment the groups into two sets, much the same way you do in Exchange 5.5. Assuming that the AD domain is in native mode, you can mail-enable one set of USGs and use this set for email distribution and public folder permissions. You can then use the other set of USGs, which aren't mail-enabled, for resource permissions. Although this approach works, it often doubles Exchange administrators' workload because any changes to group memberships typically need to be made to the USGs in both sets.

In a native-mode AD domain, you can use one set of USGs for email distribution, public folder permissions, and Windows resource permissions. However, Exchange administrators often forget that the USGs are used for multiple purposes, which might lead to security problems. For example, suppose that a marketing department member wants to get all the email messages sent to the sales department, so an administrator makes that person a member of the mail-enabled USG called Entire Sales Department. Now, the marketing member will not only receive the Sales department email messages but also have all the permissions to Windows resources to which the Entire Sales Department USG is assigned.

If you want to use a single set of USGs and you want to consolidate groups when you migrate the DLs, you need to take special precautions. I recommend that you consolidate the UDGs after the migration. After Exchange 2000 converts the consolidated UDGs into USGs, confirm that the consolidated USGs have the same memberships as the unconsolidated UDGs. You can then mail-enable the USGs and assign those USGs the necessary permissions to public folders and resources. Finally, delete the unconsolidated UDGs. For more information about migrating DLs, see the following Microsoft articles:

Note that for organizations with more than one domain, you should choose the group types with care. In a multidomain Win2K AD forest, mail addressed to a mail-enabled global group might not be delivered. However, if you make all your groups USGs, you'll increase the replication load to the GC servers. For more information about this problem, see the Microsoft article "XADM: Message Delivery to Global Groups Does Not Work" (http://support.microsoft.com/?kbid=271930).

Tip 9: Check Connector and Gateway Compatibility
Exchange 2000 provides connectivity to SMTP, Microsoft Mail (MS Mail), Lotus cc:Mail, and Lotus Notes. If you're providing email connectivity through another type of connector or gateway (e.g., IBM PROFS, IBM OfficeVision, Wang OFFICE/Microsoft Exchange Gateway), check with the vendor to make sure that the version you're running is ready to operate on an Exchange 2000 server or whether you need an update or new version. If an update or new version isn't available, you'll have to continue to operate at least one Exchange 5.5 server in your organization.

Tip 10: Check Antivirus and Backup Software Compatibility
Backup and antivirus software designed to work with Exchange 5.5 probably won't function with Exchange 2000 without modification. You should check with the backup or antivirus software vendor to determine the update or new version you need.

Let's Be Careful Out There
Migrating to Exchange 2000 isn't rocket science, and it doesn't need to be a painful process. If you take the time to understand the migration process thoroughly, get some training, determine the best migration method and tools for your organization, avoid the known pitfalls, and make sure that you have the hardware and software necessary for the migration, your migration will be successful and painless.