Migrating Special Mailboxes to Exchange 2000

Prevent mismatched accounts

Resource mailboxes—mailboxes for objects rather than people—can be challenging to migrate from Exchange Server 5.5 to Exchange 2000 Server. Other Exchange 5.5 mailbox configurations can pose problems for migration, too. The problems result from differences between the Exchange 2000/Windows 2000 environment and the Exchange 5.5/Windows NT 4.0 environment.

Specifically, the relationship between an Exchange 2000 mailbox and a Win2K account differs radically from the relationship between an Exchange 5.5 mailbox and an NT 4.0 account. In the Exchange 5.5 model, the NT 4.0 account is a property of the mailbox. Thus, you can associate multiple Exchange 5.5 mailboxes with one NT 4.0 account. In Exchange 2000, the relationship is reversed: The Exchange 2000 mailbox is a property of the Win2K account. The architecture of Win2K and Exchange 2000 prevents you from associating more than one Exchange 2000 mailbox with one Win2K account.

Under most circumstances, the one-to-one (1:1) relationship between the Exchange 2000 mailbox and the Win2K account works well. Exchange 5.5 mailboxes typically have only one NT 4.0 account associated with them, so migrating them to Exchange 2000 is easy. However, problems can arise if the Exchange 5.5 Directory Service (DS) contains mailboxes that

