Windows Insider

Making the Connection

Using the Active Directory Connector is an effective way to move your legacy Exchange environment to a new Exchange 2003 setup.

• By Bill Boswell
• 04/01/2004

I was born in a small town in New Mexico. Visitors to my home state generally share a few common experiences: blistering their tongues on the local cuisine, getting speeding tickets in towns along the Texas border, and buying mementos made in factories in China and not, as the sellers promise, by the hands of local Native Americans.

Visitors to New Mexico also get a sense of the vastness of nature, especially if they run out of gas on a two-lane strip of asphalt in the middle of thousands of square miles of sun-baked Pleistocene sandstone and ancient lava flows.

I think about this whenever I talk to someone who’s completed the upgrade from Windows NT 4.0 to Active Directory, but hasn’t yet made the transition from legacy Exchange to Exchange 2000 or Exchange 2003. They’ve only completed half the journey and still have a lot of long, dusty miles ahead of them.

One of the challenges in making the transition to a modern version of Exchange is 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. Those parameters then have to be put into AD so you can move user mailboxes and Internet connectors to sleek, new Exchange servers with minimal service disruption.

The tool Microsoft supplies to perform this service is the Active Directory Connector, or ADC. As illustrated in Figure 1, the ADC locates objects of interest in both directory services—legacy Exchange and AD—and copies the attributes of those objects back and forth to keep the settings in sync. Legacy mailbox owners (recipients) replicate to AD 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 1. Connections made between legacy Exchange and AD by the AD Connector (ADC). (Click image to view larger version.)

With the ADC working in the background, you can manage your legacy Exchange recipients, distribution lists, and custom recipients from the AD Users and Computers console. Once all mailboxes and public folders and connectors have been moved, you can decommission the legacy servers and remove the ADC from service.

When installing the ADC, use the version that matches the Exchange version you plan on deploying. If you haven’t yet begun your Exchange upgrade, I’d recommend going right to Exchange 2003 and skipping Exchange 2000 completely. You’ll like the new features and additional security options in Exchange 2003, and the deployment tools make installation almost routine.

To get all the new features in Exchange 2003, you should deploy it on Windows Server 2003 member servers in a Windows 2003 forest. If your Windows 2003 deployment still lies many months in the future, you can deploy Exchange 2003 in a Windows 2000 Server domain, either on Windows 2003 member servers or on Win2K member servers. You can’t do the opposite, however. You can’t run Exchange 2000 or Exchange 5.5 on Windows Server 2003. (You’ll see hints on the Internet that suggest installing legacy Exchange on Win2K then upgrading to Windows 2003, but this configuration isn’t supported and shouldn’t be used in production.)

Don’t use the version of ADC that comes on the Win2K or Windows 2003 Setup CD. That version doesn’t map special attributes required by Exchange recipients and public folders. If you’ve already installed the operating system version of the ADC, remove it before installing the Exchange version. Also, unlike the Exchange files themselves, you can do the initial installation of the ADC using the Exchange service pack files.

Connection Agreements
The ADC stores configuration para-meters in AD objects called Connection Agreements (CAs). A CA defines the object types that the ADC will copy, their source and target containers, the replication schedule, the account credentials to use for replication, 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 have support for LDAP writes and paged results. (Once your deployment has begun, you can point your CAs to the Site Replication Service on a modern Exchange server, which emulates the legacy Exchange directory service.) Exchange servers that don’t form the endpoint of a CA can run earlier versions of Exchange, but you should try to run the same version on all servers to minimize compatibility problems.

The ADC uses three types of CAs:

Recipient. This CA maps the attributes of User, Group, and Contact objects in AD 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 AD to permit modern Exchange to accept e-mail on behalf of the public folders.

Configuration. This CA maps some of the content of the Configuration container in the legacy Exchange directory service with objects in the Organization container in AD. Exchange Setup or subsequent SRS activation creates this CA. You can’t create one manually.

Because each legacy Exchange site forms a separate naming context in the legacy 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.

