16.3 Exchange 5.5 and the Active Directory Connector

A lot of companies that are migrating to Exchange 2000 had Exchange 5.5 deployed previously. To help with the transition process, Microsoft created the Active Directory Connector (ADC), which allows you to migrate at your own pace while maintaining both environments.

The ADC is comprised of a service that does the work and an MMC console to manage the service. While the console can be installed on any client or server, the ADC service has to be installed on a DC for it to work.

To support connection to the ADC, you will need Microsoft Exchange 5.5 Service Pack 1 or above.

When you install the ADC for the first time in a forest, it extends the schema to include new Exchange objects and attributes, as well as modifying existing Active Directory objects to include new Exchange-relevant attributes. The Exchange Schema is also modified if you intend to replicate Active Directory data to Exchange. For example, the User class object in the Active Directory Schema is directly modified to include three Exchange-relevant auxiliary classes in the auxiliary class attribute: msExchMailStorage, msExchCustomAttributes, and msExchCertificateInformation. Auxiliary classes and schema are discussed more fully in Chapter 4.

Once the Active Directory schema is extended, Active Directory then can hold mail attributes for groups, users, and contacts just as the Exchange directory can. This means that the ADC now can replicate data bidirectionally, knowing that either end can store the same data. This allows you to run the ADC in one of three ways:

From Active Directory to Exchange

Every new creation of a user, distribution group, security group, or contact object that is mail-enabled in a designated Organizational Unit will be copied over to a designated Recipients container on Exchange. Every change to the attributes of an existing mail-enabled object will also be passed. Deletions also can be synchronized.

From Exchange to Active Directory

Every new creation of a user, mailing list, or contact object in Exchange automatically creates a corresponding user account in a specified Organizational Unit in Active Directory. Attribute changes also get passed, as do deletions.

Bidirectional replication

Changes at either end get replicated over to the other system.

If you choose to manage one-way replication, you must appreciate that you can update the details only for those objects on the one-way source directory from that time on. If you were to update the target directory, the changes you made could potentially be erased during the next update as the system realizes that the target is no longer in synchronization with the source. To fully appreciate this and see why bidirectional replication does not necessarily help you here, see the later Section 16.3.2 and Section 16.3.3.

There are other implications that need to be understood for these scenarios. When passing information from Active Directory to Exchange, for example, you must designate a set of specific Organizational Units that will contain the objects to be replicated. Any Organizational Units that you do not list will never have objects replicated, even if they are mail-enabled objects.

Once the ADC is installed, the Active Directory Users and Computers MMC has three extra property pages available to it. Two of these pages are visible only if you choose the Advanced option from the View menu. One word of warning: to see the extra pages in the Active Directory Users and Computers MMC on any server or workstation, you must have the ADC MMC installed onto that client first. Installing the MMC part of the ADC onto a client configures the Active Directory User and Computers MMC with the extra snap-in options for these pages.

We'll now take a look at how to configure the ADC for your use and follow on with how to mail-enable a user using the GUI and ADSI.

16.3.1 Configuring the ADC

Once you've installed the ADC, you need to designate a DC to hold what's known as a connection agreement. This agreement is an Active Directory msExchConnectionAgreement object that will hold all the information relating to the replication of the data you require. Specifically, when you set up an agreement, it adds an item to a part of the Configuration Naming Context with a path similar to this:

cn=My Connection Agreement, cn=Active Directory Connections, cn=Microsoft Exchange, 
cn=Services, cn=Configuration, dc=windows, dc=mycorp, dc=com.

The agreement stores all the data as attributes of the agreement object itself. Attributes hold information such as which direction replication will take place, when it will take place, what parts of Active Directory or Exchange actually hold the objects that you wish to replicate, and so on. For example, the attribute that holds Active Directory Organizational Units to replicate to Exchange is known as the msExchServer1ExportContainers attribute. Figure 16-1 shows a sample connection agreement running on a DC called Mint and connecting to an Exchange server called Sumac.

Figure 16-1. A connection agreement

If you right-click the agreement in the display pane, you can replicate the agreement immediately. You also can create new agreements from here as well.

If you have more than one Exchange site or multiple Windows 2000 domains that you wish to replicate to or from, you need more than one connection agreement. Similarly, if you have only one Exchange server, but you need to replicate differently for various parts of the service (e.g., the Finance Organizational Unit replicates once nightly to an Exchange container, the Sales Organizational Unit replicates hourly to an Exchange container, but the Marketing Exchange container replicates every 15 minutes back to Active Directory), you will need more than one agreement (in this case three).

