The Active Directory Connector (ADC) has been around since Exchange 2000 Server first hit the streets. You use the ADC to synchronize the Exchange Server 5.5 Directory Service (DS) with Active Directory (AD) so that a mixed Exchange organization containing both Exchange 5.5 and Exchange 2000 or Exchange Server 2003 servers has one consistent Global Address List (GAL) and one consistent set of configuration information.
The ADC has undergone quiet refinement over the years. The version that we use today with Exchange 2003 is much more powerful than earlier versions. Microsoft has silently applied many bug fixes to the ADC and has significantly enhanced behind-the-scenes functionality—most notably in the new support for cross-site mailbox moves, introduced in Exchange 2003 Service Pack 1 (SP1). Let's take a look at a few ill-documented or barely publicized aspects of the ADC that nevertheless have significant importance for Exchange administrators.
ADC Account Creation and Migration
During synchronization of mailbox objects, the Exchange 2000 version of the ADC uses a set of object-matching rules to try to find an object in AD that's related to an in-process Exchange 5.5 object. These rules attempt to match first on globally unique identifiers (GUIDs), then distinguished names (DNs), and finally on SIDs. If the ADC can find no matching object in AD, it creates a new object (typically a user object) in AD. The new user object is created with a samAccountName attribute (also the User logon name) that matches the Exchange 5.5 mailbox alias, as Figure 1 shows.
Although this functionality works well for many organizations, problems arise when the ADC creates accounts before any legacy Windows NT 4.0-to-AD account migration takes place. In such cases, the ADC might create an AD account with a logon name of neiln (as you see in Figure 1), but if an administrator subsequently uses the Active Directory Migration Tool (ADMT) to migrate the corresponding NT 4.0 account to AD, a naming clash occurs. Many organizations have NT 4.0 logon names that are identical to Exchange mailbox aliases. If a clash occurs, ADMT typically appends (or prepends) a numeric value to the samAccountName of the new object it has created. Thus, the ADC might ultimately create two accounts, with logon names of neiln and neiln-1. The standard approach in this case is to use the AD Cleanup Tool to identify the matching objects and merge them, but unfortunately the AD Cleanup Tool merges the ADC-created object into the ADMT-created object. Therefore, either you end up with user logon names that are changed to values such as neiln-1, or you have to change the logon names.
Furthermore, some organizations cut corners and use the ADC-created object as a legitimate logon account. Doing so is disastrous because unlike an ADMT-created account, an ADC-created object doesn't have a sIDHistory attribute; therefore, access to security resources such as printers, network shares, and groups would be lost after the migration. Only when you use ADMT (or another third-party account-migration tool) to migrate NT 4.0 accounts can you make the full security context available.
Other problems specifically related to Public Folder access and mailbox delegation might arise if users enable and use ADC-created accounts as "real" accounts. When an Exchange user attempts to access an Exchange Public Folder, the Exchange Store process uses AD attributes associated with the mailbox to determine whether the user has the correct permissions to access the Public Folder information. Only the ADC can populate the msExchMasterAccountSID attribute with a value: Accounts created in AD either through Exchange System Manager (ESM) or through ADMT won't have a value for msExchMasterAccountSID. Therefore, when a user continues to log on to an old NT 4.0 account (completely separate from AD), his or her permissions and ability to access Pubic Folder content or access another user's mailbox are determined by the value in msExchMasterAccountSID—not the SID associated with the ADC-created account.
However, for AD accounts that ESM or ADMT creates, the Store uses the object's security context (through either the objectSID or the sIDHistory) to calculate access to a resource. The Store process knows which approach to use because it assumes that an enabled object (i.e., an object created by ESM or ADMT) can use its security context, whereas a disabled object (i.e., an object created by the ADC) must rely on the msExchMasterAccountSID. Therefore, if a user utilizes an ADC-created account for logon, the appropriate security context might not be in place.
Some third-party NT 4.0-to-AD migration tools deal more gracefully with the existence of an ADC-created object whose samAccountName matches the NT 4.0 logon name of the migrated account. These tools recognize that the matching values are related and merge them during the NT 4.0 account migration. Therefore, no duplicate objects exist in AD and there's no need to subsequently run the AD Cleanup Tool.
samAccountName-Mapping Changes
In a simplification effort, Microsoft modified the behavior of the ADC when Exchange 2003 shipped. In the Exchange 2003 version of the ADC, the samAccountName is randomized when the ADC creates an AD object for an Exchange 5.5 mailbox. Instead of creating an AD account with a logon name matching the Exchange 5.5 mailbox alias, the ADC creates the AD account's logon name (i.e., samAccountName attribute) with a value such as ADC_SNWNIEAEHAIGTRWNV.
The effect of this randomized samAccountName format is twofold. First, when ADMT migrates NT 4.0 accounts to AD, the chances of a name clash are small because the NT 4.0 logon name is unlikely to be the same as the samAccountName of the ADC-created object. Therefore, the ADMT-created account will have a logon name that's identical to the NT 4.0 account logon name, and when the AD Cleanup Tool merges the two accounts, the desirable logon name will be retained—that is, neiln rather than neiln-1. Second, the problem of using the ADC-created account as the primary logon account is effectively eliminated. The long-winded and difficult-to-remember nature of this randomized account logon name is enough to discourage even the most technical of users from using it as a logon name.
This new approach clearly has its advantages, but some third-party migration tools present problems. Some of these tools rely on the fact that the ADC-created object's samAccountName is identical to the logon value used for the NT 4.0 account and in fact match on this field during NT 4.0 account migration. With the new default behavior, the tools can no longer use this functionality. Although this updated functionality in the Exchange 2003 version of the ADC has been available for a while, many migration tools (e.g., Microsoft's ADMT) still suffer from this problem.