When you use the Active Directory Connector (ADC) to synchronize the Exchange 5.5 mailboxes into Active Directory (AD), these three mailbox configurations can wreak havoc. (The ADC provides object-based bidirectional synchronization between the Exchange 5.5 DS and AD. If you're unfamiliar with the ADC, see "Real-Life ADC Deployment, Part 1" and "Real-Life ADC Deployment, Part 2," Windows & .NET Magazine, InstantDoc ID 20395 and InstantDoc ID 20722, respectively, http://www.winnetmag.com.) Let's take a look at the various problems and how to avoid them.

Multiple Mailboxes Referencing the Same Account
Let's say that you create an Exchange 5.5 mailbox in the Exchange 5.5/NT 4.0 environment and associate it with one NT 4.0 account. By default, the Exchange 5.5 mailbox has an alias that consists of the mailbox owner's complete first name and the first letter of the last name, as Figure 1, page 2, shows. Depending on whether you keep the Exchange 5.5 and NT 4.0 accounts in sync, the alias might correspond to the SAM account name of the associated primary NT 4.0 account. Typically, the SAM account name corresponds if you let Microsoft Exchange Administrator create the NT 4.0 account. However, if you create the NT 4.0 account separately, your naming conventions might vary and the values for the attributes might differ.

Occasionally, two or more Exchange 5.5 mailboxes share the same primary NT 4.0 account. For example, administrators often create a resource mailbox for an overhead projector or a conference room so that people can reserve the projector or conference room by scheduling it as an attendee of a meeting. Rather than create a separate NT 4.0 account to associate with that resource mailbox, administrators typically use an existing NT 4.0 account, such as an assistant's account. Figure 2 shows an example of a resource mailbox that uses the same primary NT 4.0 account (i.e., RESEARCHRhoton) as the mailbox in Figure 1.

When the ADC tries to synchronize Exchange 5.5 mailboxes that share an NT 4.0 account, problems arise. The ADC creates two mailbox-enabled objects to represent the Exchange 5.5 mailboxes, but the ADC has only one NT 4.0 account with which to uniquely identify them. For example, suppose the ADC tries to synchronize the John Rhoton and Overhead Projector mailboxes in Figure 1 and Figure 2, respectively, into a new Win2K domain. Let's assume that the ADC processes the John Rhoton mailbox first. (The ADC processes objects for synchronization alphabetically first by container name, then by the name of individual objects in the container. This processing order determines whether a resource mailbox or a real mailbox is processed first.) Following the default mapping rules, the ADC creates a Win2K user object in AD and assigns the object a distinguished name (DN) based on the mailbox's display name. Although this user object represents the John Rhoton mailbox, the ADC provides a pointer back to the NT 4.0 account associated with the mailbox. As Figure 3 shows, the ADC provides this pointer by writing the NT 4.0 account's SID in the user object's msExchMasterAccountSID attribute.

Next, the ADC attempts to synchronize the Overhead Projector mailbox into AD. The ADC creates a Win2K user object and assigns a DN that reflects that mailbox's display name. This part of the process doesn't cause problems because the user objects for the John Rhoton and Overhead Projector mailboxes have unique DNs and SIDs. (Both user objects are new, so both have unique SIDs.) However, problems arise when the ADC writes the NT 4.0 account's SID in the user object's ms- ExchMasterAccountSID attribute. As Figure 4 shows, two user objects now link to the same mailbox. When you later use a migration tool to migrate the NT 4.0 accounts into Win2K, the migration tool has a good chance of matching the user account for John Rhoton with the Overhead Projector mailbox rather than the John Rhoton mailbox.

A similar problem can arise if you've already migrated the NT 4.0 accounts into Win2K before running the ADC. If you used cloning to migrate the accounts, the Win2K user object's sID History attribute contains the NT 4.0 account's SID. If you performed an in-place upgrade, the Win2K user object's objectSID attribute contains the NT 4.0 account's SID. When you use the ADC to synchronize the Exchange 5.5 mailboxes into AD, the ADC will match the Exchange 5.5 mailbox's associated NT account with the Win2K user object's sIDHistory or objectSID attribute. This matching process works well as long as no resource mailboxes exist. However, if they exist, the ADC might match a resource mailbox with a user account. In that case, the wrong mailbox information gets associated with that account and the native Exchange 2000 users can't send mail to the user's Exchange 5.5 mailbox.

No matter whether you've migrated the NT 4.0 accounts previously, if the ADC synchronizes the correct user mailbox with user account, you're still left with a problem: The ADC can't match or create a Win2K user object to represent the resource mailbox. The ADC can't match the resource mailbox with the existing user account because that account has already been matched. So, the ADC attempts to create another user object, which generates an error because in AD, all references to SIDs must be unique. Figure 5 shows a sample error message that appears in the Windows event log. The lack of an AD object for the resource mailbox means that native Exchange 2000 users can't access it when scheduling a meeting.

Mailboxes with Associated NT 4.0 Groups
In Exchange 2000, you can associate only a Win2K user account with a mailbox. In Exchange 5.5, you can associate an NT 4.0 group account instead of an NT 4.0 user account with a mailbox. For example, an Exchange 5.5 mailbox named Tennis Players might have an associated NT 4.0 group named Tennis Players.

When using the ADC to synchronize an Exchange 5.5 mailbox with an associated NT 4.0 group, you might experience problems. The ADC creates a Win2K user account whose name is derived from the Exchange 5.5 mailbox's display name. For example, for the Tennis Players mailbox, the ADC creates a Win2K user account named Tennis Players. When the ADC synchronizes this mailbox into AD, it creates a Win2K user object (not a group object) that also has the name Tennis Players and writes the NT 4.0 group's SID as the value of the msExch-MasterAccountSID attribute. Thus, the group-sharing aspect of the Exchange 5.5 mailbox isn't represented in Exchange 2000.

If you've already migrated the NT 4.0 accounts into Win2K, another problem might occur. The NT 4.0 group might already be migrated to a security group in the Win2K forest. In this case, the security-group object's sIDHistory attribute (cloned) or objectSID attribute (upgraded) contains the NT 4.0 group's SID. When you run the ADC, it attempts to create a user object and write the NT 4.0 group's SID to the user object's msExchMasterAccount-SID attribute. However, because the security-group object has already been assigned this SID, the attempt fails.

Mailboxes with No Associated NT 4.0 Accounts
Sometimes, an Exchange 5.5 mailbox doesn't have an NT 4.0 account associated with it. For example, you might have such a mailbox for email redirection or address translation. When the ADC synchronizes such mailboxes, it creates a Win2K user account. The ADC derives the user account's name from the Exchange 5.5 mailbox display name. However, the ADC can't set the msExchMasterAccountSID attribute to the NT 4.0 account's SID because no such account exists. Thus, the ADC sets the attribute to a self SID. A self SID isn't a real SID but rather a hexadecimal value that's common to all Win2K objects that don't have an associated NT 4.0 account. Migration tools have problems matching mailboxes with user accounts that have self SIDs.

Identifying Problem Mailboxes
As you can see, having Exchange 5.5 mailboxes that reference the same account, a group account, or no account can cause problems when you use the ADC. To prevent these problems, you need to audit the Exchange 5.5 DS so that you identify the problematic mailboxes. You can use several tools to perform this audit. Although you can purchase third-party tools for this purpose, you can use the Ntdsatrb tool (formerly the NTDS-NoMatch utility), which is on the Exchange 2000 Service Pack 1 (SP1) CD-ROM and from the Microsoft Exchange 2000 Internals Web site (http://www.exinternals.com). You can also inspect the mailboxes manually.

Using Ntdsatrb. To install Ntdsatrb, open ntdsatrb.zip and double-click setup.exe. Ntdsatrb automatically installs in the program filestdsatrb directory on the system drive. You use a command window to run Ntdsatrb. When you run the utility, you must supply a server name as an argument. Optionally, you can supply the Lightweight Directory Access Protocol (LDAP) port number if you're running a nonstandard LDAP configuration on a port other than 389. Ntdsatrb uses LDAP to connect to an Exchange 5.5 server in your organization, then uses an algorithm to process all the Exchange 5.5 mailboxes in each site.

The utility begins by comparing an Exchange 5.5 mailbox's alias and primary NT 4.0 account. If they're identical, Ntdsatrb assumes that the mailbox is the primary mailbox that you want to associate with the account and proceeds to the next mailbox. If the alias and primary NT 4.0 account differ, Ntdsatrb assumes that the mailbox is problematic and writes an entry in a Comma Separated Value (.csv) file in the working directory. One .csv file exists for each Exchange 5.5 site in an Exchange organization.

Figure 6 shows a sample .csv file. The first line identifies the attribute names. The subsequent lines identify the problematic mailboxes. You can later use Ntdsatrb with this input file to modify the problematic mailboxes' Custom Attribute 10 attribute (i.e., Extension-Attribute-10 in the .csv file). Ntdsatrb sets this attribute's value to NTDSNoMatch. The ADC doesn't synchronize any mailboxes that have this attribute set to this value.

As Figure 6 shows, Ntdsatrb has determined that the John Rhoton and Overhead Projector mailboxes shouldn't be synchronized. This determination might seem counterintuitive—surely, the John Rhoton mailbox shouldn't be excluded from the synchronization. Herein lies Ntdsatrb's major weakness. It assumes that if the mailbox alias and the associated NT account name differ, the mailbox isn't the primary mailbox for the account. In some organizations, this assumption holds true; in other organizations, this assumption is incorrect. As I described earlier, if you create the NT 4.0 accounts separately rather than let Exchange Administrator create them, your naming conventions might vary, thereby causing the mailbox's alias and the associated NT account's name to differ. In this situation, Ntdsatrb produces erroneous results. So, before you use Ntdsatrb, you need to make sure that the mailbox aliases and Windows account names align. In addition, before Ntdsatrb uses the .csv files to modify the Custom Attribute 10 attribute, you need to carefully review the files and remove any mailboxes that need to be synchronized. You can find more information about how to use Ntdsatrb in the Microsoft article "XADM: Documentation for the NTDSNoMatch Utility" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q274173).

Inspecting mailboxes manually. In organizations with a small number of users, you can use Exchange Administrator to manually inspect mailboxes and identify those mailboxes that are problematic. To modify the problematic mailboxes, you can set the Custom Attribute 10 attribute to NTDSNo-Match or modify another attribute. (For information about other attributes that you can modify, see "ADC Filtering and Object-Matching," January 2001, InstantDoc ID 16139.)

In organizations with many users, manually inspecting the mailboxes with Exchange Administrator would be too time-consuming and inefficient. To automate the process, you can export the contents of the Exchange 5.5 DS to a .csv file, then inspect the results. To export the mailbox metadata, you use the command

exchsrvrbinadmin.exe     /e mbxs.csv /o options.opt

Although this command appears in two lines here, you need to type it on one continuous line in the command-shell window. This command instructs Exchange Administrator to run in export mode (/e) and write the mailbox metadata to a file named mbxs.csv. You need to create the .csv file before you perform this export operation. On the first line, you must specify the attributes of the directory objects you want to export. In this case, you need to specify

Obj-Class,Primary Windows NT     Account,Display Name,Alias

on the first line of the .csv file. The /o switch specifies the name of the file that holds optional settings for the export operation. For example, the contents of the options file might look like

[Export]DirectoryService=GLUONExportObject=Mailbox

where DirectoryService specifies the name of the Exchange 5.5 server to which you want to connect and ExportObject specifies the type of objects that you want to export.

After you run the command, you can open the .csv export file in Microsoft Excel and use column-sorting techniques to identify problematic mailboxes. Another option is to write a script or create a macro to process the metadata.

An Important Task
Understanding how Exchange 5.5 mailboxes use NT 4.0 accounts and cleaning up your Exchange 5.5 DS are crucial to a successful migration to Win2K and Exchange 2000. Failure to perform this cleanup task will result in an incomplete AD or an AD that contains incorrect information. As the Microsoft article "XADM: How to Correct Mismatched Accounts After Active Directory Connector Replication" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q256862) shows, preventing these problems is much easier than correcting them.