The Active Directory Connector (ADC) management console now contains an ADC Tools option. ADC Tools is a collection of wizards and tools that help you set up connection agreements. Specifically, ADC Tools scans your current Active Directory® directory service and Exchange Server 5.5 directory and organization, and then automatically creates the recommended connection agreements.

The following sections discuss the wizards that are included in ADC Tools.

 Resource Mailbox Wizard

The Resource Mailbox Wizard identifies Active Directory accounts that match more than one Exchange Server 5.5 mailbox. Using this wizard, you can match the appropriate primary mailbox to the Active Directory account and stamp other mailboxes with the NTDSNoMatch attribute, which designates the mailboxes as resource mailboxes. You can either make these changes through the graphical user interface (GUI) or export a comma-separated value (.csv) file that you can update and import into the Exchange Server 5.5 directory.

Note:
If any changes were made after you ran this wizard, the results will not be seen by ADC Tools unless you run the data collection step again. Therefore, if any changes were made in later steps, you need to re-run data collection to be able to verify that the ADC wizards are now running without reporting errors.

 Connection Agreement Wizard

This wizard recommends public folder connection agreements and recipient connection agreements based on your Exchange Server 5.5 directory and Active Directory configuration. You can review the list of recommended connection agreements and select those you want the wizard to create.

In Exchange 2000 Server, the ADC schema files were a subset of the Exchange 2000 Server core schema files. So, although the ADC’s setup /schemaonly switch extended the schema, customers were required to perform further schema extensions using setup /forestprep. This meant longer lockdown periods for larger customers whose custom applications were sensitive to schema extensions because of the delayed nature of replications and resetting of indexed attributes. For more information about indexed attributes, see Microsoft Knowledge Base article 230662, "Enumerating Indexed Attributes in Windows 2000 Active Directory."

In Exchange Server 2003, the schema files imported during the installation or upgrade of an Active Directory Connector service are identical to the core Exchange Server 2003 schema; therefore, the schema is updated only once. So, if the Exchange Server 2003 version of ADC setup detects the existence of the Exchange Server 2003 schema, no further schema updates are applied. On the other hand, if ADC setup detects a schema version below 6870, the Exchange Server 2003 schema updates are applied.

Note:

Although the Exchange Server 2003 ADC setup includes the entire schema, it does not mean it is equal to a setup /forestprep. This is because ADC Setup does not perform many of forestprep’s actions, such as importing the Microsoft Office Outlook® templates and setting access control lists (ACLs) on some Active Directory containers. Additionally, forestprep cleans up some address templates and display specifiers that were Exchange Server 5.5 classes that were never used nor shown in Active Directory. Therefore, forestprep is still required if ADC setup is run first, but customers who follow change-control procedures within large environments will not need to plan for additional administrative lockdowns as they wait for schema changes to replicate, because schema extensions are skipped when running forestprep later.

When the ADC is upgraded to the Exchange Server 2003 version, the ADC setup program not only upgrades the ADC binaries, but it also modifies the versionNumber attribute on any connection agreements owned by that ADC service.

To determine what connection agreements are owned by an ADC service, use the Active Directory Connector Services snap-in, and select the ADC server indicated by the name Active Directory Connector servername on the left pane. Its owned connection agreements will be viewable on the right.

When ADC setup upgrades the connection agreement versionNumber attribute, the values are set to 16973842. Older ADC services (such as Microsoft® Windows® 2000 Server ADC and Exchange 2000 Server SP3 ADC) cannot process these new connection agreements because they expect the older Major version (versionNumber = 16908296). Additionally, if an Exchange 2000 Server or Windows 2000 Server ADC manager snap-in is used to administer an upgraded or new Exchange Server 2003 connection agreement, the following warning is displayed.

By the same token, whenever an Exchange 2003 ADC Services snap-in is used to open the properties of an Exchange 2000 Server or Windows 2000 Server connection agreement, the same warning will appear.

The following are two reasons for increasing the major versions on public folder connection agreements and recipient connection agreements:

• Windows 2000 Server ADC services cannot run any newer connection agreements. Any public folder connection agreement re-homed to the Windows 2000 Server version of the ADC service caused corruption.
  
• The new connection agreements use Kerberos for authentication, which is not understood by Exchange 2000 Server ADC services.
  

In summary, an Exchange 2000 Server ADC service cannot run a connection agreement whose version is incompatible with its own. Conversely, an Exchange Server 2003 service cannot run a connection agreement whose versionNumber is below 16973842.