When you set a connector up and try to replicate objects and attributes back and forth, it's not surprising that there might be a few problems at first while you begin to understand how things work. To help with this, you can open up the properties of any connection agreement and specify a set of logging levels for various aspects of the agreement. Figure 16-2 shows these.

Figure 16-2. Diagnostic logging for the connector

When you select a logging level, events are logged to the event log. The highest level produces copious amounts of information and thus is very useful when debugging. When we go to create a new connection agreement from the ADC MMC, seven property pages are available. We've had a lot of personal experience with these pages, so we'll try to help you understand them better. The first page that appears is shown in Figure 16-3.

Figure 16-3. Properties of a new connection agreement

The agreement needs a name, which is what the screen is prompting for. The agreement is currently unidirectional from Exchange to Active Directory, and the ADC service is running on the DC called Mint at present. Depending on the replication direction that you choose, the From Windows and From Exchange tabs will be modified. Having typed in the name, we then need to tell the ADC what server is hosting the Exchange services and what server is hosting the ADC service. We do that from Figure 16-4 which is the Connections property page.

Figure 16-4. Connections property page

Here Mint, a DC in the domain CFS, is using Windows Challenge/Response authentication and connecting to the Exchange server Sumac, also in the CFS domain, as the Administrator user from the CFS domain. Any account can be used for connection; we've just chosen the standard account here for the test domain. The only requirement is that the account has full privilege in both directions to be able to replicate and update the required databases. Once this page is completed, we need to consider when we want the agreement to run. We do this from the Schedule property page shown in Figure 16-5.

Figure 16-5. Schedule property page

Figure 16-5 appears to show that we can specify the replication interval in 15-minute or hourly cycles. In fact, this isn't the case. While this screen allows you to see a weekly replication cycle in 15-minute or hourly slots, replication will occur once during every 15-minute slot. Figure 16-5 shows a replication schedule from 8 A.M. to 10 P.M. This means that replication will occur every 15 minutes between 8 A.M. and 10 P.M., i.e., 56 times. If we want the replication to occur once an hour, the only recourse is to switch to a 15-minute view and highlight the 15-minute time period when we want replication to take place. For example, we could switch to the 15 minute view and choose 08:45-09:00, 09:45-10:00, 10:45-11:00, and so on, making sure that no other 15-minute slots were enabled.

While we have chosen to replicate at the selected times on this screen, there are two other options available. The first is never to replicate the agreement. If you ever need to stop replicating this agreement, this is where you come to disable replication. The option called Always forces the agreement to constantly replicate with almost no breathing space. Almost as soon as the agreement has finished replicating, it starts the replication cycle again. It is unlikely to be replicating a significant amount of data each time the agreement replicates, as there will have been so little time since the previous cycle. However, one or both databases will still be scanned to see whether any updates have occurred since last time, so it is important to realize that turning this on will produce a performance hit, however small. Only you will know how much traffic is likely to be replicated between the two databases for your organization, so testing is the only way to see if there is a problem with turning this setting to Always.

The last checkbox is very useful in fully updating one database or another, and we used it most during testing of the ADC. If you choose to replicate the entire directory, every object in the target is fully updated by every object in the source. But hang on, you may be thinking, if all the items are replicated, what's the point in replicating the whole lot again? Consider that you're setting up the ADC on a new site, replicating from Exchange to Active Directory, and want to make sure that everything works correctly when the data is replicated to Active Directory. To that end, you decide to test-replicate a number of the Exchange Recipients containers to one Active Directory test Organizational Unit. Replication goes well the first time, but you want to do some more tests. You empty the test Organizational Unit of users in Active Directory and then open up the agreement to replicate the entire directory the next time replication takes place. You then can go back to the main agreement, Figure 16-1, and right-click the agreement to select Replicate Now. Every object is immediately replicated again, just as if this were the first time that the agreement had ever been replicated.

Figure 16-6 shows the property page detailing the settings for replication from Exchange as the source to Active Directory as the target. You can specify for this agreement that mailboxes, custom recipients, and distribution lists will be copied from a series of Recipients containers to a single Organizational Unit in Active Directory.

Figure 16-6. From Exchange property page

Remember that you can have only one target for either direction of a connection agreement. If you want to replicate distribution lists from the Recipients container(s) to a specific Organizational Unit, custom recipients from the Recipients container(s) to another Organizational Unit, and mailboxes to a third Organizational Unit, you need three agreements. Each agreement would replicate one type of source object from multiple recipient containers to a single target Organizational Unit.

