5 Things They Never Told You About the ADC

Avoid these pitfalls

On the face of it, the Active Directory Connector (ADC) seems like a straightforward piece of technology. Armed with the requisite Schema and Enterprise Admin privileges, you simply install it from the CD-ROM, configure it by pointing one end to an Exchange Server 5.5 Directory Service (DS) and the other end to a Windows 2000 Active Directory (AD) service, and—bah-dah-bing, bah-dah-boom—you immediately start synchronizing information between the directories. Simple!

Well, the process isn't as straightforward as that! The ADC is certainly a powerful tool for synchronizing information, but its operation can be quite subtle. To use the ADC effectively and efficiently in a production environment, you need to understand some of its idiosyncrasies. Here are five hints that will get you on the right track.

1. Use the Right Version for the Job
The ADC has two versions. One ADC version is on the Win2K installation CD-ROM, so obviously the ADC has been around for some time. Many companies that have been experimenting with Win2K since its beta days have also taken the time to play with the Win2K ADC and have been replicating information from the Exchange Server 5.5 DS into the AD. Microsoft made the Win2K ADC version available to let you prepare the AD for eventual migration to Exchange 2000 Server.

Another ADC version is on the Exchange 2000 installation CD-ROM; you must use this version when you're working with Exchange 2000. The Win2K ADC is functional insofar as it lets you synchronize recipient information (e.g., mailboxes, custom recipients, distribution lists—DLs) between Exchange Server 5.5 and AD, but the Exchange 2000 ADC goes further. In addition to being able to synchronize recipient information, this ADC version can also deal with Exchange Server 5.5 configuration information.

For most companies, making the move from Exchange Server 5.5 to Exchange 2000 will result in some form of coexistence between the old Exchange environment and the new one. This coexistence implies mail interoperability in which Exchange 2000 servers can use remote procedure calls (RPCs) to deliver messages natively to Exchange Server 5.5 servers (unlike the native Exchange 2000 SMTP mail transport).

To deliver messages in this way, Exchange 2000 uses information about the Exchange Server 5.5 environment from the configuration container of the Exchange Server 5.5 DS. The Exchange 2000 ADC creates a special type of connection agreement (CA) called a Configuration Connection Agreement (ConfigCA) that defines an instance of synchronization. The ConfigCA's role is to synchronize configuration container information with the AD's configuration naming context. The configuration-naming context holds all the Exchange 2000 environment's configuration information that Exchange 2000 servers require, including information about servers and Administrative and Routing Group topology.

Exchange 2000 automatically creates ConfigCAs on your behalf when you upgrade an Exchange Server 5.5 server to Exchange 2000 or when you install an Exchange 2000 server into an existing Exchange Server 5.5 site. However, for this process to work, you must make sure that you've already installed the correct ADC: You must use the Exchange 2000 ADC, not the Win2K ADC.

You can tell which version of the ADC you're using by looking at the version number on the adc.exe Properties tab. On a Win2K ADC, the version number is 6.0.3939.7, whereas on the Exchange 2000 ADC, the version number is much higher. As you can see in Figure 1, the version number associated with the ADC from the Exchange 2000 Release Candidate 2 (RC2) kit is 6.0.4368.7.

2. Configure Two-Way CAs with Care
When you configure a CA, you can specify the direction in which you want it to operate. You can create a one-way CA from Exchange Server 5.5 to the AD, a one-way CA from the AD to Exchange Server 5.5, or a two-way CA between Exchange Server 5.5 and the AD.

In addition to specifying the direction, you need to specify which parts of the directory services you want to participate in the synchronization. Figure 2 shows the settings for the two-way CA between the systems my group uses to experiment with. In Figure 2, you can see that I want to have any Exchange Server 5.5 objects that exist in containers called DirSynced Objects, External People, and Recipients synchronized into one part of the AD, the Users organizational unit (OU). This CA shows the many-to-one characteristic of Exchange Server 5.5-container-to-AD OU mapping. If I'd wanted to reflect the same separation of objects into multiple containers in the AD, I would have needed three CAs: one CA to map each source container to its partner OU in the AD. In my example I can bundle those separate object groupings into a simpler structure in the AD, collapsing three containers into one. However, for your deployment the logical structure that you've had in the Exchange directory might still be desirable (from an administrative perspective) in the AD.