ADC Mailbox Mapping
To build a mental picture of the way the ADC operates, it helps to understand the operation 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 you do an in-place upgrade of an NT 4.0 domain to AD. This transfers the user account information from the SAM of the PDC into AD, including the users’ original SIDs and passwords. As shown in Figure 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. AD stores the SID in an attribute called ObjectSID.

Figure 2. The initial Exchange mailbox mapping using the user’s SID. (Click image to view larger version.)

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 AD with a matching ObjectSID attribute.

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

Figure 3. User attributes after initial mapping and replication by ADC. (Click image to view larger version.)

ADC-Global-Names
In addition to copying attributes from legacy Exchange, the ADC assigns a new attribute called ADC-Global-Names to the AD 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 in-cludes 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 AD 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 complimentary object in legacy Exchange, then replicates any updated e-mail attributes. This transaction also replicates the ADC-Global-Names attribute.

After this replication, as shown in Figure 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 AD along with an update timestamp and some flags.

Figure 4. ADC-Global-Names content after replication back to legacy Exchange. (Click image to view larger version.)

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

NT Account Migrations
Not all transitions from NT to AD involve an in-place upgrade of the PDC, though. Many organizations create a pristine AD domain then use a utility such as the Active Directory Migration Tool (ADMT) or third-party utility to migrate user, group and computer accounts into the AD 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 AD attribute called SIDHistory. The SID stored in SIDHistory gets included in the user’s access token. Essentially, this gives the user two account identities: The new AD account, represented by the ObjectSID attribute, and the old NT account, represented by the SIDHistory attribute.

In a migration involving Exchange, you first create the user accounts in AD using the migration utility of choice, then install and run the ADC to populate these objects with e-mail attributes. As shown in Figure 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 5. Mailbox mapping after account migration using SIDHistory. (Click image to view larger version.)

Invalid User Accounts
The ADC matching process may 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 AD.

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

One or both of these assumptions may 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 AD. Missing owners can also occur in domain migrations, where an NT account might not successfully copy to AD for one reason or another.

If a legacy mailbox owner doesn’t exist as a user object in AD, the ADC creates a disabled user object to represent the recipient. As shown in Figure 6, this 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 link 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 linkage.

Figure 6. Disabled user object created by ADC to represent legacy mailbox with no valid owner. (Click image to view larger version.)

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

You shouldn’t see disabled user accounts if you verify that each mailbox has a valid owner prior to installing the ADC. If you do get a disabled user account after running a Recipient Connection Agreement, don’t simply change the logon name and enable the account. Determine why the legacy mailbox didn’t have a valid owner, correct the condition, then delete the disabled user account and run the Recipient Connection Agreement again. Microsoft Knowledgebase article 316047, “XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts,” discusses the various negative effects of enabling a disabled ADC placeholder account and offers other 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 the Exchange calendar for scheduling access to them.

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 modern Exchange only permits a user to own 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 (see Figure 7). It presents these mailboxes in a tree with the suggested primary mailbox shown in bold. It determines the candidate for the primary mailbox by matching the mailbox alias to the user name. If the Wizard makes a mistake, simply highlight the actual primary mailbox and click Set as Primary.

Figure 7. Resource Mailbox Wizard in Exchange 2003 showing primary and resource mailboxes.

The wizard takes these settings and marks each resource mailbox by placing the word NTDSNoMatch in Custom Attribute 10 of the mailbox. 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 AD, then creates disabled user accounts for the resource mailboxes. The ADC places the original owner on the permission list for the resource mailbox so that the user retains the ability to open the mailbox even though it’s owned by the disabled user account.

Making the Journey
I hope this talk of directory service interconnections and attribute mapping hasn’t scared you off from starting your Exchange migration. The checklists and support tools in Exchange 2003 make installing and configuring the ADC as simple as these things can get, considering the complexity of the task. If you have a properly configured, reliable DNS infrastructure, a solid AD deployment and a well-managed legacy Exchange environment, you should get to the end of the migration with few problems.