Eventually, all ADC services must be upgraded prior to the installation of the first server that runs Exchange 2003 Server. Otherwise, Exchange Server 2003 setup may not proceed. Administrators must perform an "in-place upgrade" of all pre-Exchange Server 2003 ADC services prior to installation, so that all legacy connection agreements are phased-out.

If an Exchange Server 5.5 object exists, but its primary Windows account (assoc-NT-account) resides in a Microsoft Windows NT® Server 4.0 domain or in a separate forest, a properly configured connection agreement directs the ADC service to perform object-creation. By contrast, if the mailbox’s primary Windows NT account pre-existed within the forest, the ADC performs object matching and stamps pre-existing user accounts during the initial replication cycle. By default, in the object-creation connection agreements, a disabled account is created by the ADC service. In the past, the Exchange 2000 Server ADC services would generate the disabled security principal (that is, samaccountname or pre-Windows 2000 logon name) that matched the Exchange Server object’s alias name. This situation caused problems for a couple of reasons.

• Customers often had the misunderstanding that ADC object creation was an easy way to migrate Windows NT Server 4.0 accounts to Active Directory. Although it wasn’t proper, customers would enable these “placeholder” accounts that were generated by the ADC, not knowing that doing so would cause delegation problems, public folder ACL conversion problems, and other permissions problems that may prevent logon or mailbox moves. For more information about problems caused by enabling placeholder accounts, see Microsoft Knowledge Base article 316047, XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts.
  
• ADC-generated objects conflict with the Active Directory Migration Tool’s (ADMT) ability to migrate user logon names from their source domains. (This situation only applies if ADMT is used after the initial ADC replication, and if the aliasname=userlogonname of the source domain). So when ADMT attempts to create user objects in the target domain, it encounters conflicts with the ADC-generated accounts. ADMT was designed to resolve these conflicts by appending -1 to each samaccountname it generates – thus satisfying the samaccountname uniqueness within a domain. Although ADMT is a proper and supported migration method for user accounts, the -1 object causes an issue for customers because their users prefer not to append a -1 to their logon process. One may believe that ADClean may be used to merge the two objects into a single account, thereby resolving this issue. However, ADClean excludes transferring samaccountname when it merges the disabled objects’ attributes to the ADMT-generated account. In the end, users are still stuck with different user logon names (for example, a user was accustomed to logging on to the source domain as "johnsmith" but must now log on as "johnsmith-1").
  

In Exchange Server 2003, by randomizing samaccountnames (that is, pre-Windows 2000 Server logon name) whenever the ADC generates a placeholder object, both previous problem scenarios are resolved. A typical user logon name for an ADC-generated account would be "ADC_BDZQOKNUIZDWPPHG" where the characters following the underscore are always randomized. Because this random username is difficult to use for any logon prompt, it inhibits administrators from improperly enabling the placeholder accounts generated by the ADC. Second, the prepared random name will not cause naming conflicts when the future ADMT migrations try to create new users in the Exchange Server 2003 forest. The following figure shows how this looks on the actual account.

Note:

Although the Exchange Server 2003 ADC corrects this issue during object creation, any existing objects that were created prior to when ADC was upgraded may still need their account names renamed. CleanSAM.vbs, a script used by Microsoft Product Support Services to correct the above issues for Exchange 2000 Server topologies, may be used against accounts residing in Exchange Server 2003 environments that were upgraded from Exchange 2000 Server. The script may be obtained by contacting Microsoft Product Support Services. The CleanSAM script also resolved the behavior where, in some instances, ADMT would “match” with the disabled accounts and subsequently merge on top of them, thereby enabling the accounts but failing to clear the msExchMasterAccountSID attribute.

There is one exception that prevents the new ADC from randomizing samaccountnames and that is when the ADC replicates an Exchange Server 5.5 "resource" object. (Specifically, the Exchange Server 5.5 object contains the value NTDSNoMatch on custom attribute 10).

This is because the Exchange Server 5.5 object's associated Windows NT account is already matched with some other Exchange Server  5.5 object that is a 'primary.' Because the ADC randomizes for that 'primary' mailbox, that primary mailbox will be merged with the ADMT account. But for the resource mailbox, the Exchange Server 2003 ADC creates them the same way as in Exchange 2000 Server; that is, with the samaccountname being the same as the alias, because it is not expected that ADMT will see a conflict. (There was no unique associated Windows NT account for our resource mailbox in the first place!)

