Migrating from Legacy Exchange

This chapter is from the book

Learning Exchange Server 2003

Learn More Buy

This chapter is from the book

This chapter is from the book 

Learning Exchange Server 2003

Learn More Buy

Active Directory Connector Operation

One of the challenges in making the transition to Exchange 2003 consists of extracting all the operational parameters for e-mail recipients, distribution lists, custom recipients, public folders, address lists, and message routing parameters from the existing legacy Exchange directory service and putting that information into Active Directory. You as the administrator can move mailboxes and connectors off the old Exchange 5.x servers and onto sleek, new Exchange 2003 servers with minimal service disruption.

The tool Microsoft supplies to perform this operation is called the Active Directory Connector, or ADC. As illustrated in Figure 12.1, the ADC locates objects of interest in both directory services—legacy Exchange and Active Directory—and copies attributes for those objects back and forth to keep the objects in sync. An exception would be a one-way Connection agreement, used in specialized circumstances.

• Legacy mailbox owners replicate to Active Directory as mailbox-enabled user objects.

• Legacy distribution lists become mail-enabled Universal Distribution Groups, which get promoted to Universal Security Groups if used to control access to public folders or user mailboxes.

• Legacy custom recipients become mail-enabled contacts.

Figure 12.1 Diagram of object replication to and from the legacy Exchange directory service and Active Directory.migration from legacy ExchangeADCone-way Connection agreementsADC (Active Directory Connector)migration from legacy Exchangeone-way Connection agreements

With the ADC working in the background, you can manage legacy Exchange objects from the Active Directory Users and Computers console. Once all mailboxes, public folders, and connectors have been moved, you can decommission the legacy servers and remove the ADC from service.

Connection Agreements

The ADC stores configuration parameters in Active Directory objects called Connection Agreements (CAs). A CA defines object types for the ADC to copy, the source and target containers for the objects, a replication schedule, credentials to use for making inter-server replication connections, and the name of an Exchange server to act as an endpoint on the legacy side of the CA.

The ADC uses LDAP to query and update servers on both sides of a CA, so the legacy Exchange server must run Exchange 5.5 SP3 or higher to support LDAP writes and paged results.

The ADC uses three types of CAs:

• Recipient. This CA maps the attributes of User, Group, and Contact objects in Active Directory with Recipient, Distribution List, and Custom Recipient objects in the legacy Exchange directory service.

• Public Folder. This CA maps legacy public folders with Public Folder objects in Active Directory to permit Exchange 2003 to accept e-mail on behalf of the public folders.

• Configuration. This CA maps some of the objects in the legacy Configuration container with objects in the Exchange 2003 Organization container in Active Directory. You cannot create this CA manually. Exchange Setup configures the CA as part of installing the first server in each legacy site.

Because each site forms a separate naming context in the legacy Exchange directory service, you must create a separate User and Public Folder CA for each site. The Connection Agreement Wizard in Exchange 2003 automates this process. You can use the same ADC for multiple sites. Consider installing multiple ADCs if you have large geographical separations or so many sites that you would overload a single ADC server.

ADC Mailbox Mapping

To build a mental picture of the way the ADC operates, it helps to understand the function of certain critical attributes that tell the ADC how to select objects and which e-mail parameters to copy between the objects.

Let's assume that you do an in-place upgrade of an NT4 domain to Active Directory. This transfers user account information from the PDC's SAM into Active Directory, including the users' original SIDs and passwords. As shown in Figure 12.2, a user's SID provides the initial link between the user's domain account and the user's legacy Exchange mailbox. Legacy Exchange stores this SID in the Primary Windows NT Account attribute. Active Directory stores the SID in an attribute called ObjectSID.

Figure 12.2 Initial linkage of user object in Active Directory to legacy mailbox via user SID.SIDs (Security IDs)ADC mailbox mappingmigration from legacy ExchangeADCmailbox mappingADC (Active Directory Connector)migration from legacy Exchangemailbox mappingmailboxesADC mapping

Initial ADC Attribute Copy

When you configure a Recipient Connection Agreement, the ADC makes an LDAP connection between the two directory services and, for each recipient object in the legacy Exchange directory service, it reads the Primary Windows NT Account attribute and then searches for a user object in Active Directory with a matching ObjectSID attribute.

Once the ADC makes this match, it copies the e-mail attributes from legacy Exchange to the Active Directory object. Figure 12.3 shows a few of the copied attributes. An ADC Policy object in Active Directory determines which attributes to copy and maps the legacy Exchange attribute names to their Active Directory equivalents.

Figure 12.3 Following initial ADC replication, e-mail attributes copied to Active Directory object and ADC-Global-Names created.legacy Exchange serversmigration to Exchange 2003ADC operations