The property page relating to replication in the direction from Active Directory to Exchange is very similar, as shown in Figure 16-7. Here, instead, you specify multiple Organizational Units going to a single Recipients container. Again, users, contacts, and groups can be specified as being copied during replication. In Figure 16-7, only users are being copied.

Figure 16-7. From Windows property page

The checkbox at the bottom of the screen is used to indicate whether you wish to use or ignore the Access Control Lists that are defined on user, contact, and group objects to filter the items that get replicated. While items that are not mailbox- enabled are never copied, neither are items whose ACL indicates that they should be filtered out if this checkbox is cleared.

Figure 16-8 indicates what should happen when you replicate through a deletion in either direction. When an Active Directory user is deleted, her mailbox can be removed immediately. Alternatively, the information can be stored in a Comma-Separated-Value (CSV) file for later action using the Bulk Import command in the Exchange Administrator or via a script. If you choose the CSV option, the system sets the Hide Mailbox flag on the object and writes information to a file in this location: ADC Path\Connection Agreement Name\LocalToRemote\lra.csv.

Figure 16-8. Deletion property page

The converse also is true. When an Exchange mailbox is deleted, Active Directory users can also be immediately deleted or the information kept in a CSV for later action. In the latter case, the system sets the Mail-Enabled attribute to False and records the deletion information into the file: ADCPath\Connection Agreement Name\RemoteToLocal\lra.csv. If you want to use this CSV file to delete the users later, the file first has to be converted to an LDAP Data Interchange File Format (LDF), using the LDIF Directory Synchronization Bulk Import/Export tool found on a DC: %systemroot%\system32\ldifde.exe. The option that you choose depends on your own environment and whether you wish to keep users that have no mailbox or mailboxes that have no corresponding user for a time period to comply with internal regulations.

The last property page, Advanced, shown in Figure 16-9, is a selection of items that don't fit anywhere else.

Figure 16-9. Advanced property page

There are certain times when so many changes have been made and need replicating in a single run that the memory needed to store and send them is too large for the DC to cope with. To combat this before it becomes a problem, the ADC can page results, so that the updates are placed on pages, each holding a certain set of updates. Each page is sent to Exchange, then the system waits for the page to complete updating before continuing. This slows down the process slightly but is much less likely to impede or cripple any systems. The Advanced page allows you to specify the number of entries that you wish to hold for each direction. In normal operations, there shouldn't be any need to alter these values. However, if you do have a lot of memory and believe that your system can cope with hundreds or thousands of updates in one go, you can modify these values.

The simple Primary Connection Agreement checkbox tucked away here belies its importance. A primary connection agreement is one that can create objects in a target directory service; a secondary connection agreement can update only existing objects in a directory service. Here this agreement is a primary agreement, so it has full authority. We can create a number of secondary agreements on other DCs if we wish to enable fault tolerance and load balancing.

Finally, when a mailbox is replicated without an associated user, the system allows one of three options. A windows contact can be created, a disabled user can be created, or a fully specified user can be created and enabled. This covers the fact that certain mailboxes may be placeholders for external contacts that do not have associated user accounts, and the ADC needs to know what you want to do with these sorts of replicated items.

The limitations of the ADC are that it is not possible from looking at the set of multiple agreements to see which agreements go in which direction and which containers are copied over in each direction. We think it would have been more useful to have a second tool that acts almost as a map, which says that agreement A replicates mailboxes only from these Active Directory Organizational Units to this Exchange container, and agreement B is bidirectional and replicates all objects in this single Exchange container to this Active Directory Organizational Unit, and vice versa. For complex Active Directory and Exchange organizations that will be slowly adopting Active Directory and Exchange 2000, this would have been a useful addition. The only way to do this at present is to somehow incorporate this information into the name of the agreement. That's the only gripe we have, and compared to the usefulness of the tool, it's a very small one indeed.

16.3.2 Mail-Enabling Objects via the GUI

Now that the ADC is installed and configured, and the schemas have been modified, you can run the Active Directory Users and Computers tool on any client that has Active Directory Connector Management MMC installed on it and see extra property pages relating to the Exchange attributes of users. You will need to enable Advanced view from the View menu of the MMC to see all three pages.

The extra property pages are not visible from a client that does not have Active Directory Connector Management MMC installed on it.

Figure 16-10 shows the Exchange General tab, the first of the three new property pages available to you. It allows you to configure various options that you used to need the Exchange Administrator program to do directly. The property page shown in Figure 16-11 allows you to set new email addresses in any of the available types that Exchange supports.

