Making the Connection
Using the Active Directory Connector is an effective way to move your legacy Exchange environment to a new Exchange 2003 setup.
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.
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
|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.)
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
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
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
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
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.