ADC-Global-Names Attribute Creation

In addition to copying attributes from legacy Exchange, the ADC assigns a new attribute called ADC-Global-Names to the Active Directory object. This permits the ADC to store detailed matching information that simplifies subsequent searches and reduces the LDAP traffic required to perform object mapping. The initial content of the ADC-Global-Names attribute includes two elements:

• EX5. This element contains the Distinguished Name and object class of the legacy Exchange object along with a timestamp of the last update and a set of flags that control the update methods used by the ADC.

• Forest. This element contains the Distinguished Name of the Active Directory forest along with an update timestamp and some flags.

The next time the Connection Agreement runs, the ADC looks for User objects that have an ADC-Global-Names attribute, uses the EX5 element to locate the complementary object in legacy Exchange, and then replicates any updated e-mail attributes to the legacy object. This transaction also replicates the ADC-Global-Names attribute.

After this replication, as shown in Figure 12.4, the ADC then adds two elements to the legacy Exchange copy of ADC-Global-Names:

• NT5. This element contains the Globally Unique Identifier (GUID) of the legacy Exchange organization along with an update timestamp and some flags.

• FOREST. This element contains the GUID of the Configuration container in Active Directory along with an update timestamp and some flags.

Figure 12.4 Following replication back to legacy Exchange, the ADC-Global-Names provides all mapping information needed to keep objects in sync.legacy Exchange serversmigration to Exchange 2003ADC operations

The next time the Connection Agreement runs, these new elements replicate from legacy Exchange to Active Directory. At this point, the ADC can match users to mailbox owners based solely on their ADC-Global-Names attributes and no longer needs their SIDs.

NT Account Migrations

Not all transitions from NT to Active Directory involve an in-place upgrade of the PDC, though. Many organizations create a pristine Active Directory domain and then use a utility such as the Active Directory Migration Tool (ADMT), or a third-party migration utility, to move user, group, and computer account information into the Active Directory domain.

Unlike an in-place upgrade, which retains the users' original domain SIDs, a migration creates new user accounts with new SIDs. It also saves the original NT domain SIDs into a special Active Directory attribute called SIDHistory.

When a user authenticates in the Active Directory domain, the SIDHistory value gets included in the user's access token. Essentially, this gives the user two account identities: the new Active Directory account, represented by the ObjectSID attribute, and the old NT account, represented by the SIDHistory attribute.

In a migration involving Exchange, first create the user accounts in Active Directory using the migration utility of your choice, and then install and run the ADC to populate these objects with e-mail attributes. As shown in Figure 12.5, the ADC starts off by matching a mailbox owner's SID with a SID stored in SIDHistory. Once the ADC completes this initial match and copies the e-mail attributes, it can then use ADC-Global-Names to permanently link the two objects.

Figure 12.5 Migrated user maps to legacy Exchange mailbox via SIDHistory attribute.migration from legacy ExchangeADCNT domainsADC (Active Directory Connector)migration from legacy ExchangeNT domainsADMT (Active Directory Migration Tool)NT domainsmigration from legacy ExchangeNT domainsmigration from legacy Exchangelegacy Exchange serversmigration to Exchange 2003ADC operations

Invalid User Accounts

The ADC matching process might seem straightforward, but if you read between the lines, you'll see that the ADC makes a couple of critical assumptions:

• Valid mailbox owner. Every mailbox in the legacy Exchange directory service has an owner that exists in Active Directory.

• Unique mailbox owner. No two mailboxes have the same owner.

One or both of these assumptions might prove invalid in a production environment. For example, although it's unusual to have a mailbox with no owner, it's possible for someone to create a mailbox and deliberately not put an entry in the Primary Windows NT Account field. Or the mailbox owner might be assigned to a group, something not supported by Active Directory. Missing owners can also occur in domain migrations, where an NT account might not successfully copy to Active Directory for one reason or another. Keep in mind that a mailbox can be assigned only to a single user.

If a legacy mailbox owner does not exist as a user object in Active Directory, the ADC creates a disabled user object to represent the recipient. As shown in Figure 12.6, this disabled user object has no legacy NT domain SID, so the ADC creates an attribute called msExchangeMasterAccountSID and populates it with the user's legacy SID. It then uses this attribute as the initial match between the disabled user object and the legacy mailbox owner so it can populate the object with e-mail attributes and set up the ADC-Global-Names link.

Figure 12.6 ADC creates a disabled user object when confronted with a legacy Exchange mailbox without a direct match in Active Directory.legacy Exchange serversmigration to Exchange 2003ADC operations

Don't Enable the Disabled User Objects