Figure 16-10. Exchange General property page

Figure 16-11. Exchange E-mail Addresses property page

The page shown in Figure 16-12 allows you to configure the less used and more advanced settings.

Figure 16-12. Exchange Advanced property page

If we now go back to the Exchange General property page and click on the Storage Limits button, the screen shown in Figure 16-13 appears. We are not going to go through every option in this manner, but Figure 16-13 serves to highlight an example of when you can get into problems.

Figure 16-13. Storage Limits options

Any Exchange mailbox can have a set of three custom limits for the private information store, the user's own mailbox. The Exchange service as a whole can also have default limits defined; any users who have no custom limits defined get the defaults. These limits cause warnings to be issued to transgressors on a daily basis by default based on whether certain conditions have been met. In addition, as soon as the user exceeds the Prohibit Send limit, he can send mail no more. When he reaches the Prohibit Receive limit, he cannot receive mail any more, and all further mail to that mailbox is returned to the sender. Figure 16-13 shows that for this particular Active Directory user, the "Use information store defaults" checkbox is not checked but cleared. This means that this user is not using the Exchange information store default limits and instead will use the values indicated on the form. But hang on; there are no values on the form. None of the next three checkboxes been set. This means that you've told the Exchange system not to use its default limits and not to set any custom limits for this user either. In other words, the user has no limits defined for his mailbox. On the second part of the form, you can see that the Deleted Item Retention time, how long the system keeps messages after they have been deleted by the user, is set to the defaults.

It is now possible to manage a lot of the Exchange user functionality from these property pages. If you are used to managing this data on Exchange, and your ADC connection agreement(s) state that data is being transferred one way from Active Directory to Exchange, you need to get into a new mindset of managing the data on Active Directory now. Otherwise, any data that you change on the Exchange server has the potential to be wiped out during two specific replication cycles:

• When any change is made to the same options for the user in Active Directory

• When the connection agreement is told to replicate all data during the next replication cycle

Of course, this also applies to data being replicated one way from Exchange to Active Directory.

If you have an agreement that replicates only one way (Active Directory to Exchange or Exchange to Active Directory), you should not modify the data on the replication target directory directly. This is very bad practice and liable to cause problems. Instead, you should modify the data on the replication source directory and let the data replicate across naturally or force a replication. This ensures the data in both directories stays in synchronization. If you were to modify only the target directory, there is the potential for data from the source directory to overwrite any changes you made to the target directory at a later point in time.

16.3.3 Why Bidirectional Replication May Not Solve Your Problems

While you may think that bidirectional replication will solve the problems, in fact, it probably won't unless your Active Directory Organizational Unit structure tends to mirror the setup of your Exchange Recipients containers. While bidirectional replication appears to specifically link up individual objects in Active Directory with objects in the Exchange directory—so that whenever a change is made in one, the corresponding change is made in the other—this isn't exactly true. In fact, as shown earlier, to replicate from Active Directory to Exchange, you have to designate one or more Organizational Units in Active Directory as the source and only one Recipient container in Exchange as the target. Then the data can be replicated from Active Directory objects in the source Organizational Units to the target container in Exchange. If you wish to have data going from Exchange to Active Directory, you have to specify one or more Recipient containers in the Exchange directory as the source and one Organizational Unit in Active Directory as the target. The point is that you do not have a one-to-one mapping of the containers; you have a many-to-one mapping.

So no matter which direction one-way replication takes place, with only one target in either connection agreement we have the following problem, best shown as an example. Let's say that we have Test as the only Organizational Unit as the source in the one-way connection agreement and a Recipients container as the target. If we want Exchange modifications to replicate back to Active Directory, then with a one-to-one mapping existing between containers in the agreement, we can simply set the agreement up bidirectionally. But what would happen if we add a second Organizational Unit to the one-way agreement, called Finance? Now a Test user's data gets replicated over to Exchange as before. But when you want any changes to that user's Exchange mailbox replicated back and set the agreement up bidirectionally, you have to tell the system that the single Recipients container that receives updates from Test and Finance now has to replicate its data back to one and only one Organizational Unit. This is a severe problem.

The only solution is to mirror the Organizational Unit structure that you use in your connection agreement with the same structure of Recipients folders in Exchange. To get proper bidirectional replication, we would need to set up two Exchange recipients containers that represented Test users and Finance users and then set up multiple one-to-one connection agreements.

Obviously, when Exchange 2000 comes along and uses Active Directory as its directory service rather than its own Exchange directory service, there will no longer be any need to worry about the ADC and replication of data.