In my environment, I have settings on the From Windows tab that represent the other direction for my two-way CA, as Figure 3 shows. My CA properties specify that objects created or changed in the AD Users OU will have their modifications synchronized back to the Recipients container in the Exchange Server 5.5 DS. This kind of mapping lets you use the AD Users and Computers tool to centrally manage both Exchange Server 5.5 directory objects and native AD objects. I can manage attributes on that mailbox by updating the attributes on the synchronized version in the AD and see the changes replicated back to Exchange Server 5.5.

Think about the subtlety associated with this CA. A two-way CA is a two-way CA only if you explicitly map an Exchange Server 5.5 source container to a target AD OU and you explicitly provide mapping back from the target OU (BAR) to the source container.

In my example, the only two-way part of this CA is between the Exchange Server 5.5 Recipients container and the AD Users OU. Objects from the Recipients container will be synchronized into the AD. If I make any changes to the object in the AD—perhaps using the Active Directory Users and Computers tool—these changes will be synchronized back to the source object because an explicit synchronization path exists from the Users OU back to the Recipients container.

Unfortunately, my two other Exchange Server 5.5 containers, DirSynced Objects and External People, won't be synchronized back. No explicit synchronization path exists back from the Users OU to their respective Exchange Server 5.5 containers, so any changes I make to these objects in the AD aren't synchronized back to the Exchange Server 5.5 DS.

As you can see, defining a management model is imperative in synchronized environments such as this one. Either you use a single AD-based management model for directory objects, or you use a well-defined model that uses Microsoft Exchange Administrator to manage Exchange Server 5.5 objects and the AD Users and Computers tool to manage native AD objects.

Mixing management models only leads to confusion and data inconsistency. For example, you might use Exchange Administrator to modify an attribute on an object in the Exchange Server 5.5 directory and at the same time another administrator uses AD Users and Computers to modify the same attribute on the synchronized version of the object in the AD. In this case, the last modifier wins and the next ADC synchronization overwrites your Exchange Administrator native modification. Mixed management tools lead to management mix-ups.

3. Beware Exchange Server 5.5 Back Replication
When you start to deploy and enable the ADC, you might see unexpected replication in your Exchange Server 5.5 environment. For example, assume that I have a large Exchange Server 5.5 environment, distributed globally with multiple sites, hundreds of Exchange Server 5.5 servers, and tens of thousands of users. Over the weekend, my Exchange administrators decide that on Monday they want to experiment with the ADC. They plan to bring up an ADC and use a one-way CA from the Recipients containers in the headquarters location to bulk-load user objects into the AD. For the sake of this example, let's assume that the company is based in Chicago and that this location has 10 Exchange Server 5.5 servers, each with a thousand users.

My fictitious company has no Win2K infrastructure in place, but the Exchange Server 5.5 administrators are forward-looking and they want to become familiar with the technology. They bring up a small test lab that includes a couple of Win2K servers that aren't visible out on the corporate network.

The administrators plan to configure a one-way CA from Exchange Server 5.5 to AD, add the 10 Recipients containers (which are all homed in the Chicago site), and enable the CA. The administrators assume that they'll then start to see the AD become populated with 10,000 user objects, based on the 10,000 mailboxes in the Chicago site. They're pretty confident that this test is safe because the only traffic that they expect to see is object synchronization coming from the Chicago site into their test Win2K environment.