A disabled user object created by the ADC acts solely as a placeholder. It has no authentication functions. As shown in Figure 12.7, the disabled object has a scrambled logon name and no User Principal Name (UPN), indicating that it should not be used for logon purposes. (You can't see it in the user interface, but the account also gets a randomly generated complex password.)

Figure 12.7 Disabled mailbox created by ADC not intended for authentication purposes. It's simply a placeholder for a resource mailbox.

If you do a thorough job of migrating user accounts from each NT domain to Active Directory, you should not see any disabled user accounts after installing the ADC. If you do get a disabled user account, don't simply change the logon name and enable the account. Determine why the legacy mailbox did not have a valid owner, correct the condition, and then delete the disabled user account and let the ADC find the correct object. Microsoft Knowledge-Base article 316047 discusses the various negative effects of enabling a disabled ADC placeholder account and offers several workarounds.

Multiple Mailbox Owners

Another common ADC matching issue involves so-called resource mailboxes. These mailboxes don't represent users. Instead, they represent conference rooms, projectors, audio equipment, laptop computers, and so forth. By creating mailboxes for these items, you can use the free/busy information in Outlook calendars to schedule access to the resources.

Resource mailboxes tend to have the same owner. For example, a single admin assistant in an office might own all the resource mailboxes for the conference rooms and audio-visual equipment. This presents a problem for the ADC, because Exchange 2003 permits users to have only one mailbox. You can resolve this problem using an ADC feature called NTDSNoMatch. Here's how it works.

Consider a user who has ownership of a primary mailbox and several resource mailboxes. The ADC Tools has a Resource Mailbox Wizard that looks for multiple mailboxes owned by the same user. It presents these mailboxes in a tree with the suggested primary mailbox shown in bold, as shown in Figure 12.8.

Figure 12.8 Primary mailbox can be mapped to user account separately from resource mailboxes using Resource Mailbox Wizard in ADC Tools.mailboxesmultiple ownersResource Mailbox wizardmultiple mailbox owner

The wizard determines its candidate for the primary mailbox by matching the mailbox alias to the user name. If the wizard makes a mistake, you can highlight the actual primary mailbox and click Set as Primary. (The Resource Mailbox Wizard in the ADC Tools replaces the NTDSNoMatch utility described in Microsoft Knowledge-Base article 274173.)

The wizard takes the settings you configure in the tree and marks each resource mailbox by placing the word NTDSNoMatch in Custom Attribute 10 of the mailbox object in legacy Exchange. Figure 12.9 shows an example.

Figure 12.9 Resource mailboxes marked with NTDSNoMatch entry in Custom Attribute 10 of legacy Exchange object.migration from legacy ExchangeADCinvalid user accountsADC (Active Directory Connector)migration from legacy Exchangeinvalid user accountsinvalid user accountsmigration from legacy Exchangeuser accountsmigration from legacy Exchangeinvalid accountslegacy Exchange serversmigration to Exchange 2003ADC operations

When the ADC runs the Recipient Connection Agreement the first time, it copies the e-mail attributes from the primary mailbox to the matching user object in Active Directory. It then creates disabled user accounts for each resource mailbox and places the original owner on the permission list for those mailboxes, so the original owner retains the ability to open the mailboxes, even though they are now owned by the disabled user accounts.

Active Directory Account Cleanup Wizard

If you should accidentally or deliberately use the ADC to create a set of disabled user accounts in Active Directory prior to migrating users from one or more legacy domains, you can recover full functionality in two stages.

• First, migrate user accounts using ADMT or a third-party migration tool. Because the migrated accounts have actual logon names, not the scrambled logon names assigned by the ADC, the migration succeeds so long as you don't target the new user objects to the same container that holds the disabled user objects.

• Second, use the Active Directory Account Cleanup Wizard that accompanies the ADC to merge the e-mail attributes from the disabled user objects to the actual user objects and then delete the disabled objects.

The AD Account Cleanup Wizard is installed along with Exchange 2003 and can be accessed via the Start menu using the path Start | All Programs | Microsoft Exchange | Deployment. Run the Active Directory Cleanup Wizard as follows:

1. At the initial welcome screen, click Next. The Identify Merging Accounts window opens, as shown in Figure 12.10.

   Figure 12.10 AD Cleanup Wizard showing Identify Merging Accounts window where you select a search container for the cleanup.migration from legacy ExchangeADCAD Account Cleanup wizardADC (Active Directory Connector)migration from legacy ExchangeAccount Cleanup wizarduser accountsmigration from legacy ExchangeAD Account Cleanup wizardAccount Cleanup wizard (Active Directory)migration from legacy Exchange

2. Leave the Search Entire Directory or Selected Containers option selected along with the Search Based on Exchange Mailboxes Only.

3. Click Next. After a period of searching, the Review Merging Accounts window opens to display the list of disabled accounts that match enabled accounts. Figure 12.11 shows an example.

   Figure 12.11 Review Merging Accounts window gives side-by-side comparison of disabled user object and live user object.migration from legacy ExchangeADCAD Account Cleanup wizardADC (Active Directory Connector)migration from legacy ExchangeAccount Cleanup wizarduser accountsmigration from legacy ExchangeAD Account Cleanup wizardAccount Cleanup wizard (Active Directory)migration from legacy Exchange

4. Click Next. The Begin Merging Accounts window opens, as shown in Figure 12.12.

   Figure 12.12 Begin Merging Accounts window provides options to do the merge or save to a file.legacy Exchange serversmigration to Exchange 2003ADC operations

5. Check the Begin the Merge Process Now box.

6. Click Next to begin the merge. Acknowledge the warning that pops up.

7. Once the merge has completed, a Summary window opens. If you see any errors, follow up by checking the Adclean.log file in the \Exchsrvr\bin folder.

Now check the Recipients folder that originally held the disabled user accounts and verify that the accounts have disappeared. You might need to press F5 to refresh the display. Check the Properties window of a user account to verify the presence of the Exchange tabs and that the Exchange information looks correct.

As a recap, you should not need to use the Active Directory Cleanup Wizard if you perform the migration steps in the proper order (migrate and then install the ADC.) If you have a few accounts that did not migrate the first time, you can use the Active Directory Cleanup Wizard to merge the e-mail attributes and avoid a remigration. You can also run Adclean.exe from the command line. The utility has several switches. See Microsoft Knowledge-Base article 270655 for details.

ADC and Distribution Lists

Exchange 2003 uses Distribution groups and Security groups in Active Directory to represent distribution lists. When the ADC encounters a distribution list in the legacy Exchange directory service, it creates a Universal Distribution Group in Active Directory.

The ADC creates Universal groups so that the members can get mail from any user in any domain in the forest. Universal group membership replicates in the Global Catalog so that membership expansion works correctly.

The ADC creates Distribution groups rather than Security groups just in case the target domain has not been upgraded to Windows 2000 Native functional level or higher. Distribution groups have an SID, but they cannot be used on Access Control Lists (ACLs) for security objects such as NTFS files and folders, Registry keys, and Active Directory objects. Creating Universal groups also avoids conflict with Windows administrators, who might not want a pile of new Security groups to appear in Active Directory following the e-mail migration.

Automatic Security Group Upgrades

Populating Active Directory with Universal Distribution Groups can lead to a problem, though. Legacy Exchange allows distribution lists to control access to resources such as public folders and user mailboxes.

In Exchange 2003, MAPI permissions on a public folder correspond to Access Control Entries (ACEs) on an ACL for the folder. Figure 12.13 shows a comparison of the MAPI permissions and ACEs for an example public folder. The example shows that a group called TucsonDistro1 appears on the MAPI permission list with the Author role, and that Exchange converts this to a set of ALLOW and DENY entries for two ACEs in the ACL for the folder.

Figure 12.13 MAPI role corresponds to a set of Allow and Deny permissions in standard Windows ACL.Security groupsmigration from legacy Exchange

It's this correlation of MAPI permissions to ACL entries that causes a problem when the ADC creates a Universal Distribution Group. If the distribution list represented by that group appears on the MAPI permissions of a public folder, then the Exchange 2003 Information Store can't create an Access Control Entry for the group to put on the ACL for the folder.

Exchange 2003 resolves this in the same way that your mother resolved arguments with you. It doesn't take no for an answer. If the Information Store sees that a Universal Distribution Group has been placed on the MAPI permissions for a public folder or user mailbox, it automatically promotes the group to a Universal Security Group and then puts the SID of the group in the ACL.

Distribution List Membership

When the ADC creates a new Universal Distribution Group, it populates the group with members based on the membership of the legacy Exchange distribution list.

For example, if the legacy Exchange directory service contains a distribution list called South Park that holds a recipient named Kenney, the ADC creates a Universal Distribution Group called South Park and links the group's Member attribute to the Kenney object.

If a distribution list contains an invalid recipient—for example, if someone deletes the Kenny object from Active Directory (the b#*$%ds)—the ADC would create a disabled user account to represent the recipient and then would create the Universal Distribution Group with a link between the Member attribute and the disabled account.

Subsequent changes to the group membership in Active Directory replicate to legacy Exchange as a change to the distribution list members.

If you permanently delete the newly created Kenny account from Active Directory and remove him from the membership of the South Park group, then the ADC removes him from the legacy distribution list, as well.