Connection agreements no longer use Windows NT Server 4.0 Challenge/Response (NTLM) for authentication to domain controllers. Instead, the Exchange Server 2003 ADC uses Kerberos for authentication. This change was made because:

• The ADC contains many valuable passwords, such as domain administrator or even enterprise administrator-level of privileges.
  
• NTLM and unsigned Lightweight Directory Access Protocol (LDAP) are susceptible to replay attacks.
  

This change only affects the ADC server during its communication with a Windows 2000 Server SP3 domain controller or later. The following figure illustrates the hard-coded changes to the ADC manager.

Note:
In this figure, Exchange Server 5.5 LDAP communication remains at the Windows NT Server 4.0 Challenge/Response authentication mechanism. Only Windows 2000 Server SP3 or Windows Server 2003 domain controllers support signed LDAP on connection agreements.

It is worth noting that the automatically created (by ADC Tools) connection agreements (either public folder or recipient connection agreements) will have an additional filter that will make them replicate only objects for specific site naming context. In other words, let's say that you have a domain called "Root" and a site called "Mixed". You run ADC Tools and the connection agreements are created for this site and it is all replicating well.

Next, you create a new administrative group, let's say it is a pure Exchange 2000 Server/Exchange Server 2003 administrative group and you call it "AG2". With an ADC Tools created recipient connection agreement in place, you will notice that new mailbox-enabled users in the same Active Directory domain that are in site AG2 will not replicate to Exchange Server 5.5/Site Replication Service (SRS), even though those AG2 user mailboxes might be in the same Organizational Unit as user mailboxes for the Mixed site that do replicate. The reason why this is the case can be found in the following attribute of ADC-created recipient connection agreement:

1> msExchServer1SearchFilter: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=My Organization/ou=Mixed/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE)));

This attribute shows that this recipient connection agreement will filter on the site called Mixed, therefore, it will replicate only mailboxes that are in the Mixed site.

In contrast to the attribute above, the following attribute is the same attribute from a recipient connection agreement that was created manually (not through ADC Tools):

1> msExchServer1SearchFilter: (|(objectclass=user)(objectclass=contact)(objectclass=group));

Therefore, this recipient connection agreement will replicate any objects that belong to any site, as long as they are in the containers that ADC replicates.

What you would need to do in this situation is to either create a manual connection agreement (which will not include a per-administrative group filter), or rerun the ADC Tools so that it will discover the new administrative group and create another user connection agreement whose search filter includes objects from /ou=AG2.

It is worth noting that recipient connection agreements created by ADC Tools will typically point from "domain" to "site" levels and vice versa. This is done to ensure that everything actually gets replicated. Replication will happen, but it should be explained that, because of the domain to site levels and vice versa agreements, there may be additional containers created on both sides of the connection agreements.

In the following figure, note that the containers on those connection agreements are "top level," in other words, the domain and site.

This might cause additional containers to be created on both sides of this recipient connection agreement (depending on where mailboxes and mailbox-enabled Active Directory accounts are stored). The following figure shows an example.

Although these additional containers may appear to “litter” each directory, there is nothing technically wrong with having these extra containers because users who view the global address list (GAL) do not see the Exchange Server 5.5/Organizational Unit hierarchies. Additionally, administrators may easily move objects between Organizational Units to their desired locations, and those objects will still replicate because they will not fall outside of the domain-level search scope of the recipient connection agreement. (Previously, administrators moving objects with manual recipient connection agreements would often cause their GALs to become out-of-sync.) Keep in mind that the goal of ADC Tools’ connection agreement creation is to get the GALs replicated; it obviously cannot guess how administrators want to organize their administrative structures.

One thing to note, ADC is not necessarily going to match with already created containers. For example, let's say that you have a simple Organizational Unit like Users and a mailbox-enabled user like Administrator in Exchange Server 2003 and the connection agreements were set up by ADC Tools so they source the domain and the Exchange Site. When the connection agreement runs, it creates a Users sub-container in Exchange Server 5.5 under the Recipients container. When the connection agreement runs again, it doesn’t find the existing Organizational Unit called Users on the Active Directory side; instead, it creates a sub Organizational Unit underneath the Organizational Unit you specify as the default staging area. This problem, again, is only a "cosmetic" problem.

For more information, see the following Microsoft Knowledge Base articles:

• 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts"
  
• 230662, "Enumerating Indexed Attributes in Windows 2000 Active Directory"