What happens is a little different and not a little surprising! A wave of Exchange Server 5.5 replication takes place across the hundreds of Exchange Server 5.5 servers that exist worldwide. Every one of the 10,000 Chicago-based mailboxes gets re-replicated across the whole Exchange Server 5.5 environment. Clearly, this behavior comes as a surprise to my administrators. They created only a one-way CA to the AD, so they didn't expect to see anything change in the production Exchange Server 5.5 environment.

What causes all this replication? As the ADC synchronizes each of the 10,000 Exchange Server 5.5 mailboxes, it modifies the ADC-Global-Names attribute on the object in the Exchange Server 5.5 Directory to reflect the fact that the ADC has synchronized this object. The ADC-Global-Names attribute is added to the Exchange Server 5.5 Directory Schema when you upgrade one Exchange Server 5.5 server to Service Pack 3 (SP3—a mandatory requirement for the ADC in Exchange 2000 RC2). However, in previous Exchange 2000 versions, when you configured a CA, the beta first time it connected to your Exchange Server 5.5 environment, it added the attribute to the Schema. (Figure 4 shows the attribute in Microsoft Exchange Administrator's raw mode.)

Now, dust off your Exchange Server 5.5 books. Remember that when you make any change to an Exchange Server 5.5 object, the Object-USN and Object-DSN-Signature attributes are updated, which means that the object will take part in Exchange Server 5.5 intrasite or intersite directory replication.

What's the lesson here? If you're going to do some testing (and you need to conduct tests sooner rather than later), make sure you use a separate test lab not connected to the production environment to avoid these unexpected anomalies.

4. Understand the CA Directory Replication Schedule
In the Exchange Server 5.5 world, when you set up a directory replication connector (DRC), you can specify how often you want replication to occur across the connector. On the CA Properties page's Schedule tab, you can elect to have replication take place Never, Always, or Selected times.

When you configure the schedule on the Schedule tab of a CA Properties dialog box, you see the familiar user interface (UI), which Figure 5 shows. This dialog box looks just like the schedule settings that the DRC uses, but the schedules have subtle differences.

On an Exchange Server 5.5 DRC, setting the schedule to Always translates as "Try to do some replication every 15 minutes." However, on the ADC, setting the schedule to Always means "Try to do some synchronization every 5 seconds."

Your initial reaction might be, "Great! Now when I say 'Always synchronize,' I'm getting what I really want." But what you get might not be what you want. The ADC uses Lightweight Directory Access Protocol (LDAP) to access both the Exchange Server 5.5 DS and the AD. As the ADC checks whether objects are to be synchronized, it executes an LDAP search based on the container and OU information that you've specified elsewhere on the CA. LDAP operations are costly, and they usually impose a significant load on the CPU of the systems on which the searches are being executed. Executing these LDAP searches every 5 seconds will undoubtedly affect the performance of the Exchange Server 5.5 and active servers that are hosting the ends of the CA.

What can you do about this supposed improved functionality? If you really want to check for synchronization every 5 seconds, consider having dedicated systems to host the ends of the CA. A good idea would be to place a dedicated Exchange Server 5.5 server that hosts no mailboxes in every site in which CAs terminate. You don't have to buy 23 new servers if you have 23 sites. You can use existing servers—maybe your current site bridgeheads or connector servers. Similarly, you can apply the same logic to the AD servers, but you need only one such dedicated server here because AD information is read/writeable anywhere in the forest, unlike Exchange Server 5.5 in which DS containers are read-only outside their home site.

However, maybe you don't need to check for synchronization with such frequency. You could just use the Selected times setting and initiate synchronization for a short time every hour or so or at particular times of the day.

Alternatively—and perhaps the most attractive option if you need to have synchronization occurring regularly—you can tune the frequency of synchronization. You can define the default number of seconds to wait between synchronization cycles by changing a Registry setting. To the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSADCParameters Registry key, add the Synch Sleep Delay DWORD value and set the value to the number of seconds you want Exchange to wait between replication cycles. For example, you can modify the value of this key to a setting of 300 seconds, which would yield a more palatable 5 minutes between synchronization actions, rather than the more aggressive default value.

5. Native Mode Win2K Domains Work Best
Let's review some fundamentals. A Win2K domain is in native mode if it contains only Win2K domain controllers. As long as you meet this requirement (i.e., no Windows NT 4.0 BDCs in a Win2K domain), you can have any mix of Win2K and NT 4.0 member servers in that domain. A Win2K domain is in mixed mode if it contains any NT 4.0 domain controllers.

Exchange 2000 works best if you can have most (if not all) of your Win2K infrastructure in place in native mode rather than mixed mode. With respect to the ADC, native mode is important for the synchronization of certain types of Exchange Server 5.5 DLs.

When the ADC synchronizes an Exchange Server 5.5 DL over to the AD, it always creates a mail-enabled universal distribution group as the synchronized object. Usually this object isn't a problem because Win2K has no restrictions against having universal distribution groups in a mixed mode domain.

But the purpose of the Exchange Server 5.5 DL becomes important here. If you were using the DL in Exchange Server 5.5 simply as a means of mail-address expansion, then you can continue with the same model, using a mail-enabled universal distribution group in Win2K. However, many organizations have other uses for the Exchange Server 5.5 DL, such as using DLs to enforce permissions to the public folder tree structure. Instead of assigning permissions to individual mailboxes, administrators use a DL in the ACL on the public folder to assign the permissions and add people to or remove them from the appropriate DL. This model works well and lends itself to a more efficient management technique.

But here's the problem. To implement the same model in Exchange 2000, you have to use ACLs on the public folders that relate back to Win2K groups. Win2K offers two types of groups—distribution groups and security groups—which can exist in different modes—domain local, domain global, or universal.

You can't use distribution groups in ACLs because they aren't security principals: that is, they don't have a SID value associated with them in AD. Security groups, however, are security principals and are designed specifically for use in ACLs. The ADC creates universal distribution groups (groups that are visible across all domains in the forest and can have membership drawn from any domain in the forest) because these groups represent the most flexible group objects. (DL membership in Exchange Server 5.5 might have membership drawn from anywhere in the organization, and in Win2K, these user objects might be scattered across many domains.)

A problem arises because the ADC creates universal distribution groups and because you can't use this type of group to enforce permissions on public folders. Fortunately, Exchange 2000 automatically converts universal distribution groups to universal security groups under three circumstances:

This conversion process takes place only if the universal distribution group already exists in a native mode domain. If the universal distribution group is in a mixed mode domain, no conversion takes place. Similarly, Exchange 2000 converts to universal security groups only those universal distribution groups that are used to give read permission to public folders; Exchange 2000 ignores any other universal distribution groups that are used simply for mail expansion.

Therefore, if you want to host universal security groups, you must make sure that the CA that you use is homing them into a native mode domain. The latest version of the ADC (i.e., the version shipping on the Exchange RC2 kit) reminds you of this requirement as you configure the agreement, as Figure 6 shows.

You need to think carefully about the management of these groups. Empowering end users with management of universal distribution groups to control mail expansion is one thing, but letting users meddle with universal security groups and control who can access various areas of public folder information is completely different. Modifying this kind of membership information is a role reserved to public folder administrators.

Knowledge Is Power
Don't get me wrong: I think the ADC is just great. It's a powerful tool that does a great job of facilitating coexistence between Exchange 2000 and Exchange Server 5.5. In addition, you can use it in other innovative ways to provide interorganizational directory synchronization. Greg Dodge, "Exchange Server 5.5 Interorganizational Solutions," page 12, explains this technique.

However, the ADC isn't a straightforward tool. Its power stems from its sophistication, and that sophistication means that you have to treat it with respect. If you want to have a successful Exchange 2000 deployment, you must get to know exactly how the ADC works. Build a test lab that mirrors your production environment, and keep on testing and retesting until everything makes sense to you.

I've outlined just a few of the tricky features I've found in the ADC. If you don't find more sweet spots, chances are you're missing something.