Understanding and Deploying Exchange 2000 Active Directory Connector

Understanding and
Deploying
Exchange 2000 Active
Directory Connector
Graham McIntyre, Paul Bowden,

Bryan Hunt
Understanding and
Deploying
Exchange 2000 Active
Directory Connector
Graham McIntyre, Paul Bowden,

Bryan Hunt
Applies To: Exchange 2000 Server SP3

Copyright
Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless
otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events
depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo,
person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in
this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not
give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2003 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Outlook, Windows, Windows NT and Windows Server are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Acknowledgments
Project Editor: Lindsay Pyfer

Editors: Lindsay Pyfer, Cathy Anderson, Alison Hirsch, Diane Forsyth
Technical Reviewers: Brad Owen, Harvey Rook, Neil Shipp, ADCTalk
Artist: Kristie Smith
Production: Joe Orzech, Sean Pohtilla
Table of Contents
Understanding and Deploying Exchange 2000 Active Directory
Connector....................................................................................1
Understanding and Deploying Exchange 2000 Active Directory
Connector...................................................................................iv
Introduction.................................................................................5
Overview...................................................................................5
What Will You Learn from This Book?....................................... ..................5
Who Should Read This Book?.............................................................. .......6
What Terminology Is Used in This Book?....................................... .............6
How Is This Book Structured?........................................ ............................7
Chapter 1...................................................................................10
What Is Active Directory Connector?.......................................10
What Does ADC Consist Of?................................................................ .....10
Versions of ADC............................................................... ........................10
Exchange 2000 and Active Directory......................................... ..............11
Connection Agreements............................................ ..............................12
Using a Single One-Way Connection Agreement to Export the Entire
Organization......................................................................... ...................12
Configuration Connection Agreements and the Site Replication Service. 13
Chapter 2..................................................................................16
Deployment Planning .............................................................16
Questions to Ask Before Deploying Active Directory Connector...............16
How Many Exchange Sites Does the Organization Have?...................16
How Many Active Directory Domains Are Being Planned?..................17
Will Master/Account Domains Be Upgraded Before ADC Is Deployed?
........................................................................... ...............................18
How Is the Container Structure in the Existing Exchange System
Defined?......................................................................................... ....20
Chapter 3...................................................................................22
Technical Planning...................................................................22
Exchange Server Versions........................................ ...............................22
Schema Updates................................................................................... ...22
Installing Exchange Server 5.5 on a Windows 2000 Server.....................23
Where Should ADC Be Installed?.............................................................. 24
Deploying Multiple ADC Servers.................................... ..........................25
ii Understanding and Deploying Exchange 2000 Active Directory Connector
LDAP Ports and Protocols....................................................... ..................25
Planning Your Connection Agreements....................................................26
Scenario 1: Two Active Directory Domains, Three Exchange Sites.....26
Scenario 2: Simple Mapping...................................................... .........30
Scenario 3: One Domain, Multi-Site, Split Containers.........................32
Public Folder Connection Agreements..................................................... .46
Chapter 4...................................................................................48
Resource Usage.......................................................................48
Server Resources Consumed by ADC................................................ .......48
Network Consumption.................................................. ...........................48
Using the Site Replication Service with Exchange 2000 Server...............50
Downstream Replication Traffic.............................................................. ..51
Chapter 5...................................................................................52
How Active Directory Connector Works...................................52
Initial Replication................................................................ .....................52
Detecting Changes in the Exchange Directory..................................... ....52
Detecting Changes in Active Directory....................................................53
Object Class Mapping and Attributes....................................... ................53
Duplicate Object Detection........................................................... ...........55
Schema Discovery................................................................ ...................56
Chapter 6 ..................................................................................57
How to Implement Active Directory Connector.......................57
ADC Installation..................................................................... ..................57
Configuring Attribute Replication and Object Matching...........................58
Creating Connection Agreements........................................ ....................60
Creating Public Folder Connection Agreements.......................................69
Chapter 7...................................................................................73
After Installation......................................................................73
How Active Directory Connector Finds, Matches, and Links Objects........73
Replicated Objects in Active Directory...................................... ...............75
Replicated Objects in the Exchange Directory.........................................77
Primary vs. Non-Primary Connection Agreements...................................78
Chapter 8...................................................................................81
Troubleshooting.......................................................................81
Event Logs................................................................................. ..............81
Event Logging................................................................ ....................82
Table of Contents iii
Directory Inconsistencies................................................................ .........83
Additional Troubleshooting.................................................. ...............83
Best Practices When Using Diagnostic Logging..................................84
Failure to Write to an Object........................................................... ....84
Failure to Match an Object.................................. ...............................84
Troubleshooting Failures-to-Match.............................................. ........85
Failed.ldf File............................................................... .......................85
Ldif.err File.............................................................. ...........................85
Chapter 9...................................................................................86
Advanced Configuration..........................................................86
Tools............................................................................ ............................86
Changing the LDAP Search Filter Rule............................................... .......87
Changing the Attribute Mapping Table........................................... ..........88
Appendixes
..................................................................................................89
Appendix A ...............................................................................90
Schema Updates Made by the Exchange 2000 Server Active
Directory Connector................................................................90
Appendix B................................................................................94
Manipulating Mailbox to Active Directory Account Replication 94
Appendix C ...............................................................................95
Attributes of a Connection Agreement....................................95
General Attributes....................................................................... .......95
Windows Server-Specific Attributes............................................ ........97
Exchange Server-Specific Attributes..................................................99
Appendix D..............................................................................102
ADC Matching Rules..............................................................102
Format of ADC Matching Rules........................................... ..............104
Modifying Object Matching Rules.....................................................105
Appendix E..............................................................................107
Viewing and Modifying the Attribute Mapping.......................107
Changing the Attribute Mapping Rules Manually...................................109
Syntax of Schema Map Files........................................................ .....109
Validating Object-Class Matches......................................................113
Unmerged Attribute Cleanup............................................. ....................113
iv Understanding and Deploying Exchange 2000 Active Directory Connector
Specifying an Authoritative Attribute Source.........................................114
Appendix F...............................................................................115
Move Server Wizard..............................................................115
Appendix G..............................................................................117
Replicating Distribution Lists and Groups..............................117
Exchange 5.5 Distribution Lists........................................... .............117
Windows NT 4.0 Groups ............................................ ......................117
Windows 2000 Groups ...................................... ..............................117
Distribution Groups vs. Security Groups...................................... .....118
Windows 2000 Domain Modes and Group Restrictions.....................118
Active Directory Connector and Distribution Lists............................118
Access Control Lists and Groups......................................................118
Token Augmentation........................................... .............................119
Converting Universal Distribution Groups to Universal Security Groups
......................................................................... ...............................119
Disconnecting User Domain Upgrades from Exchange 2000
Deployment.......................................................... ...........................119
Added Complexity from Disabled Users and Mailbox Rights.............120
Moving Groups from a Mixed-mode Domain to a Native-mode Domain
......................................................................... ...............................120
Appendix H..............................................................................122
Four Test Topologies..............................................................122
Appendix I................................................................................126
Inter-Organization Connection Agreement............................126
Arbitrating Changes....................................................................... ........126
Replication Loop Prevention.............................................. ...............128
Additional Registry Keys for ADC................................. ..........................129
Appendix J................................................................................131
Additional Resources.............................................................131
Technical Articles.............................................. ...............................131
Resource Kits....................................................... ............................131
Microsoft Knowledge Base Articles........................................ ...........131
I N T R O D U C T I O N
Overview
Organizations deploy Active Directory Connector (ADC) for four main reasons:
• To take advantage of the rich information about users in the Microsoft® Exchange directory
by replicating it (rather than re-entering it) to the Microsoft Active Directory® directory
service (replicating may be either for Active Directory testing purposes or for the production
environment).
• To replicate existing Microsoft Exchange Server version 5.5 directory data to Active
Directory so that new third-party applications can take advantage of it.
• To create an environment in which both Active Directory and the Exchange directory can be
managed from one management application.
• To make it possible to deploy Exchange 2000 Server while coexisting with the installed
Exchange environment.
If any of the preceding reasons apply to your organization, use this book to plan and carry out
your deployment of ADC.
If none of these reasons apply to your organization, you may not need to deploy ADC. For
example, Exchange 5.5 can run efficiently without ADC, even when the domains and servers
have been upgraded to Microsoft Windows® 2000 Server and Active Directory. Active Directory
continues to provide authentication services for Exchange just as Microsoft Windows NT®
Server version 4.0 did, and Microsoft Outlook® continues to use the directory service in
Exchange.
This book provides an example of an implementation of ADC, including screen shots.
Note
The information in this book is based on Microsoft Windows 2000 Server Service
Pack (SP) 2 and Microsoft Exchange 2000 Server SP2.
What Will You Learn from This

Book?
This book provides detailed answers to the following questions:
• What is ADC?
6 Understanding and Deploying Exchange 2000 Active Directory Connector
• What should I consider before implementing ADC?
• How does ADC work?
• How do I install ADC?
• How do I configure connection agreements?
• How does ADC match objects?
• How does the schema map work?
• How do object matching rules work?
• What is the difference between recipient, public folder, and configuration connection
agreements?
• How do I troubleshoot Active Directory Connector?
Who Should Read This Book?

This book is intended for Active Directory and Exchange administrators who are responsible for
deploying Exchange 2000. This book provides both high-level and detailed information about
deploying Active Directory Connector to facilitate a migration from Exchange 5.5 to Exchange
2000 Server.
What Terminology Is Used in

This Book?
To understand this book, make sure you are familiar with the following terms, some of which
were taken from the Distributed Systems Guide volume of the Window 2000 Resource Kit
(http://go.microsoft.com/fwlink/?LinkId=6545):
access control entry (ACE)
An entry in an access control list (ACL) containing the security ID (SID) for a user or group
and an access mask that specifies which operations by the user or group are allowed, denied,
or audited.
access control list (ACL)
A list of security protections that apply to an entire object, a set of the object's properties, or
an individual property of an object. There are two types of access control lists: discretionary
and system.
access token
A data structure containing security information that identifies a user to the security
subsystem on a computer running Windows 2000 or Microsoft Windows NT®. Access
tokens contain a user's security ID, the security IDs for groups that the user belongs to, and a
list of the user's privileges on the local computer.
Introduction 7
Config CA
A unique instance of a connection agreement, known as a configuration connection
agreement or Config CA. Config CAs are responsible for replicating objects from the
configuration naming context, such as server objects and connector objects. Unlike standard
connection agreements, Config CAs are configured automatically by Exchange Server rather
than having to be instantiated manually. Also, the Config CA is always between Active
Directory and the Exchange Site Replication Service (SRS) rather than between Active
Directory and Exchange 5.5.
connection agreement
The mechanism by which you establish a relationship between an existing Exchange site and
Active Directory. A connection agreement holds information, such as the server names to
contact for replication, object classes to replicate, target containers, and the replication
schedule.
permission
A rule associated with an object to regulate which users can gain access to the object and in
what manner. Permissions are granted or denied by the object's owner.
security descriptor
A data structure that contains security information associated with a protected object.
Security descriptors include information about who owns the object, who may access it and
in what way, and what types of access will be audited.
security ID (SID)
A data structure of variable length that uniquely identifies user, group, service, and computer
accounts within an enterprise. Every account is issued a SID when the account is first
created. Access control mechanisms in Windows 2000 identify security principals by SID
rather than by name.
security principal
An account-holder, such as a user, computer, or service. Each security principal within a
Windows 2000 domain is identified by a unique security ID (SID). When a security principal
logs on to a computer running Windows 2000, the Local Security Authority (LSA)
authenticates the security principal's account name and password. If the logon is successful,
the system creates an access token. Every process executed on behalf of this security
principal will have a copy of its access token.
For more information about Microsoft Windows 2000 security concepts, see "Access Control" in
Chapter 12 of the Distributed Systems Guide volume of the Microsoft Windows 2000 Server
Resource Kit (http://go.microsoft.com/fwlink/?LinkId=6545).
How Is This Book Structured?

This book is divided into nine chapters and ten appendixes.
Chapter 1, "What is Active Directory Connector"
This chapter describes Active Directory Connector, its purpose, its features, and how they
interact to implement Active Directory in organizations that have already deployed
Exchange 5.5 and to achieve co-existence between Exchange Server 5.5 and Exchange 2000
Server.
Chapter 2, "Deployment Planning"
This chapter lists the questions that you should ask before you deploy ADC in your
organization and the reasons for asking these questions.
Chapter 3, "Technical Planning"
This chapter describes factors that you need to consider when you plan your ADC
deployment. These factors include server version, schema updates, compatibility with
Windows 2000 Server, where to install ADC, what you need to know before deploying
multiple ADC servers, LDAP ports and protocols, and how to plan connection agreements.
Three detailed scenarios are presented to illustrate thorough planning of connection
agreements. Information about the public folder connection agreement is also included.
Chapter 4, "Resource Usage"
This chapter describes the server and network requirements for handling the resources that
are consumed when ADC is running, and factors that affect how many resources are
consumed.
Chapter 5, "How Active Directory Connector Works"
This chapter describes the process by which ADC synchronizes Windows 2000 Active
Directory with the Exchange 5.5 directory, including discussions of the initial replication,
how changes are detected in the Exchange directory and Active Directory, how different
classes of objects are mapped between the two directories, what happens when a duplicate
object is detected, and how schema discovery accommodates discrepancies between systems
with the Exchange 5.5 directory and Active Directory.
Chapter 6, "How to Implement Active Directory Connector"
This chapter includes step-by-step procedures for implementing ADC, including illustrations
of the user interface (UI).
Chapter 7, "After Installation"
This chapter describes how ADC finds, matches, and links objects, how Active Directory
and the Exchange 5.5 directory handle replicated objects, and the two kinds of primary
connection agreements.
Chapter 8, "Troubleshooting"
This chapter describes how to change diagnostic logging options, lists the different ADC
event logging messages and logging levels, provides information about managing directory
inconsistencies, and lists common issues that may arise after the ADC has been implemented
along with tips and tricks for resolving these issues.
Chapter 9, "Advanced Configuration"
This chapter describes advanced customizations that you might need to make to the ADC in
deployments with a very complex Exchange site or Active Directory topology, and the tools
you use to make the changes.
Appendix A, "Schema Updates Made by the Exchange 2000 Server Active
Directory Connector"
This appendix shows the schema updates that are applied to an Exchange 5.5 site when an
ADC is installed and configured to write to that site, or when a server is upgraded to
Exchange 5.5 SP3.
Introduction 9
Appendix B, "Manipulating Mailbox to Active Directory Account Replication"
This appendix describes what to do with the multiple mailboxes with the same associated
Windows NT account that are allowed in Exchange 5.5 but are not allowed in Active
Directory.
Appendix C, "Attributes of a Connection Agreement"
This appendix lists the three groups of attributes that are contained in a connection
agreement and describes each of these attributes.
Appendix D, "ADC Matching Rules"
This appendix describes the matching rules ADC uses when replicating objects, the format
of the matching rules, and how to modify them.
Appendix E, "Viewing and Modifying the Attribute Mapping"
This appendix describes the location of the ADC schema map, its attributes, and what you
need to know to view or edit attribute mapping.
Appendix F, "Move Server Wizard"
This appendix describes how to avoid or rectify adverse effects that occur if you use the
Exchange 5.5 Move Server Wizard after ADC has been deployed.
Appendix G, "Replicating Distribution Lists and Groups"
This appendix describes the different types of lists and groups that are used in Exchange 5.5
and Exchange 2000, how they are affected by ADC, and includes a procedure for moving
groups from a mixed-mode domain to a native-mode domain.
Appendix H, "Four Test Topologies"
This appendix describes the four basic topologies for testing Universal Security Groups and
Public Folder Access Control Lists, and explains the elements that differentiate each
topology from the others.
Appendix I, "Inter-Organization Connection Agreement"
This appendix describes the inter-organization connection agreement option that can be set
on the Advanced tab of a connection agreement properties sheet and what happens if you do
not select this option. This appendix also includes a discussion of how changes are arbitrated
so that they can be synchronized between directories, and a list of additional registry keys
for ADC.
Appendix J, "Additional Resources"
This appendix contains additional resources to help you maximize your understanding of the
Active Directory Connector information that is discussed in this book.
C H A P T E R 1
What Is Active Directory

Connector?
Active Directory Connector (ADC) is the component that synchronizes the Microsoft®
Windows® 2000 version of the Active Directory® directory service with the Microsoft Exchange
Server version 5.5 directory. This synchronization aids in the implementation of Active Directory
for organizations that have already deployed Exchange 5.5. ADC is a necessary component for
achieving coexistence between Exchange Server 5.5 and Exchange 2000 Server.
ADC:
• Uses the Lightweight Directory Access Protocol (LDAP) application programming interface
(API) to perform fast replication between the two directories.
• Hosts all active replication components in Active Directory.
• Only replicates objects that have changed, whenever possible, to minimize replication
traffic.
• Maintains object fidelity through replication (for example, the Active Directory Group object
maps to the Exchange Distribution List object).
• Hosts multiple connections on a single Active Directory server and manages these through
connection agreements.
What Does ADC Consist Of?

ADC is installed as an additional component, with a separate installation program from the main
Exchange 2000 setup. On installation, you will notice a new Windows service called the
MSADC. This service can be started and stopped like any other service. Also installed are a
Microsoft Management Console (MMC) snap-in and a console named Active Directory
Connector Management that you can use to configure the connection agreements between Active
Directory and the Exchange directory.
Versions of ADC
The basic replication functionality of ADC is included with Windows 2000. However, when you
install Exchange 2000, an update is installed.
Chapter 1: What Is Active Directory Connector? 11
Windows 2000 ADC

The Windows 2000 ADC, which is included with Windows 2000, replicates directory
information in Exchange 5.5 to Active Directory and vice versa. Many customers have already
invested heavily in the Exchange directory, and much of this data can be uploaded in bulk to
Active Directory, which decreases implementation time. Through synchronization, the
Active Directory administrator can also perform basic management functions for Exchange 5.5
users. The Windows 2000 ADC can only replicate the site naming context. It will synchronize
additions or modifications on Exchange 5.5 mailboxes, distributions lists, and custom recipients.
Exchange 2000 Server ADC Update

The Exchange 2000 Server ADC update is an enhanced connector included with Exchange 2000.
Whereas the Windows 2000 ADC replicates objects in the Exchange site-naming context (for
example, Recipients containers) to Active Directory, the Exchange 2000 ADC also replicates data
from the configuration naming context, thus providing support for sites that include both
Exchange 5.5 and Exchange 2000 and for downstream routing.
Exchange 2000 ADC Service Packs

Exchange 2000 Service Pack 1 (SP1) and Service Pack 2 (SP2) include an update to Active
Directory Connector. These versions of ADC include the same basic functionality as the version
originally commercially released, but with some added features. To upgrade ADC to the latest
service pack, run setup.exe from the Service Pack media and choose Reinstall.
The upgrade path between the different versions of ADC is seamless. Although it is possible to
deploy the Windows 2000 version, and then later upgrade to the Exchange 2000 version, it is
recommended that you install the latest version of ADC that is available. For example, to install
the SP2 version of ADC, you do not have to install the original version of Exchange 2000 first.
When upgrading from the Windows 2000 ADC to the Exchange 2000 ADC, additional schema
changes are made when the Exchange 2000 ADC setup program runs. For more information
about these changes, see Appendix A, "Schema Updates Made by the Exchange 2000 Server
Active Directory Connector."
Exchange 2000 and

Active Directory
Exchange 2000 no longer includes a directory service of its own; instead, it uses Active
Directory, provided by Windows 2000, for object browsing, access control, and name resolution.
For companies that have already deployed Exchange 5.5, coexistence between the Exchange 5.5
directory and Active Directory is a vital prerequisite for the Exchange 2000 upgrade process.
However, after Exchange 2000 is deployed, Active Directory becomes the global address list for
those Microsoft Outlook® messaging and collaboration client users who have their mailboxes on
Exchange 2000. Therefore, it is important for the Exchange 5.5 directory and Active Directory to
have complete information about each other.
Connection Agreements
Installing ADC on a server defines a service within Windows 2000. To establish a relationship
between an existing Exchange site and Active Directory, you must configure a connection
agreement. The connection agreement holds information, such as the server names to contact for
replication, object classes to replicate, target containers, and the replication schedule.
It is possible to define multiple connection agreements on a single ADC server, each of which
can go from Active Directory to a single Exchange site or to multiple Exchange sites. For optimal
performance, it is recommended that each ADC server manage no more than 50 to 75 individual
connection agreements, depending on the specifications of the computer and the number of
objects in each directory. In enterprise environments, you may want to deploy multiple ADC
servers to improve performance, especially when there are multiple geographic locations that
contain Exchange servers and domain controllers.
Using a Single One-Way

Connection Agreement to
Export the Entire Organization
If you are uploading existing Exchange directory data to Active Directory, you can create a single
connection agreement between Active Directory and an Exchange 5.5 server that uses the
Exchange organization as a source for replication. Because all site information from the entire
Exchange organization can be gained from any Exchange 5.5 server in the organization, all of the
objects and sites can be pulled through a single connection. The connection is defined as a one
way from Exchange agreement, allowing Active Directory data to be updated when the Exchange
directory is modified. This has a limitation, however. The highest level that can be exported on a
two-way connection agreement is the site level. If you decide to use a single one-way connection
agreement to export the entire organization, you should do so only for an initial population of
Active Directory. Exchange 2000 cannot be installed until at least one two-way connection
agreement is set up. A two-way connection agreement both reads from and writes to both
directories and, as such, can only communicate with one Exchange site.
Figure 1.1 Populating Active Directory with a one-way connection agreement
Before installing Exchange 2000, you must reconfigure the connection agreements to allow for
two-way replication for, at a minimum, the site where you are going to install the Exchange 2000
server. The mixed site needs to be removed from the list of export containers on the From
Exchange tab of the one-way connection agreement, because that site now has its own two-way
connection agreement. You can create multiple connection agreements (on the same ADC server,
if you prefer) if multiple Exchange sites exist in the Exchange 5.5 directory.
Figure 1.2 Synchronization using two-way connection agreements
Configuration Connection
Agreements and the Site
Replication Service
A Recipient Connection Agreement replicates recipient objects, such as mailboxes, distribution
lists, and contacts, between the Exchange 5.5 directory and Active Directory; however, when an
Exchange 2000 server belongs to an existing Exchange 5.5 site, configuration information must
be replicated. This replication allows the Exchange 2000 server to be represented in the
Exchange site server list so that earlier versions of Exchange can send and receive messages as
seamlessly as if the new server were running Exchange 5.5. Additionally, gateway or route
information must be replicated between the two directories to allow Exchange 2000 servers to
send messages to specialized connectors that exist on the Exchange 5.5 servers and vice versa.
All configuration information is replicated through a unique instance of a connection agreement,
which is known as a configuration connection agreement or Config CA.
Unlike standard connection agreements, Config CAs are configured automatically by Exchange
Server rather than having to be instantiated manually. Additionally, the agreement for replicating
configuration-naming context data is between Active Directory and the Exchange Site
Replication Service (SRS) rather than between Active Directory and Exchange Server 5.5. The
SRS is a component installed by Exchange 2000 Server and is similar to the Exchange 5.5
directory service, although the Name Service Provider Interface (NSPI) is disabled, so clients do
not connect directly to the SRS to perform address book operations. When an Exchange 2000
server is installed into an Exchange 5.x site, the SRS is used for intra-site directory replication
over remote procedure calls (RPCs). If an Exchange 5.5 directory-replication bridgehead server
is upgraded to Exchange 2000, the SRS provides mail-based directory replication to downstream
Exchange 5.x sites.
Config CAs are named "ConfigCA_SRSNAME", where SRSNAME is the name of the SRS with
which the Config CA is associated. You can use the Active Directory Connector Management
snap-in to view the properties of Config CAs; however, most properties are read-only and cannot
be modified. Like a standard Exchange directory service, the SRS supports direct LDAP calls
and listens on port 379 to avoid port contention with other LDAP services running on the
computer.
Figure 1.3 Exchange Server 5.5 and Exchange 2000 Server co-existence
with the Site Replication Service
After replication, all Exchange 5.x sites are represented in Active Directory as administrative
groups. Exchange 2000 servers in the administrative group are represented in the Exchange 5.x
site. Typically, there is only one Config CA and Site Replication Service per mixed site. The Site
Replication Service is on the first Exchange 2000 server installed into an Exchange 5.5 site or the
first one to be upgraded. However, additional Site Replication Services can be created in a site by
upgrading an Exchange 5.5 server that is the bridgehead of a Directory Replication Connector, or
by using Exchange System Manager to create a new Site Replication Service on an existing
Exchange 2000 server in the site.
C H A P T E R 2
Deployment Planning
Before you deploy Active Directory Connector (ADC) and its connection agreements, it is vitally
important that you consider all of the organization's business requirements to avoid problems
later on. ADC can be configured to make fundamental changes to directories (including deleting
objects). Therefore, incorrect deployment could result in destabilization of the existing
Microsoft® Exchange infrastructure.
Questions to Ask Before

Deploying Active Directory
Connector
Before you deploy Active Directory Connector, ask the questions listed in this section:
• How many Exchange sites does the organization have?
• How many Active Directory® domains are being planned?
• Will domains be upgraded before ADC is deployed?
• How is the container structure in the existing Exchange system defined?
The business sponsor, the Active Directory directory service planning team, the Exchange 2000
Server planning team, and support and administration staff should discuss these issues. The
answers to these questions will dictate how you should deploy ADC.
How Many Exchange Sites Does the

Organization Have?
Creating a deployment plan begins with an assessment of the existing environment. For starters,
how many Exchange sites are in the organization? How is the replication topology set up? In
which site(s) are you going to deploy Exchange 2000 servers initially?
Normally, it is recommended that you set up two-way ADC replication for all sites. This prevents
your having to change the ADC configuration later as you begin introducing Exchange 2000
Chapter 2: Deployment Planning 17
servers, and also ensures that any new objects, or changes to existing objects, in either Active
Directory or Exchange Server version 5.5, are replicated properly.
However, if you have a large number of Exchange 5.5 sites and you plan to deploy
Exchange 2000 one site at a time, it may be easier to set up two-way replication for the initial
sites where Exchange 2000 will be deployed, and a single one-way connection agreement from
Exchange to Windows to populate Active Directory with information from the other
Exchange 5.5 sites. When you are ready to deploy Exchange 2000 in another Exchange 5.5 site,
remove that site from the existing one-way connection agreement, and create a new two-way
connection agreement directly to that site. For an example of how to transition additional
Exchange 5.5 sites to using two-way connection agreements, see "Scenario 3: One Domain,
Multi-Site, Split Containers" in Chapter 3.
How Many Active Directory Domains

Are Being Planned?
Unlike directory services in previous versions of Exchange, Active Directory does not tie the
namespace to the directory replication model. For example, when Exchange 5.5 was deployed,
the business may have had a requirement to move users seamlessly between Exchange servers.
To meet this requirement, some customers may have deployed very wide Exchange sites that
span low-bandwidth networks. Because the Exchange site requires that every Exchange 5.5
server in the site have Remote Procedure Call (RPC) connectivity to every other Exchange 5.5
server in the site, additional management and administration challenges are produced.
Although Active Directory is far more flexible than the directory in previous versions of
Exchange in terms of namespace and the replication model, the initial release of Microsoft
Windows® 2000 requires that domain naming context replication transfers between domain
controllers occur over synchronous RPC. In some environments, this requirement of synchronous
RPC connectivity between domain controllers in a domain may result in the deployment of many
small domains. As the number of domains in Active Directory increases, the number of
connection agreements may also increase.
Another consideration for the deployment of ADC is the number of ADC servers required to
replicate the data. Although ADC can have connection agreements for multiple Active Directory
domains, the protocol used between the ADC server and the Exchange 5.5 directory is mainly
Lightweight Directory Access Protocol (LDAP) and a few RPC requests (the latter is used when
writing to the Exchange directory), and both require direct Internet Protocol (IP) connectivity.
If a global organization has offices and Exchange sites in many countries/regions, it is unlikely
that the company will deploy only one ADC server. Most companies install an ADC server in
each major geographical region, where it can be in close physical proximity to the Exchange and
Active Directory endpoints of its connection agreements. To create a mailbox in Exchange 5.5,
ADC requires LDAP connectivity to the directory and RPC connectivity to Exchange System
Attendant. To delete a mailbox in Exchange 5.5, ADC requires LDAP connectivity to the
directory and RPC connectivity to the store.
Will Master/Account Domains Be

Upgraded Before ADC Is Deployed?
Each Exchange mailbox is mapped to a primary Microsoft Windows NT® account, which is
normally mapped to a master-accounts domain. Ideally, each of these account domains should be
upgraded to Windows 2000 and Active Directory before ADC is deployed. This is actually not
required, however, because only the primary domain controller of these domains requires the
upgrade. All other backup domain controllers and member servers can reside in the mixed-mode
domain.
There are several aspects to consider when determining whether your account domain will be a
Windows NT 4.0 domain or an Active Directory domain. After you start to install Exchange 2000
servers, Microsoft Outlook® is able to detect only directory objects that are represented in Active
Directory, so you may need to configure additional connection agreements as part of the
Exchange 2000 deployment process. You need to ensure that all existing Exchange objects,
including those mapped to Microsoft Windows NT® 4.0 domains, are represented in Active
Directory.
For example, what if one of your existing Exchange sites has Mailbox objects that have their
primary Windows NT account mapped to a pure Windows NT 4.0 domain (that is, a domain in
which all domain controllers are running Windows NT 4.0)? If you define a connection
agreement for those Mailbox objects, you must decide how those objects are to be created within
Active Directory. Because Mailbox objects cannot be mapped to a security object within Active
Directory (they only exist in the Windows NT 4.0 domain), by default, a disabled Windows User
object is created. This disabled user has a special mailbox store permission, called Associated
External Account, to show that the Windows NT 4.0 account is the actual owner of the mailbox.
ADC also populates an attribute on the disabled user named msExchMasterAccountSID, which
holds the Security ID (SID) of the Windows NT 4.0 account that is the primary Windows NT
account of the Exchange 5.5 mailbox.
Note
As you will read later in this book, you can specify whether ADC should create a new
object if it cannot find an existing matching object, by defining whether or not the
connection agreement is primary. This behavior is used to prevent duplicate object
creation when the same source container is replicated over multiple connection
agreements to different destination containers.
Caution
Although ADC allows you to create Enabled Windows User, Disabled Windows User,
or Contact objects in Active Directory, you should never configure ADC to create
Enabled Windows User or Contact objects. Contact objects cannot be merged into
Enabled Windows User objects later. The accounts created by ADC are not meant to
be logged on to as security principals; they are merely placeholders for the Exchange
mailbox attributes. Using enabled accounts will not allow users to access the
mailboxes with their Windows NT 4.0 accounts, or to later merge with the upgraded
or migrated accounts. Additionally, the disabled users created by ADC should not be
enabled and used for logon, unless specific steps are taken to update the mailbox
rights and msExchMasterAccountSID that are set on the user. You must either
upgrade the Windows NT 4.0 domain, or use a domain migration utility that can
migrate SIDHistory, to bring the Windows NT 4.0 accounts into Active Directory. For
more information about the disabled accounts, see Microsoft Knowledge Base article
316047, "XADM: Addressing Problems That Are Created When You Enable ADC-
Generated Accounts" (http://support.microsoft.com/?kbid=316047).
Now that the disabled user is representing the mailbox in Active Directory, it is possible to move
the mailbox to an Exchange 2000 server using the Active Directory Users and Computers MMC
snap-in. At this point, because of the "Associated External Account" Information Store
permissions and msExchMasterAccountSID, the Windows NT 4.0 user can log on to the
Exchange 2000 mailbox.
At some point, before or after the mailbox is moved to Exchange 2000, the Windows NT account
must be upgraded or migrated. To upgrade the domain, the primary domain controller needs to be
upgraded to Windows 2000. Backup domain controllers do not need to be upgraded immediately,
because a mixed-mode domain supports Windows NT 4.0 backup domain controllers. When you
upgrade, the Security Accounts Manager (SAM) account database is upgraded directly, and the
user accounts in Active Directory keep the same SID that the Windows NT 4.0 account had.
To migrate the users into Active Directory, there are a variety of domain migration tools, such as
the Active Directory Migration Tool. The main requirement is that the tool supports migrating
SIDHistory. SIDHistory adds the SID of the Windows NT 4.0 user onto the newly created Active
Directory user to allow the Active Directory user to access the same resources that the
Windows NT 4.0 user could, by adding the Windows NT 4.0 SID to the user's token.
After the Windows NT accounts have been upgraded or migrated, you will have two accounts in
Active Directory — the disabled user account created by ADC with all the mail attributes and
msExchMasterAccountSID, and the enabled user account, either upgraded or migrated with
SIDHistory. To merge the two accounts together, and stamp all the mail attributes onto the
enabled account, use the Active Directory Cleanup Wizard (ADClean). ADClean looks for
enabled accounts whose objectSID or SIDHistory match the msExchMasterAccountSID of the
disabled users. When it finds a match, it merges the mail attributes onto the enabled users, and
then deletes the disabled user.
How Is the Container Structure in the

Existing Exchange System Defined?
By default, only the Recipients container is defined for an Exchange site. Some companies create
other containers for different types of objects. It is relatively uncommon for companies to create
containers for each business unit or department, because it is extremely difficult to move objects
between containers. It is quite common, though, for companies to create special containers to
hold different object classes, such as Distribution Lists and Custom Recipients. Depending on the
existing structure in the Exchange directory and the proposed structure in Active Directory, you
may need to decide on a strategy for replicating those objects to equivalent containers.
Figure 2.1 shows the dialog box that illustrates choosing export containers from Exchange
Server 5.5.
Figure 2.1 Choosing recipient containers to export from Exchange Server 5.5
For example, suppose that an Exchange site has three containers: Recipients, Distribution Lists,
and External Addresses.
• To retain the same structure in Active Directory, create a single connection agreement. The
source container in the Exchange directory is the site because the subcontainers can be
created automatically in Active Directory and populated. Note that ADC will only create a
subcontainer if there are objects (mailboxes, distribution lists, custom recipients) within the
source subcontainer for which ADC has to create a new object in the source directory.
• To consolidate all three Exchange containers into a single container or organizational unit in
Active Directory, create a single connection agreement and choose each of the three
containers as the source individually.
• To have complete control over each container (specifying target container or organizational
unit replication times and deletion variables), create three separate connection agreements.
Note
To change the model completely so that the Active Directory structure represents the
business model, configure a single connection agreement, choose the containers
individually or choose the site level, and then replicate them to a dummy target
container or organizational unit in Active Directory. After the objects have been
replicated, you can use Active Directory Users and Computers to move those objects
(by right-clicking the object) to the correct container or organizational unit. ADC
retains the relationship between the two objects even though they have been
moved. This relationship is maintained because of the match between the object and
the globally unique identifier (GUID). If you use this approach, remember to include
the new container or organizational unit as an export container on the From
Windows tab of the two-way connection agreement. Otherwise, changes made to
the object in Active Directory are not replicated back to the Exchange directory.
Note
It is not recommended that you create a special container in Exchange 5.5 to hold
new objects that are created in Active Directory. For example, do not create an
"Exchange 2000 mailboxes" container in Exchange 5.5 and use that as the default
destination on the From Windows tab. Instead, use the Recipients container as the
default destination (where new objects are created in Exchange if no match can be
found). There are two reasons for this:
It does not make sense to separate mailboxes in Exchange 5.5 based on whether
they are Exchange 5.5 or Exchange 2000 mailboxes. This approach does not work
because there is no way to move objects between containers in Exchange 5.5.
Eventually, all of the mailboxes will be moved to Exchange 2000, even if they are in a
container that originally held only Exchange 5.5 mailboxes.
The Exchange 5.5 directory structure has a limited lifetime. As soon as all of the
Exchange 5.5 servers have been upgraded, the Exchange 5.5 directory will no longer
be used.
Using the Recipients container as the default destination will simplify administration
and connection agreement configuration.
C H A P T E R 3
Technical Planning
Chapter 3 presents information you should be familiar with as you plan your deployment of
Active Directory Connector (ADC). Three detailed scenarios are provided to illustrate how to
deploy connection agreements correctly. A section on the public folder connection agreement
describes this special type of connection agreement.
Exchange Server Versions

When you define a connection agreement to a Microsoft® Exchange site, the target directory
bridgehead server must be running Exchange Server version 5.5 Service Pack (SP) 2 or later,
even if you are defining a one-way connection agreement. This is required because, although
Exchange 5.0 server allows read-only Lightweight Directory Access Protocol (LDAP) access, it
doesn't support the additional LDAP paging support required to optimize the throughput of ADC.
Other Exchange servers within the site are not required to run Exchange 5.5.
Schema Updates
When the Exchange 2000 ADC is configured with a two-way connection agreement in the
Exchange 5.5 site, the schema version is checked and updated as required. If you upgrade one of
the servers in the site to Exchange 5.5 SP3, the schema is up-to-date; if not, the directory service
on the target Exchange bridgehead server is stopped, the new schema updates are added, and the
service is started again. The actual schema changes are listed in Appendix A, "Schema Updates
Made by the Exchange 2000 Server Active Directory Connector."
Note
You need Schema Admin permissions to update the schema.
Chapter 3: Technical Planning 23
Installing Exchange
Server 5.5 on a
Windows 2000 Server
Some customers may want to deploy Exchange 5.5 on Microsoft Windows® 2000 Server. This is
possible, but Exchange 5.5 SP3 or later should be installed to support this configuration fully.
After the Exchange 5.5 installation, you may notice that the Active Directory® directory service
contains no information about Exchange. Also, when you try to create new User objects in
Active Directory Users and Computers, you are not prompted to create a Mailbox object. On
Microsoft Windows NT® 4.0, Setup for Exchange Server installs the mailumx.dll library to
support User Manager for Domains. With this DLL in place, the Exchange Administrator and
User Manager programs appear to be linked together. Because Windows 2000 uses a different
administration architecture, this linking is no longer possible through the installed DLL.
If you use the Exchange Administrator program to create Active Directory User objects
automatically, only a small set of fields is populated. The Active Directory display name is set to
the mailbox display name, and the Security Accounts Manager (SAM) account name is set to the
selected logon name.
For Active Directory to recognize the existence of an Exchange 5.5 installation, ADC must be
installed. Even if you haven't configured any connection agreements, ADC should appear in
Active Directory Sites and Services Manager and all Active Directory User and Contact objects
should have the following new configuration options:
• E-mail Addresses tab
• Exchange Tasks, Create Mailbox
After ADC is installed, when creating User objects, the wizard prompts you to create an
Exchange mailbox. However, if you have not configured a connection agreement that exports the
organizational unit the user is in to Exchange 5.5, these options are unavailable.
Note
The new options available after ADC installation are supported only on servers and
workstations that have the ADC manager component or Exchange 2000 System
Manager installed directly on them. The new functionality is in an MMC extension
named maildsmx.dll.
Figure 3.1 Creating an Exchange mailbox using Active Directory Users and
Computers
Where Should ADC Be

Installed?
Selecting the correct class of computer to run ADC depends on the size of your existing
Exchange deployment, the number of Windows 2000 domains, and the hardware budget.
Depending on the replication schedule set for the connection agreements, the number of calls
made into Active Directory and the processing load can be significant. Logically, it makes sense
to install the ADC service directly onto a global catalog server. However, considering that the
global catalog is a key resource in the organization, you may decide to implement ADC on a
member server, ensuring that a fast network link exists between the member and the global
catalog server. Ideally, the Exchange 5.5 bridgehead server should also be on the same fast
network. This allows you to achieve the best performance from all of the components. Of course,
if you deploy ADC in this manner, additional hardware costs may need to be considered.
Although connection agreements are defined and executed on the ADC server, the source and
target directories reside on other computers.
Figure 3.2 Synchronizing multiple Exchange Server 5.5 sites with ADC
Deploying Multiple ADC

Servers
You can deploy multiple ADC servers in large installations, although you must configure the
connection agreements so that each replicates different sets of objects. If only mail-based
connectivity exists, or if you require additional replication performance, you can deploy multiple
ADC servers to ensure that Internet Protocol (IP) connections between servers are relatively
local. They should not be deployed as a fault-tolerant solution, although you can mitigate the risk
of downtime by having more than one ADC server in the enterprise.
Administration and management overhead can be kept to a minimum when you deploy multiple
ADC servers because ADC obtains all configuration information from the configuration naming
context in Active Directory. Because each domain controller in the forest holds a read/write copy
of this context, system administrators can manage connection agreements remotely, even if direct
IP connectivity does not exist between the management console and the ADC server. In this
scenario, the system administrator makes changes to a local domain controller that then replicates
to all of the other servers. Be sure to consider domain controller replication latency when making
these changes. The change will not apply to ADC until it replicates to the domain controller that
ADC is using.
LDAP Ports and Protocols

By default, the ADC server attempts to communicate with the Exchange directory bridgehead on
port 389 (379 for the Site Replication Service), which is the most commonly used LDAP port. In
some circumstances, you must configure the connection agreement for another port, one case
being when Exchange 5.5 is deployed on a Windows 2000 domain controller. Active Directory
components always start before the Exchange directory starts; therefore, the operating system
locks port 389. The Exchange directory still starts, but LDAP communications are not possible.
To work around this situation, use the Exchange 5.5 administration program to reconfigure the
listening port for LDAP (port 390 is usually a good choice), and then set the connection
agreement on ADC to match.
Another circumstance in which you must configure the connection agreement for another port is
when your Recipient Connection Agreement is using a Site Replication Service as its Exchange
bridgehead. In this case, change the port number on the connection agreement to port 379.
Active Directory ports are always 389 for the domain controller and 3268 for the global catalog
server. ADC uses port 389 for export and import, and port 3268 for cross-domain searches.
Nearly all communications that the ADC server establishes are based on LDAP. There is,
however, one instance in which ADC will use a few synchronous remote procedure calls (RPCs):
when you use Active Directory Users and Computers to create a User object, but the mailbox is
specified to exist on an Exchange 5.5 server. When the next replication cycle occurs, an instance
of the Mailbox object is created and a call is made to create new proxy addresses, such as Simple
Mail Transfer Protocol (SMTP), X.400 (X400), or Microsoft Mail (MS). The proxy address
generator can be called only through RPC. This call is made to Exchange System Attendant.
Additionally, if a delete for a mailbox on Exchange 5.5 is made through ADC, an RPC call to the
Exchange Information Store is made and a call to the Exchange 5.5 directory is made through
LDAP. This may be a consideration for you if a firewall exists between the ADC server and the
Exchange 5.5 bridgehead server.
Planning Your Connection

Agreements
It is vitally important that you plan your connection agreements, to avoid problems later on. As
indicated in Chapter 2, ADC can be configured to make fundamental changes to directories
(including deleting objects) and could destabilize the existing Exchange infrastructure.
The following three scenarios are examples of how to deploy connection agreements correctly.
Scenario 1: Two Active Directory

Domains, Three Exchange Sites
Existing Exchange and Windows Environment
Three Exchange sites, Americas, Europe, and Asia, have user accounts in two domains,
corp.contoso.com and sales.contoso.com. High-speed links exist between all sites and domains.
All Exchange mailboxes in the Americas and Europe sites, and some of the Exchange mailboxes
in the Asia site have their primary Windows NT accounts mapped to the corp.contoso.com
domain. The other Exchange mailboxes in the Asia site have user accounts in the
sales.contoso.com domain. For all sites, all Mailbox, Distribution List, and Custom Recipient
objects are in the Recipients container. Each Active Directory domain has all User, Group, and
Contact objects in the Users container.
Business and Technical Requirements
• All replication should be two-way replication.
• Any new mail-enabled Contact or Group objects created in the corp.contoso.com domain
should be created in the Americas site.
• Any new Custom Recipient, Distribution List, or Resource mailboxes created in Asia should
be created in the corp.contoso.com domain.
Solution
To support full two-way replication, the company deploys only one ADC server. The ADC server
in the corp.contoso.com domain handles the connection agreements for both Active Directory
domains. Although Active Directory does not require a global catalog server to be present in each
domain, ADC (and other Exchange 2000 components) benefit from having fast, local access to
the full Active Directory catalog. Additionally, a global catalog server has a full replica of its
home domain, but only a partial, read-only replica of the other domains within the forest.
From looking at the initial environment, you can see that there are two places where a single
export container has multiple connection agreements to different import containers. The first is
the corp.contoso.com\Users container, which has connection agreements to Americas, Europe,
and Asia. The second is the Asia site, which has connection agreements set up to both
corp.contoso.com and sales.contoso.com. This is why the business requirements must specify
which connection agreement should be allowed to create new objects. If more than one primary
connection agreement exports the same containers, it is possible that ADC could create the same
object in more than one place, resulting in duplicate objects.
The connection agreement setup would appear as follows.
Table 3.1 Connection agreement configuration for Scenario 1, Part 1
Attribute/Connection Connection agreement Connection agreement

agreement Americas <-> Europe
corp.contoso.com <-> corp.contoso.com
Type Two-way Two-way
From Exchange tab:
Exchange export Americas/Recipients Europe/Recipients

containers
Objects from Exchange Mailboxes/Custom Recipients Mailboxes/Custom Recipient

/Distribution Lists s
/Distribution Lists
Default destination corp.contoso.com/Users corp.contoso.com/Users

Attribute/Connection Connection agreement Connection agreement

agreement Americas <-> Europe
corp.contoso.com <-> corp.contoso.com
(Windows)
From Windows tab:
Windows export corp.contoso.com/Users corp.contoso.com/Users

containers
Objects from Users/Contacts/Groups Users/Contacts/Groups

Active Directory
Default destination Americas/Recipients Europe/Recipients

(Exchange)
Advanced tab:
Primary to Exchange Yes No

organization
Primary to Windows Yes Yes

domain
Attribute/Connection Connection agreement Asia Connection agreement

agreement <-> corp.contoso.com Asia <->
sales.contoso.com
From Exchange tab:
Exchange export Asia/Recipients Asia/Recipients

containers
Objects from Exchange Mailboxes/Custom Recipients Mailboxes/Custom Recipien

/Distribution Lists ts
/Distribution Lists
Default destination corp.contoso.com/Users sales.contoso.com/Users

(Windows)
Attribute/Connection Connection agreement Asia Connection agreement

agreement <-> corp.contoso.com Asia <->
sales.contoso.com
From Windows tab:
Windows export corp.contoso.com/Users sales.contoso.com/Users

containers

Active Directory
Default destination Asia/Recipients Asia/Recipients

(Exchange)
Advanced tab:
Primary to Exchange No Yes

organization
Primary to Windows Yes No

domain
Figure 3.3 demonstrates the connection agreements. You may find it helpful to sketch the
containers and connection agreements when you plan an ADC configuration.
Figure 3.3 Three Exchange sites, two active domains

Container Mapping
ADC supports some fairly complex container-mapping schemes that you need to consider if
either the Active Directory domain has been split into many organizational units or if the legacy
Exchange environment uses more than one Recipients container. Depending on the requirements,
you may need to deploy multiple connection agreements from the Active Directory domain to the
same Exchange site.
One of the basic questions that designers ask is, "Should I map the Active Directory Users
container to the Recipients container in the Exchange directory?" And following that, "Should I
place legacy Exchange objects in the Users container?"
The container-mapping scheme you use with ADC depends largely on your business
requirements for Active Directory and on your existing Exchange site configuration. Remember
that ADC uses the default destination set on the connection agreement to replicate directory
objects that cannot be mapped between the two directories automatically. Therefore, in an
Exchange organization that has both Exchange 5.x and Exchange 2000 servers, the replicated
directory objects are replicated to the correct containers automatically, and you do not need to
make a decision.
The following are examples of container mapping based on different scenarios.
Scenario 2: Simple Mapping

Existing Exchange and Windows Environment
Two Exchange 5.5 sites: Reading (the largest) and Manchester are replicated together using
native Exchange directory replication connectors. Each site has only the standard Recipients
container, and this container holds all Mailbox, Custom Recipient, and Distribution List objects.
The primary Windows NT account of each Mailbox object currently maps to a User object in
Active Directory.
Business and Technical Requirements for Active Directory
• One domain called example.com and all objects reside in the standard Users container.
• All objects managed from a single tool.
• Any new mail-enabled groups or contacts created in the Users container will be created in
the Reading site.
Solution
Deploy one ADC server. Configure one connection agreement for each existing Exchange site.
See Table 3.3 for the connection agreement configuration.
Table 3.3 Connection agreement configuration for Scenario 2
Attribute/Connection Connection agreement Connection agreement to

agreement to Reading Manchester
From Exchange tab:
Exchange export Reading/Recipients Manchester/Recipients

containers
Objects from Exchange Mailboxes/Custom Recipients Mailboxes/Custom Recipients

/Distribution Lists /Distribution Lists
Default destination Users Users

(Windows)
From Windows tab:
Windows export containers Users Users

Active Directory
Default destination Reading/Recipients Manchester/Recipients

(Exchange)
Advanced tab:

organization

domain
Figure 3.4 demonstrates the connection agreements.
Figure 3.4 Two Exchange Server 5.5 sites and a single Active Directory
domain
Scenario 3: One Domain, Multi-Site,

Split Containers
Existing Exchange Environment
Setting up this scenario is relatively complex, given the number of sites, domains, and
requirements involved. This scenario involves ADC deployment recommendations in quite a few
areas.
A large organization, Northwind Traders, plans to deploy Exchange 2000. There are 20 sites in
the organization. The Seattle and Boston sites will be the first two sites to install Exchange 2000
servers. The remaining sites, including Washington and Miami, will be upgraded incrementally to
Exchange 2000 over the next 12 months. Each site has the standard Recipients container for
Mailbox objects, but there is also a Distribution List container in each site for Distribution List
objects. Each site also has an Internet container to hold SMTP Custom Recipients for external
business partners.
There are four existing Windows NT 4.0 account domains that hold all user accounts. All
Exchange mailboxes in the organization have the primary Windows NT account in one of the
four domains. The administrators have created a single new Windows 2000 domain,
northwindtraders.com, which they plan to migrate all Windows NT accounts into using a third-
party migration tool that supports migrating SIDHistory. Exchange 2000 will be installed, and
users moved from Exchange 5.5 to Exchange 2000, before the Windows NT migration is
completed.
Currently, direct RPC connectivity to the server where the ADC service is installed is not
available at all sites. Additionally, the Exchange environment is not managed centrally, so setting
up connection agreements to all 20 sites directly is not possible until administrators in the remote
sites can coordinate access. Both of these issues will be resolved before the remote sites are ready
to upgrade to Exchange 2000.
Business and Technical Requirements for Active Directory
• All information from the entire Exchange directory needs to be integrated into Active
Directory as soon as possible. Exchange 2000 servers will be installed into the Seattle and
Boston sites.
• The business has already designed an organizational unit structure for Active Directory
based on business units (Sales, Marketing, Research, and Support). Under each business unit
are organizational units named Users and Groups. The migration tool will use information
about the Windows NT 4.0 accounts to create the new accounts in the appropriate
organizational unit. The company has an automated tool to move the groups created by ADC
under the appropriate business unit.
• The business does, however, want to keep the SMTP contacts in a different organizational
unit in Active Directory, which is called External and will reside in the northwindtraders.com
domain. All custom recipients from all sites should be in this container.
• The Northwind Traders administrators should be able to create a user in any business unit
Users container, and put that user's mailbox on an Exchange 2000 server at any site that has
an Exchange 2000 server installed.
• Any new mail-enabled groups created in Active Directory should be replicated to the Seattle
site.
• Any new Contacts created in the External organizational unit should be replicated to the
Seattle site.
Solution
Deploy one ADC server, initially with six connection agreements: two two-way for Seattle, two
two-way for Boston, and two one-way connection agreements to replicate the remaining
Exchange 5.5 sites into Active Directory. Create a new container in Active Directory named
ExchangeTemp, and use this as the default destination for all mailboxes and distribution lists
from Exchange.
As another Exchange site such as Washington or Miami prepares to deploy Exchange 2000, set
up two new connection agreements for that site and remove that site from the two existing one-
way connection agreements. See Table 3.4 for information about connection agreement
configuration for this scenario.
Table 3.4 Connection agreement configuration for Scenario 3, part 1
Attribute/Connection Seattle Boston

agreement Mailbox/Distribution list Mailbox/Distribution list
connection agreement connection agreement
From Exchange tab:
Exchange export Seattle/Recipients Boston/Recipients

containers Seattle/Distribution List Boston/Distribution List
Objects from Exchange Mailboxes/Distribution Lists Mailboxes/Distribution Lists
Default destination ExchangeTemp ExchangeTemp

(Windows)
From Windows tab:
Windows export Sales/Users Sales/Users

containers Sales/Groups Sales/Groups
Marketing/Users Marketing/Users
Marketing/Groups Marketing/Groups
Research/Users Research/Users
Research/Groups Research/Groups
Support/Users Support/Users
Support/Groups Support/Groups
ExchangeTemp ExchangeTemp
Objects from Users/Groups Users/Groups

Active Directory
Default destination Seattle/Recipients Boston/Recipients**

(Exchange)
Attribute/Connection Seattle Boston

agreement Mailbox/Distribution list Mailbox/Distribution list
connection agreement connection agreement
Advanced tab:

Organization

domain
Table 3.5 Connection agreement configuration for Scenario 3, part 2
Attribute/Connection Seattle Custom recipient Boston Custom recipient

agreement connection agreement connection agreement
From Exchange tab:
Exchange export containers Seattle/Internet Boston/Internet
Objects from Exchange Custom Recipients Custom Recipients
Default destination External External

(Windows)
From Windows tab:
Windows export containers External External
Objects from Contacts Contacts

Active Directory
Default destination Seattle/Internet Boston/Internet**

(Exchange)
Advanced tab:

organization
Attribute/Connection Seattle Custom recipient Boston Custom recipient

agreement connection agreement connection agreement

domain
Attribute/Connectio Pure Exchange 5.5 Pure Exchange 5.5

n agreement Mailbox/Distribution list from custom recipient from
Exchange to Windows Exchange to Windows
Type One-way from Exchange to One-way from Exchange to

Windows Windows
From Exchange tab:
Exchange export Washington/Recipients Washington/Internet

containers Washington/Distribution List Miami/Internet
Miami/Recipients …
Miami/Distribution List <Additional Exchange 5.5
Site/Internet>
…
<Additional Exchange 5.5
Site/Recipients and Site/Distribution
List>
Objects from Exchange Mailboxes/Distribution Lists Custom Recipients
Default destination ExchangeTemp External

(Windows)
Advanced tab:
Primary to Exchange
organization

domain
Figures 3.5 through 3.10 demonstrate these connection agreements.
Figure 3.5 Seattle Mailbox/Distribution list connection agreement

Figure 3.6 Boston Mailbox/Distribution list connection agreement

Figure 3.7 Seattle Custom recipient connection agreement

Figure 3.8 Boston Custom recipient connection agreement

Figure 3.9 Pure Exchange 5.5 Mailbox/Distribution list from Exchange to

Windows
Figure 3.10 Pure Exchange 5.5 Custom recipient from Exchange to Windows
This connection agreement configuration will set up Boston and Seattle for two-way replication
to allow Exchange 2000 to be deployed, and also ensure that all objects in the other sites are
represented in Active Directory. When the Washington site is preparing to install Exchange 2000,
the Northwind Traders administrators make the following changes to the connection agreement
setup:
1. On the "Pure Exchange 5.5 Mailbox/Distribution List from Exchange to Windows" and
"Pure Exchange 5.5 Custom Recipient from Exchange to Windows" connection agreements,
remove the Washington containers from the Exchange export containers.
2. Create two new connection agreements for Washington: one for mailboxes/distribution lists
and one for custom recipients.
Table 3.7 shows the configuration for these new connection agreements.
Table 3.7 Configuration for connection agreements for Mailbox/Distribution

list and recipient
Attribute/Connection Washington Mailbox/ Washington Custom

agreement Distribution list connection recipient connection
agreement agreement
From Exchange tab:
Exchange export Washington/Recipients Washington/Internet

containers Washington/Distribution List
Objects from Exchange Mailboxes, Distribution Lists Custom Recipients
Default destination ExchangeTemp External

(Windows)
From Windows tab:
Windows export Sales/Users External

containers Sales/Groups
Marketing/Users
Marketing/Groups
Research/Users
Research/Groups
Support/Users
Support/Groups
ExchangeTemp
Objects from Users/Groups Contacts

Active Directory
Default destination Washington/Recipients** Washington/Internet**

(Exchange)
Attribute/Connection Washington Mailbox/ Washington Custom

agreement Distribution list connection recipient connection
agreement agreement
Advanced tab:
Primary to Exchange No No
organization

domain
Figures 3.11 and 3.12 represent the two new connection agreements.
Figure 3.11 Washington Mailbox/Distribution list connection agreement

Figure 3.12 Washington Custom recipient connection agreement
Explanations and Notes

Because this scenario is relatively complex, it merits some additional explanation.
• Both the Seattle Mailbox/Distribution List and Seattle Custom Recipient connection
agreements are set as primary connection agreements. Under most circumstances, this
configuration would create duplicate objects. However, in this environment, each connection
agreement carries different object classes into the site, so there is no overlap.
• Note that Default Destination (Exchange) is marked ** for all non-primary to Exchange
connection agreements. This is because the default destination is irrelevant for non-primary
connection agreements; they will not create new objects. There is one exception: when the
default import container is used for non-primary connection agreements (see the following
bulleted item).
• Even though the Mailbox/Distribution List connection agreements to all sites except Seattle
are non-primary to Exchange, if you create a new User in Business Unit\User and create a
mailbox on an Exchange 2000 server, ADC will still create a new mailbox in the
Exchange 5.5 directory. This is because ADC can use the home server to determine in which
site the mailbox should be created. However, this does not apply to Exchange 5.5 mailboxes
created in Active Directory. For Exchange 5.5 mailboxes created in Active Directory to
replicate, the connection agreement must be marked as Primary Exchange.
• Originally, all mailboxes and distribution lists for all sites are created in the ExchangeTemp
organizational unit. Northwind Traders uses an automated method (not performed by ADC)
to move the groups created into the correct Business Unit/Distribution List organizational
unit. Note that the disabled users that are created should not be moved. Instead, the
Windows NT migration tool creates new users in the correct Business Unit/Users
organizational unit. Then, the Active Directory Cleanup Wizard (ADClean) can be run to
merge the mail attributes from the disabled user to the migrated account in the correct
organizational unit. Running the ADCClean tool deletes the disabled user automatically.
After all Windows NT 4.0 account domains have been migrated, the only mailboxes that are
left are ones that did not get merged with an enabled user — for example, resource
mailboxes marked with NTDSNoMatch.
• Each Mailbox/Distribution List connection agreement has each Business Unit Users and
Group container exported because of the requirement that a user in any business unit may
have a mailbox in any site. Exporting each container where the enabled user may be put
ensures that, after ADClean is used to merge the accounts, ADC will still be able to replicate
changes to the user in Active Directory back to its original site.
Note
Northwind Traders can still use MMC to manage Distribution List objects that are
replicated into Active Directory from Boston because a two-way connection
agreement is defined.
• Any new mail-enabled groups created in Active Directory will be created in the
Seattle/Recipients container, not the Seattle/Distribution List container. If Northwind Traders
wants the distribution lists to be created in the Distribution List container, they will need to
create additional connection agreements to handle only Group objects, and set the default
destination to Exchange to the Distribution List container.
Public Folder Connection

Agreements
Public folder connection agreements do not replicate public folder data; rather they replicate the
actual public folder directory objects between Exchange 5.5 and Active Directory.
An individual public folder directory object exists purely so that the public folder can be e-
mailed. This is why, in Exchange 2000, mail disabled public folders have no directory entry in
the Microsoft Exchange System Objects container.
However, public folder connection agreements should be created for every site in the Exchange
organization, for the following reasons:
• Folders created using Exchange 2000 cannot be administered from Exchange 5.5 if the
folders do not have a directory entry in the Exchange 5.5 directory. The Exchange 5.5
Administrator program expects to find a directory entry for all public folders.
• Folders created in Exchange 5.5 will generate errors if administered from Exchange 2000 if
they don't have a directory entry in Active Directory. Exchange System Manager will try to
find the directory entries for the folder (which is mail-enabled) in Active Directory. The error
can be cleared and the folder administered, but errors will still exist. Worse, an administrator
may attempt to re-mail enable the folder and create a separate Active Directory entry. If a
public folder connection agreement is ever created, there will be two directory entries for the
same folder, and any mail sent to the public folder will be returned as non-deliverable.
• Administrators running a DS/IS consistency adjuster on Exchange 5.5 can create directory
entries incorrectly for Exchange 2000 folders if their directory entries are not replicated.
Effectively, there would be two separate directory entries (one in Active Directory, one in the
Exchange 5.5 directory) for the same folder. If the directories were ever to replicate in the
future, public folders could have two directory entries in both the Exchange 5.5 directory
and Active Directory. This would prevent mail from being delivered to the folder.
• There may be a future requirement for mailing to the public folders. If all Exchange 5.5
servers are removed from the organization, there will be nowhere to replicate the directory
entries from. At that point, any public folders will have to be updated manually (or re-mail-
enabled using a script).
Even if there are no plans to mail public folders, public folder connection agreements should be
created at the same time as recipient connection agreements. This can help avoid problems in the
future.
Note
Public folders are replicated by e-mail. It is not necessary for folders to have directory
entries for replication to occur. Therefore, if there are problems with replication,
access permissions, or referrals, the public folder connection agreement is the last
place to troubleshoot.
C H A P T E R 4
Resource Usage
Chapter 4 provides information about the server resources that are consumed by Active Directory
Connector (ADC), network resources that are consumed when ADC is running, and factors that
affect how many resources are consumed.
Server Resources Consumed

by ADC
Depending on the replication time set and the number of objects changed, the server on which
Active Directory Connector (ADC) is running and the other directory servers it interacts with
may need to process large amounts of data. Therefore, it is important that these computers have
adequate power and memory. Their network connections should be low latency and high
bandwidth, and, ideally, set up together on the same fast local area network (LAN).
When the ADC threads are working, the load placed on the CPU of the server running ADC is
roughly 50 percent. This consumption level is constant until all replication is complete. However,
the load placed on the CPUs of the computers running the directories is relatively low by
comparison.
The memory consumption of ADC is approximately 6 megabytes (MB) + 2 MB per connection
agreement.
Network Consumption
For large Microsoft® Exchange Server and Microsoft Active Directory® directory service
deployments, you must plan carefully for any additional overhead that ADC and its connection
agreements produce. The following information is especially important if you need to size
servers and network capacity accurately. This information is even more important when the ADC
server, the Active Directory server, and the server running Microsoft Exchange Server
version 5.5 are connected over relatively slow connections.
Table 4.1 indicates the number of network frames and total traffic sent between the different
components. In the following scenarios, a change is made to the phone number on User objects
in Active Directory. Similarly, changes are made to the phone number field in the Exchange
Chapter 4: Resource Usage 49
directory objects. In these samples, ADC is running on a member server. If your deployment
places ADC and the global catalog on the same computer, disregard the network communications
between ADC and the global catalog in the table.
Table 4.1 Sample network utilization for Active Directory Connector
Totals
(frame
ADC to Global ADC to Exchange s and
Global Catalog Exchange 5.5/SRS to wire
Test Catalog to ADC 5.5/SRS ADC size)
No objects to replicate 47 frames 36 frames 20 frames 16 frames 119

frames
19 KB 14 KB 5 KB 3 KB
41 KB
One change in Active 70 frames 89 frames 27 frames 24 frames 210

Directory frames
24 KB 91 KB 9 KB 8 KB
132 KB
Two changes in Active 73 frames 98 frames 34 frames 30 frames 236

Directory frames
24 KB 98 KB 11 KB 12 KB
143 KB
Three changes in 77 frames 96 frames 40 frames 36 frames 249

Active Directory frames
24 KB 101 KB 14 KB 15 KB
154 KB
One change in the 87 frames 103 frames 29 frames 24 frames 243

Exchange Server 5.5 frames
33 KB 103 KB 10 KB 8 KB
directory service 154 KB
Two changes in the 94 frames 114 frames 32 frames 27 frames 267

37 KB 111 KB 10 KB 10 KB
Three changes in the 107 frames 122 frames 37 frames 30 frames 296
43 KB 115 KB 12 KB 12 KB
The conclusions drawn from the information in Table 4.1 are as follows:
• When the two directories are static, only a small amount of data is passed between all
components. However, the majority of this small traffic is between the ADC server and the
global catalog. The connection agreement performs the following actions on each
synchronization cycle:
• Checks to determine whether the Exchange 5.5 or Active Directory schema has
changed.
• Enumerates the Exchange 5.5 organizational units (sites) to determine which are
writable.
• Enumerates all servers in the local Exchange 5.5 site.
• Determines the list of domains in the target forest.
• Exports any updates.
• Changes made in the Exchange 5.5 directory cause a greater amount of data to be moved
over the network relative to changes in Active Directory.
• Replication data from Active Directory to the Exchange directory is linear. When there are
one or more changes to be replicated, use the following calculation:
121 kilobyte (KB) bind + 11 KB per changed object
• Replication data from the Exchange directory to Active Directory is linear. When there are
one or more changes to be replicated, use the following calculation:
140 KB bind + 14 KB per changed object
Using the Site Replication

Service with Exchange 2000
Server
Although connection agreements are usually configured between Active Directory and the
Exchange 5.5 directory service, you can also point the agreements at the Site Replication Service
(SRS) in Exchange 2000 Server (make sure to change the port to 379 when pointing to an SRS).
This can be advantageous when there is a slow network link between ADC and the Exchange 5.5
bridgehead server because the replication payload on the network is much smaller.
Chapter 4: Resource Usage 51
Downstream Replication
Traffic
As the connection agreement replicates data between the two environments, the objects
replicated also change, causing replication in the native directory. You must take this into account
before configuring each connection agreement.
Be aware that when you install a two-way connection agreement between Active Directory and
an Exchange site (or a one-way connection agreement to Exchange), the connection agreement
modifies and adds attributes to each Exchange directory object it comes in contact with. Because
Exchange supports only object-based replication, those directory objects must be replicated again
to the rest of the Exchange organization. For a large deployment of many Exchange sites, you
should plan the deployment of connection agreements carefully. One method is to deploy them
on weekends when there is potentially more bandwidth available on the network.
At a basic level, for each Exchange directory object changed on a server, approximately 5 KB of
data is sent to all other servers within the site. For replication between sites, each object
compresses to about 1 KB. For more information, see Directory Replication and Background
Traffic for Microsoft Exchange 5.5 on TechNet at
http://go.microsoft.com/fwlink/?LinkId=20532.
C H A P T E R 5
How Active Directory

Connector Works
Chapter 5 describes the processes that occur when Active Directory Connector (ADC)
synchronizes the Microsoft® Exchange Server version 5.5 directory and the Active Directory®
directory service.
Initial Replication
When the connection agreement for ADC is initially executed, the stored update sequence
number (USN) on the connection agreement is set to 0. Thus, ADC functions as if the agreement
is being run for the first time. Additionally, each connection agreement has its own signature,
which is computed at connection agreement configuration time. Active Directory objects
replicated into the Exchange directory have the same DSA-Signature attribute as the legacy
Microsoft Exchange 5.5 bridgehead server, although the Replication-Signature attribute of the
object matches the computed value of the connection agreement signature. When an
Active Directory object is replicated into the Exchange directory, the Object-Version attribute,
which is standard to Exchange, is either set to 1 (if it is a new object), or incremented by 1 (if a
modification is taking place).
Before the Lightweight Directory Access Protocol (LDAP) write is made, the current value of the
Object-Version attribute (if it exists) is read, incremented by 1, and then written into the
Replicated-Object-Version attribute also on the Exchange directory object. Thus, if ADC has just
modified an object, both the Object-Version and Replicated-Object-Version attributes are the
same.
Detecting Changes in the

Exchange Directory
When an LDAP search to the Exchange directory is performed, the request is for objects from the
stored USN (msExchServer2HighestUSN on the connection agreement) to the highest USN in
the Exchange directory. This also includes tombstoned entries (that is, entries of objects that have
Chapter 5: How Active Directory Connector Works 53
been deleted). Additionally, a filter is set so that objects that have the signature of the connection
agreement are not requested unless the Object-Version attribute is greater than the Replicated-
Object-Version attribute. This prevents ADC from back-replicating unchanged objects that were
sent to the Exchange directory previously.
Detecting Changes in Active

Directory
Active Directory uses attribute-based replication, unlike the Exchange directory, which uses
object-based replication. To detect changes in Active Directory that need to be replicated to the
Exchange environment, the connection agreement uses a combination of Active Directory USNs
and the sum of attribute versions of each Active Directory object in the source container. ADC
uses a similar stored USN on the connection agreement to keep track of what changes have
already been replicated (msExchServer1HighestUSN on the connection agreement).
Object Class Mapping and

Attributes
The following points will help you understand how different classes of objects are mapped
between the two directories:
• An Exchange 5.5 Mailbox object mapped to a Microsoft Windows NT® Server version 4.0
account appears in the Exchange directory as a Mailbox object, but it maps to Active
Directory as a disabled Windows User. This default behavior of the connection agreement
can be changed to either enabled-User or mail-enabled Contact in the configuration interface
for the connection agreement.
Note
You can prevent ADC from creating an object altogether if the Exchange
directory object cannot be mapped to Active Directory. You can do this by
clearing the This is a Primary Connection Agreement for the Connected
Exchange Organization check box, or This is a Primary Connection
Agreement for the Connected Windows Domain check box. Because a non-
primary connection agreement can modify only existing objects and not create
new objects, if a match does not occur, a new object is not created in the target
container.
• An Exchange 5.5 Mailbox object mapped to an Active Directory account appears in the
Exchange directory as a Mailbox object, and maps to Active Directory as a mailbox-enabled
user (the msExchHomeServerName attribute is set). The Object-GUID attribute of the
Exchange Mailbox object is set to the globally unique identifier (GUID) of the
Active Directory object, and the legacyExchangeDN attribute of the Active Directory object
is set to the distinguished name of the correlating object in the Exchange directory. All
directory attributes from the two objects, such as telephone number, postal address, and so
on, are merged and populated to both directory objects.
• A Distribution List object in the Exchange directory appears in Active Directory as a mail-
enabled Group object (type: Distribution, scope: Universal). Because the Distribution List
object may appear in Active Directory before the membership objects exist, any orphaned
members are binary-encoded and written to the unmergedAtts attribute in the corresponding
entry of the Group object. This ensures that membership changes to the Active Directory
Group object replicate back to the Exchange directory successfully. The unmerged attributes
are removed and resolved only after a full replication of the object is initiated.
• A custom recipient (of any address type) in the Exchange directory appears as a mail-
enabled Contact in Active Directory.
For a list of objects replicating from Active Directory to the Exchange directory, see the
following fidelity class table.
Table 5.1 Object class mapping
Exchange object class

Active Directory object mapping
Mailbox-enabled User Mailbox
Mail-enabled User Custom recipient in the target

container
Non-mail-enabled User Not replicated
Mail-enabled Contact Custom recipient in the target

container
Non-mail-enabled Contact Not replicated
Mail-enabled Group (type: Distribution) Distribution list in the target container
Mail-enabled Group (type: Security) Distribution list in the target container
Non-mail-enabled Group (type: Not replicated

Distribution)
Non-mail-enabled Group (type: Security) Not replicated

Chapter 5: How Active Directory Connector Works 55
Duplicate Object Detection

If at any point ADC attempts to create an object that already exists in the target directory, a
numeric value, prefixed with a hyphen, is appended to the common name of the object. The value
ranges from 1 to 999.
Schema Discovery
When replicating data between two different systems, the format and restrictions for the data may
be different for each system. For example, Active Directory supports 8-bit Unicode
transformation format (UTF-8) in the object name, but the corresponding entry in the Exchange
directory, in this case, the distinguished name, supports only teletext characters. Schema
discovery allows ADC to resolve the restrictions imposed by the target directory and perform the
necessary conversion. Schema discovery accommodates the following discrepancies:
• Data format and presentation (for example, UTF-8 and teletext)
• Field length restrictions
• Mandatory and optional attribute mapping
• Single-value to multivalue field mappings (and vice versa)
C H A P T E R 6
How to Implement Active

Directory Connector
Chapter 6 provides an example of an implementation of Active Directory Connector (ADC),

including screen shots.
ADC Installation
The first step in using Active Directory Connector is to install it from the Microsoft®
Exchange 2000 Server CD. The following steps lead you through the installation process:
1. Start the Microsoft Active Directory Connector Setup program. You can find it in the
\Valupack\mgmt\adc directory on the Microsoft Windows® 2000 Server Installation CD, or
in the \Adc\i386 directory on the Exchange 2000 CD. You must have Enterprise
Administrator permissions to install the ADC. Additionally, unless the schema has already
been extended with the "setup /schemaonly" switch (that is, you ran setup.exe/schemaonly
instead of setup.exe when you set up ADC), you will also need Schema Admin permissions.
The Setup program starts the ADC Installation Wizard (as shown in Figure 6.1). Follow the
steps in the wizard to install ADC.
Figure 6.1 Active Directory Connector Installation Wizard
2. Install both Active Directory Connector and the Active Directory Connector Manager and
click Next.
3. Enter the installation directory and click Next.
4. Enter the Site Services Account name and password and click Next.
Configuring Attribute
Replication and Object
Matching
You may have business and technical reasons for not wanting to replicate all attributes on objects
between Exchange and the Microsoft Active Directory® directory service. Use the property
sheets of ADC to prevent certain attributes from replicating. Figures 6.2 and 6.3 show the tabs
used to configure attribute replication and object matching.
Additionally, by default, ADC attempts to match objects between the two directories based on the
Assoc-NT-Account field. (This is the primary Microsoft Windows NT® account field in the
Exchange 5.5 Administrator program). In the majority of cases, this default is fine. However, in
other situations you might want to change the object matching rules (for example, match the
Exchange alias name to the Active Directory user name). You can specify the attribute-mapping
rules, and you can also define an ordered list of rules.
Chapter 6 : How to Implement Active Directory Connector 59
Figure 6.2 Selecting attributes to be replicated from Exchange Server 5.5
Figure 6.3 Selecting attributes to be replicated from Active Directory

Creating Connection
Agreements
To begin replicating data, a connection agreement must be created. The following steps
demonstrate how to create a connection agreement.
To create a recipient connection agreement
1. Open the Exchange Active Directory Connector and highlight an Active Directory
Connector server. Click Action, click New, and then click Recipient Connection
Agreement.
Figure 6.4 General tab properties of a recipient connection agreement
2. On the Properties property sheet, click the General tab. In the Name field, enter a
descriptive name for the connection agreement. In the Replication Direction section,
indicate whether the replication direction is one-way or two-way. In the Active Directory
Connector Service section, specify the server to run the connection agreement. In most
circumstances, this will be the local server. Figure 6.4 shows the General tab.
3. Click the Connections tab, and, if necessary, change the Lightweight Directory Access
Protocol (LDAP) port for the Exchange directory. You must do this if the default LDAP port
has been changed on the Exchange server, or if the connection agreement endpoint is the Site
Replication Service (SRS). You can verify these settings by looking at the LDAP protocol in
the Protocols container in the Exchange 5.5 Administrator program. Figure 6.5 shows the
Connections tab.
You also use the Connections tab to enter credentials that the connection agreement will use
to connect to the Exchange 5.5 directory and the Active Directory domain controller. Ensure
that the accounts that you specify have write permissions to the site or domain that you are
connecting to.
Figure 6.5 Connections tab properties of a recipient connection

agreement
4. Select the activation schedule for directory replication. During active hours, the connection
agreement checks for and processes changes once every 5 minutes. Because the ADC
connection agreement is most often used for mixed-vintage Exchange sites, the 5-minute
period aligns with the normal intra-site directory replication latency timer. Figure 6.6 shows
the Schedule tab.
Note
The setting of Always equates to every 5 minutes, 24 hours a day, 7 days a
week. Previous releases of Exchange Server used Always to indicate every
15 minutes.
Figure 6.6 Schedule tab properties of a connection agreement
Select the Replicate the entire directory the next time the agreement is run check box to
set the following attributes on the connection agreement:
• msExchServer1HighestUSN
0 (For connection agreements that replicate from Windows)
0 (For connection agreements that replicate from Exchange)
• msExchDoFullReplication
True
Forcing a replication of the entire directory causes all directory objects to be checked for
consistency. If there are any discrepancies between the directories, objects are updated as
appropriate. However, if objects are consistent, they are not replicated again.
5. Click the Advanced tab. The settings on this tab determine the finer details of how ADC
works.
Figure 6.7 Advanced tab properties of a connection agreement
In Paged Results, enter the number of Windows or Exchange Server entries per page.
Usually, you do not need to change LDAP page sizes. Although the default value of
20 entries per paged result may appear to be quite low, it does pace the processor to be kept
busy continually while receiving changes, rather than overly busy or not at all busy.
Figure 6.7 shows the Advanced tab.
The other options on the Advanced tab are very important. The check boxes indicating
primary connection agreements control what happens when replication cannot find a match
between associated objects in the two directories. Although two of the three check boxes
look similar, they perform slightly different functions.
• This is a primary Connection Agreement for the connected Exchange
Organization.
This option controls whether ADC should create a new object when it replicates a new
object from Windows, if it cannot find a matching object or determine which site the object
should be created in.
This is important when you have more than one connection agreement set up to different
sites, both exporting the same container from Active Directory. For each container you are
exporting from Windows, you should have exactly one connection agreement set as primary.
For detailed information about this check box, see "Primary vs. Non-Primary Connection
Agreements" in Chapter 7.
• This is a primary Connection Agreement for the connected Windows Domain
This check box is associated with the setting for replicating Mailbox, Distribution List, and
Custom Recipient objects that do not have an existing matching object in Active Directory.
Implicitly, this check box controls whether an object is created in the domain if a match
cannot be found. As with the Primary Exchange option, you should have exactly one primary
connection agreement handling each Exchange container that you want to replicate.
• This is an Inter-Organizational Connection Agreement
For information about this option, see Appendix I, "Inter-Organization Connection
Agreement."
6. Click the Deletion tab. The settings on this tab determine what happens when directory
objects are deleted from source and target directories.
By default, objects deleted from each directory are not propagated to the destination
directory. Instead, the deletions are held in the following directories on the ADC server:
\<%windir%>\MSADC\Connection Agreement name
Table 6.1 shows the names of the files created by ADC for deletions.
Table 6.1 Files created by ADC for deletions
File name Purpose
Win2000.ldf Entries deleted from the Exchange directory
Ex55.csv Entries deleted from Active Directory
If you decide not to propagate deletions, it can cause additional management overhead
because the system administrator must look through the files that were created and import
them into the adjacent directory. If several hundred changes are occurring and you have tight
control over who can delete Directory objects, you may opt to enable deletion propagation.
If you decide to enable deletions through the user interface, be very careful of the changes
that you make to each directory. For example, deleting a Custom Recipient object in
Exchange deletes the related Active Directory object, which may be a mail-enabled Contact
or User object representing an account from a different domain.
After a mailbox is deleted, either by using Active Directory Users and Computers or if ADC
deletes the mailbox, you may see two special values in the legacyExchangeDN value:
• ADCDisabledMailByADC. Indicates that the Exchange 5.5 mailbox was deleted and
the Active Directory object is an enabled user object.
• ADCDisabledMail. Indicates that Active Directory Users and Computers was used to
delete the user's mailbox.
Note
You may want Contact object deletions to be propagated, but may not want
Mailbox object deletions to be propagated. To improve the granularity of deletion
control in Exchange 2000 Server, you can configure multiple connection
agreements with different options.
7. Click the From Windows tab. The settings on this tab determine which containers or
organizational units are sent to the Exchange directory and specify the default destination
container where they are received in the Exchange 5.5 site. Use the Add button to add
multiple containers. If a complex hierarchy exists within the Active Directory domain, you
do not have to select each organizational unit individually; you can select the top-level
domain as the source. However, doing that assumes that you want to retain that hierarchy.
When replicating to Exchange, ADC creates those containers automatically. The containers
are only created if there are objects within those containers, and ADC must create a new
object in Exchange to match it.
Figure 6.8 From Windows tab properties of a connection agreement

It is important to understand the concept of the "default destination." If an Active Directory
User object is mapped to a Mailbox object in the Recipients container, and the connection
agreement specifies that objects be sent to a different Exchange container, a duplicate object
is not created in Exchange. ADC retains the relationship between the two objects correctly.
Therefore, think of this option as signifying, "If the Active Directory object does not relate to
any existing Exchange object, then an object is created by ADC in the target container."
For example, if a mail-enabled Contact object is created in Active Directory, a Custom
Recipient entry appears in the target Exchange container because no mapping is achieved for
security identifiers.
You can also select the object classes to replicate to the target directory by selecting or
clearing the check boxes in the Objects section. Figure 6.8 shows the From Windows tab.
Warning
You should never choose the Site level as the Default destination in Exchange.
This will cause new objects to be created directly under the site, instead of in a
Recipients container, which will make the objects unmanageable using
Exchange 5.5 Admin. Always choose a level where you want new objects to be
created, such as a Recipients container.
• Replicate secured Active Directory objects to the Exchange Directory

This option specifies whether objects with an explicit DENY Access Control Entry in their
permissions should be replicated to the Exchange directory. By default, ADC does not
replicate any objects from Active Directory with a DENY ACE for security purposes,
because there is no way to use a DENY ACE in Exchange permissions. However, this
behavior can sometimes cause some Active Directory objects not to appear in Exchange 5.5.
• Create objects in location specified by Exchange 5.5 DN
This option tells ADC where to create new objects. By default, ADC first tries to create the
object in the location specified in Default destination. However, if you enable this option,
ADC first tries to use the legacyExchangeDN of the Active Directory object to determine
where to create the object in Exchange 5.5. If that fails, then ADC tries the default
destination.
For example, suppose the default import container is cn=NewContainer,ou=Site,o=Org. A
new mailbox-enabled user is created in Active Directory with a legacyExchangeDN of
cn=NewUser,cn=Recipients,ou=Site,o=Org. With this option enabled, the user is created in
the Recipients container, not NewContainer.
This option is also useful if you have a large hierarchy of organizational units in Active
Directory, but you want to create all objects in a single container in Exchange 5.5. Enabling
this option overrides the default behavior for replicating the directory structure because all
objects are created in the Recipients container instead.
8. Click the From Exchange tab. The settings on this tab specify which containers to replicate
from the Exchange directory.
Figure 6.9 From Exchange tab properties of a connection agreement
9. Click Add and either select the Site object, or choose each recipient container individually
as the export containers, to replicate all containers in the site. Click Modify, and then in
Default destination, enter the default destination container in Active Directory. In Objects,
select the check boxes for the different types of object classes to replicate from the Exchange
directory. As with the From Windows tab described in Step 7, by doing this you specify the
default target container for objects that cannot be mapped.
Caution
As with the Default destination in Exchange 5.5, do not set the default
destination for Active Directory at the domain level. This will cause new objects
created in Active Directory to be directly under the domain object instead of in
an organizational unit or container, which will make the objects hard to manage
using Active Directory Users and Computers. Instead, always ensure that the
Default destination is a location where you actually want objects to be created.
With a two-way connection agreement, ADC requires that the default destination to
Exchange must also be listed as an export container on the From Exchange tab, and vice
versa with the default destination to Windows. This ensures that any new objects ADC
creates can replicate back to the original directory. Always ensure that any containers in
Exchange or Active Directory that you want to replicate out are listed as export containers.
Only containers from one Exchange site can be selected in a single connection agreement if
the agreement is configured to write to the Exchange directory. If multiple Exchange sites
are deployed, you also need to establish multiple connection agreements.
10. Start ADC. You can start ADC from the Computer Management MMC console or from a
command prompt by typing net start msadc.
Note
You must be a member of Administrators, Server Operators, or otherwise have
permissions to start and stop services.
11. After ADC starts, new objects are populated in both Active Directory and the Exchange
directory. To monitor the progress of a connection agreement, either look at the Performance
Monitor counters or monitor the application log.
From here, you can create additional connection agreements and enable them without having
to stop and restart the MSADC service. Changes are implemented dynamically.
Creating Public Folder

To create a public folder connection agreement
1. Open the Exchange Active Directory Connector and highlight an Active Directory
Connector server, then click Action, click New, and click Public Folder Agreement.
Figure 6.10 General tab properties of a public folder connection

agreement
2. In the Properties dialog box for the public folder connection agreement, click the General
tab. In the Name field, enter a descriptive name for the connection agreement. In the
Replication Direction section, indicate whether the replication direction is one-way or two-
way. In the Active Directory Connector Service section, specify the server to run the
connection agreement. In most circumstances, this will be the local server. Figure 6.10
shows the General tab.
Note
Public folder connection agreements must be two-way.
3. Click the Connections tab, and, if necessary, change the Lightweight Directory Access
Protocol (LDAP) port for the Exchange directory. You must do this if the default LDAP port
has been changed on the Exchange server, or if the connection agreement endpoint is the Site
Replication Service (SRS). You can verify these settings by looking at the LDAP protocol in
the Protocols container in the Exchange 5.5 Administrator program. Figure 6.11 shows the
Connections tab.
Figure 6.11 Connections tab properties of a public folder connection

agreement
4. Select the activation schedule for directory replication. During active hours, the connection
agreement checks for and processes changes once every 5 minutes. Because the ADC
connection agreement is most often used for mixed-vintage Exchange sites, the 5-minute
period aligns with the normal intra-site directory replication latency timer. Figure 6.12 shows
the Schedule tab.
Note
The setting of Always equates to every 5 minutes, 24 hours a day, 7 days a
week. Previous releases of Exchange Server used Always to indicate every
15 minutes.
Figure 6.12 Schedule tab properties of a public folder connection

agreement
Select the Replicate the entire directory the next time the agreement is run check box to
set the following attributes on the connection agreement:
0 (For connection agreements that replicate from Windows)
0 (For connection agreements that replicate from Exchange)
• msExchDoFullReplication
True
Forcing a replication of the entire directory causes all directory objects to be checked for
consistency. If there are any discrepancies between the directories, objects are updated
as appropriate. However, if objects are consistent, they are not replicated again.
5. Click the Advanced tab. The settings on this tab determine the finer details of how ADC
works.
Figure 6.13 Advanced tab properties of a public folder connection

agreement
In the Paged Results section, enter the number of Windows or Exchange Server entries per
page. Usually, you do not need to change LDAP page sizes. Although the default value of 20
entries per paged result may appear to be quite low, it does pace the processor to be kept
busy continually while receiving changes, rather than overly busy or not at all busy.
Figure 6.13 shows the Advanced tab.
The other options on the Advanced tab are very important. The check boxes indicating
primary connection agreements control what happens when replication cannot find a match
between associated objects in the two directories. Only one of the three check boxes is
available: This is a primary Connection Agreement for the connected Windows Domain.
• This is a primary Connection Agreement for the connected Windows Domain
This check box is associated with the setting for replicating public folder objects that do not
have an existing matching object in Active Directory. Implicitly, this check box controls
whether an object is created in the domain if a match cannot be found.
6. Click the Deletion tab. The settings on this tab determine what happens when directory
objects are deleted from source and target directories. By default, unlike recipient connection
agreements, objects deleted from each directory are propagated to the destination directory.
C H A P T E R 7
After Installation
Chapter 7 describes how Active Directory Connector (ADC) finds, matches, and links objects,
how Active Directory and the Exchange 5.5 directory handle replicated objects, and explains the
differences between primary and non-primary connection agreements.
How Active Directory

Connector Finds, Matches,
and Links Objects
When ADC replicates objects between Microsoft® Exchange and Microsoft Windows®, it must
determine whether a matching object in the target directory already exists. ADC uses two
methods to find a target object:
• ADC Global Names When ADC replicates to a target object, it stamps a unique value
in msExchADCGlobalNames to identify which source object replicated to it. The next time
that object replicates, it has msExchADCGlobalNames set on it, so that it can easily
determine which object to replicate back to. When the object replicates back, it sets
msExchADCGlobalNames on the original object, so now both objects are marked with each
other's unique name. For the exact format and detailed information about ADC Global
Names, see Microsoft Knowledge Base article 316280, "XADM: A Description of the 'ADC
Global Names' Attribute" (http://support.microsoft.com/?kbid=316280).
• Object Matching Rules This method applies when replicating Mailbox objects from
Microsoft Exchange Server version 5.5 to the Active Directory® directory service. ADC
looks at the primary Microsoft Windows NT® account on the mailbox (also called Assoc-
NT-Account) and tries to find a user in Windows whose objectSID or SIDHistory matches
that account. For a detailed description of the object matching rules, see Appendix D, "ADC
Matching Rules."
Figure 7.1 is a flow chart that describes how ADC matches objects from Exchange Server 5.5 to
Active Directory.
Figure 7.1 How ADC matches objects from Exchange Server 5.5 to Active
Directory
Chapter 7: After Installation 75
Replicated Objects in Active

Directory
After the initial ADC replication occurs, Exchange 5.5 objects, such as Custom Recipients,
Distribution Lists, and Mailbox Agents (for example, the Schedule+ Free/Busy Connector), are
represented by objects of the same class in the Active Directory target container. A custom
recipient is created in Active Directory as a mail-enabled Contact object. The mail address field
is set to the Simple Mail Transfer Protocol (SMTP) proxy address of the object, even if it is a
non-SMTP custom recipient. The attributes of Exchange Mailbox objects, if previously mapped
to Windows 2000 Server accounts, are replicated to the associated mailbox-enabled User object,
regardless of which container it is in.
When looking for a matching object in Active Directory, ADC searches by using the global
catalog, which means it can find a match anywhere in the forest. Similarly, when looking for a
matching object in the Exchange 5.5 directory, ADC can find a match anywhere in the
organization. However, ADC can only write to the target object if it is in a writable naming
context on the server that ADC is communicating with. For Exchange 5.5, this means anywhere
in the local site, and for Active Directory, this means anywhere in the domain. Additionally, ADC
can only write to the target object if the account specified on the Connections tab has the
appropriate write permissions on the target container.
The following two examples show situations in which the objects are matched, but the attributes
are not replicated:
• Two account domains exist that have been upgraded to Windows 2000. One
Exchange 5.5 site named Corporate exists. A connection agreement is configured to replicate
from Corporate to the NorthAmerica/Users container. An Exchange 5.5 mailbox, MB1, in
Corporate has its Assoc-NT-Account linked to a Europe Active Directory user, EuroUser.
When ADC replicates to NorthAmerica, it searches the global catalog for an objectSID that
matches the Assoc-NT-Account of MB1, and it finds EuroUser. However, because the
NorthAmerica domain controller does not have a writable copy of the Europe domain, ADC
does not write to the target object.
• One account domain exists with multiple organizational units. There is one Exchange 5.5
site with two organizational units, Executives and Employees. Each organizational unit has
been set so that only members of a particular Admin Group can read/write/modify the
corresponding container (Executive Admin Group has permission to the Executive OU
container; Employee Admin Group has permissions to the Employees container). The
account specified on the Connections tab only has permissions to read/write/modify one
organizational unit.
Object matching does not fail in either situation, but modifying the object does fail. A duplicate
object will not be created in these examples. To verify if either of these situations is happening in
your environment, set Replication to Minimum under ADC Diagnostic Logging.
The following is an example of a scenario in which replication will fail. Before you installed
ADC, the Exchange mailbox for Scott Cooper existed and was assigned to a User object. At this
stage, only a display name and a Windows NT 4.0 logon name existed for the User object in
Active Directory. After replication by ADC, the User object contains values for all of the
Exchange Mailbox object attributes, such as postal address, title, company, proxy addresses,
Distribution List membership, and management reporting. A closer look at the User object
reveals that an Exchange tab now exists and shows the Home Server as org/site/server. Also, the
e-mail address of the object is now set to the SMTP proxy address of the Exchange mailbox.
You can view the raw attributes of the User object by using the Active Directory Administration
Tool (ldp.exe) and the Active Directory Service Interfaces editor (ADSIEdit.msc). Both of these
tools are in the Windows 2000 Server Resource Kit
(http://go.microsoft.com/fwlink/?LinkId=6545).
Note
There is a brief description of how to connect and use ldp.exe and ADSIEdit.msc in
Chapter 9, "Advanced Configuration."
Now that ADC has properly linked an Exchange 5.5 Mailbox object with Active Directory, the
User object has many new fields populated. In addition to the attributes that are brought over
from the Exchange 5.5 object, ADC sets the following attributes:
msExchADCGlobalNames
Attribute syntax: multivalued Unicode string
Set on a target object to identify which source object to match to. For more information, see
Microsoft Knowledge Base article 316280, "XADM: A Description of the 'ADC Global
Names' Attribute" (http://support.microsoft.com/?kbid=316280).
legacyExchangeDN
Attribute syntax: single-valued case-insensitive string
The Exchange 5.5-style distinguished name of the Exchange 5.5 object that this object is
matched to. For example: /o=ORG/ou=SITE/cn=Recipients/cn=RDN
msExchHomeServerName
Attribute syntax: single-valued Unicode string
Contains the Exchange 5.5-style distinguished name of the server that the user's mailbox is
on.
For example: /o=ORG/ou=SITE/cn=Configuration/cn=Servers/cn=SERVER-NAME
replicationSignature
Attribute syntax: single-valued octet string
Set to the objectGUID of the connection agreement that replicated to this object.
msExchHideFromAddressLists
Attribute syntax: Boolean
Set to True if the Exchange 5.5 object is hidden from the address book.
showInAddressBook
Attribute syntax: multivalued distinguished name
Set only if Microsoft Exchange 2000 Server is installed in the forest. Unless
msExchHideFromAddressLists is set, ADC adds the distinguished name of the default global
address list (GAL) to ensure that the object will be visible in the Exchange 2000 GAL.
msExchMailboxGuid
Set to a new, random GUID for use later when the mailbox is moved to Exchange 2000.
Replicated Objects in the

Exchange Directory
Exchange objects that are either the target of an ADC match or created by ADC also contain
some new or modified attributes, including the following:
msExchADCGlobalNames (New) (Shown as ADC-Global-Names in
Exchange 5.5 Admin)
Set on a target object to identify which source the object is matched to. For more
information, see Microsoft Knowledge Base article 316280, "XADM: A Description of the
'ADC Global Names' Attribute"
(http://support.microsoft.com/?kbid=316280).
DSA-Signature (Modified)
Set to the Invocation-ID of the Exchange 5.5 server on the Connections tab of the
connection agreement.
Object-GUID (New)
Set to the objectGUID attribute present on the User object in Active Directory.
Object-Version (Modified)
Attribute syntax: single-valued integer
Incremented by one after the initial replication.
Replication-Signature (New)
Set to the objectGUID of the connection agreement that made the change.
Replicated-Object-Version (New)
Matches the Object-Version attribute because ADC made the last change to the object.
Figure 7.2 is a flow chart that describes how ADC matches objects from Active Directory to
Exchange 5.5.
Figure 7.2 How ADC matches objects from Active Directory to Exchange
Server 5.5
Primary vs. Non-Primary

When you have multiple sites, multiple domains, or both, you may need to determine if you will
need primary or non-primary connection agreements when designing your ADC deployment.
This section covers each primary option in detail.
• This is a primary Connection Agreement for the connected Windows Domain.
This option is associated with the setting for replicating mailbox, distribution list, and custom
recipient objects that do not have an existing matching object in Active Directory. There are two
different types of match ADC can use when choosing a target object to replicate to. The first is
using ADC Global Names. When exporting an object, the first thing ADC checks is whether the
source object has msExchADCGlobalNames with a value that matches the target directory type.
For mailboxes in Exchange 5.5, ADC uses a set of object matching rules to try to find an existing
user in Active Directory to match with. For distribution lists and custom recipients, ADC does
not have any matching rules. Implicitly, this option controls whether an object is created in the
domain if a match cannot be found. As with the Primary Exchange option, you should have
exactly one primary connection agreement handling each Exchange container that you want to
replicate.
• This is a primary Connection Agreement for the connected Exchange organization.
You can configure multiple connection agreements in the Exchange environment, and this is
particularly important when you have multiple sites and require two-way replication. Imagine,
though, that the Active Directory source for those connection agreements is the same container or
organizational unit. This means that as each connection agreement replicates from Windows to
Exchange, it tries to export the same objects (such as groups and contacts) to each site. If all
connection agreements were allowed to create a new group or contact object in their own site,
duplicate objects would be created. By clearing this check box on all connection agreements
except one, the "non-primary" connection agreements replicate only changes to objects that
already exist in the Exchange directory. New objects including Group and Contacts are not
replicated through this connection agreement. Then the connection agreement that is marked as
primary is responsible for creating new objects in Exchange 5.5, and that server can replicate the
new objects to all other servers using Exchange 5.5 directory replication.
For each container that you want to export, there should be exactly one primary connection
agreement. If you do not have any primary connection agreements, you will be missing objects in
the Exchange 5.5 directory because ADC will not create any new objects if it cannot find an
existing match and cannot determine which site the object belongs in. If you have more than one
primary connection agreement exporting the same containers, you risk creating duplicate objects
in the Exchange 5.5 directory.
When replicating from Windows to Exchange, the Primary option works slightly differently than
the Primary Exchange to Windows option.
The "This is a primary Connection Agreement for the connected Exchange Organization." option
only takes effect if ADC cannot determine which site an object in Windows belongs to. For
mailbox-enabled users, ADC uses the msExchHomeServerName value to determine the site. For
Contacts and mail-enabled Groups, ADC uses the legacyExchangeDN value.
If you do not have Exchange 2000 installed, or if you use the ADC version of Active Directory
Users and Computers (maildsmx.dll), and then you create a new Contact or mail-enabled Group
in Active Directory, the legacyExchangeDN value does not get set. In this case, only a
connection agreement marked as "Primary Exchange" will create a new object in Exchange 5.5.
If you use Active Directory Users and Computers to create a new mailbox-enabled user in
Exchange 5.5, the application determines which sites the user will be exported to, and a list is
displayed.
If you create a new mailbox-enabled user in Active Directory, and create the mailbox on an
Exchange 2000 server in Site A, then even if the connection agreement for Site A is not a primary
Exchange connection agreement, ADC will still create a mailbox in Site A to match the mailbox
in Active Directory. This is because ADC can use the msexchHomeServerName attribute to
determine which site the mailbox should be in and can make a logical choice to create the
mailbox in the correct location. This behavior does not apply to new mail-enabled groups or
Contacts created in Active Directory because they are not implicitly associated with a particular
site the way a mailbox object is. Also, this behavior does not apply for mailbox-enabled users
created in Active Directory with mailboxes on an Exchange 5.5 server. For the Exchange 5.5
server to be listed in the available servers list when the mailbox is being created, there must be a
primary Exchange connection agreement exporting the organizational unit the user is created in
to the site where you want to create the mailbox.
Note
It is extremely important to test the configuration before setting the configuration
agreement to "Primary". It is also important to understand that, if duplicate objects
are created, cleanup is manual. It can take a long time to clean up the results of poor
planning and deployment of ADC. For information about the suggested ADC
deployment, see Chapter 3, "Technical Planning."
C H A P T E R 8
Troubleshooting
Chapter 8 provides information to help you resolve issues that can arise with your Active
Directory Connector (ADC) deployment. Descriptions are included for each category of
diagnostic logging, as are troubleshooting tips for several common issues.
Event Logs
If you find that operations are failing to complete, you can increase the logging level for several
categories. Increasing the logging level generates more information in the event log. To change
diagnostic logging options, start the Active Directory Connector Management snap-in for the
Active Directory Connector (ADC) server that requires troubleshooting, and click the Diagnostic
Logging tab.
Figure 8.1 Diagnostic Logging tab of an Active Directory Connector server

For initial troubleshooting, it is recommended that you set the category logging level to
Minimum, then force replication of the connection agreement by right-clicking the connection
agreement and clicking Replicate Now. Figure 8.1 shows the Diagnostic Logging tab.
Event Logging
The ADC event log has five categories of messages, as shown in Table 8.1. Each category has
four levels of logging, as shown in Table 8.2.
Table 8.1 Diagnostic logging message categories
Category Description
Replication Indicate events that occurred during replication.
Account Indicate events that occurred while attempting to write or delete a

management Microsoft® Windows® object during replication.
Attribute Indicate events that occurred while mapping attributes between the Active
mapping Directory® directory service and the Microsoft Exchange Server version 5.5
directory.
LDAP Indicate events that occurred while accessing the directory using Lightweight
operations Directory Access Protocol (LDAP).
Service Indicate events that occurred when the service was started and stopped.
controller
There are four logging levels for ADC.
Table 8.2 Diagnostic logging levels
Level Description
None Default logging level. Logs only critical events and error events, including starting
and stopping the service, and component installation.
Minimum Logs events including the success or failure of adding or removing a user account,
errors encountered when establishing LDAP sessions, and errors updating the
directory.
Medium Logs events including those associated with the existence of specific objects in the
directory.
Chapter 8: Troubleshooting 83
Level Description
Maximum Logs all events and provides a complete record of the operation of ADC and the
status of replication. Unless you are troubleshooting a problem, avoid using the
Maximum logging level because it logs a large amount of information and can
affect server performance.
Directory Inconsistencies
Your first reaction to resolving replication problems may be to tear down connections and start
again. Although this is a safe operation in some systems, with Active Directory Connector be
cautious if you destroy a connection agreement and then re-establish it. Normally, deleting and
re-creating connection agreements does not resolve replication issues.
If there are minor discrepancies between the two directories, open the Active Directory
Connector snap-in, select the connection agreement in question, and on the Task menu, click
Replicate now. If this does not resolve the issue, and only one of two objects appears to be out-
of-date, try modifying one of the attributes on the object. If there are major directory
inconsistencies, on the Schedule tab, select the Replicate entire directory check box for the
If you intend to clean up the directories and reconfigure replication completely, you must also
remove msExchADCGlobalNames from all objects that have been replicated in both directories.
(For more information about how to correct mismatched accounts, see Microsoft Knowledge
Base article 256862, "XADM: How to Correct Mismatched Accounts After Active Directory
Connector Replication" (http://support.microsoft.com/?kbid=256862).
Additionally, it is recommended that when the new connection agreements are set up, you set
deletions to write to a file (as shown in Table 6.1) to avoid the inadvertent deletion of objects.
Additional Troubleshooting
Several common failures or issues may occur after ADC has been implemented:
• The connection agreement fails to replicate all or some objects.
• The connection agreement fails to update all or some objects.
• The connection agreement fails when attempting to match an object and
a duplicate object is created.
• The connection agreement appears to fail when attempting to match an object.
• ADC causes an exception.
There are some common troubleshooting tips and tricks to resolve these issues, which are
discussed in the following sections.
Best Practices When Using Diagnostic

Logging
When troubleshooting most issues, setting replication to Medium will log errors that point to the
source of the issue. Most failures or problems will be exposed during a replication cycle.
Diagnostic logging can only be set at the server level. This means that, if five connection
agreements are configured on one ADC server and diagnostic logging is set to Maximum for
replication, if all connection agreements replicate, all five will log events. Events will be logged,
providing information about connection agreements for which information may not be needed.
To log events that pertain only to a particular connection agreement, on the Schedule tab, in the
properties of the connection agreement, set all connection agreements on a particular server to
replicate Never, except the connection agreement in question. Or, move the connection
agreement that you want to troubleshoot to a different ADC server. In the Active Directory
Connector Management snap-in, right-click the connection agreement and click Replicate Now.
Set all categories to a level of None, and reset all connection agreements to their normal
schedule.
Failure to Write to an Object

Failure to write to a domain, an organizational unit, or a particular object can occur due to lack of
permissions. This can occur when a connection agreement is set to replicate, and uses credentials
specific to a domain or an organizational unit. An object that has changes may reside in a domain
or an organizational unit that the ADC account does not have permissions to write to.
To troubleshoot this issue, set replication to Minimum for the connection agreement, follow the
steps described in the preceding section, "Best Practices When Using Diagnostic Logging," and
replicate the connection agreement. This will log events describing permissions to write to the
target object.
Also, ADC may not write to an object if it determines that the objects are synchronized. To
correct this, increase the object version on the source object by modifying it in some way, and
choose Replicate Now.
ADC may also fail to write when the Windows 2000 forest has not been upgraded from the
Microsoft Windows NT® domain. Trusts have to be established to allow ADC to read/write to
both directories. In some circumstances Windows NT 4.0 accounts (considered
ForeignSecurityPrincipals) will be targeted as a match, but ADC may not have sufficient
permissions to write to the target domain.
Failure to Match an Object

ADC has logic that attempts to match an object in the directory to objects in Active Directory.
When ADC attempts to match an object, but fails, this can be because the attributes used to
Chapter 8: Troubleshooting 85
match the objects are not the same in both directories. When matching objects, ADC uses
Security ID (SID), SIDHistory, ObjectGUID, and msExchADCGlobalNames.
ADC will match on the security identifier (SID) if the Windows NT account has been upgraded
from a previous Windows NT 4.0 accounts domain. There are very few situations in which ADC
will not synchronize after a Windows NT 4.0 accounts domain has been upgraded. Typically,
failure to synchronize only occurs when ADC does not have permissions to write to the target
object.
ADC will match on SIDHistory when the Windows NT 4.0 account has been cloned (using one
of the available account cloning tools). SIDHistory is populated when the account is cloned
because the object in Active Directory is new, not upgraded. Populating SIDHistory is a function
of the cloning tool. This allows both Windows 2000 and ADC to operate and coexist when two
separate Windows NT domains are being used for authentication and access to resources.
ADC will match on MsExchADCGlobalNames only after the object has been replicated. The
MsExchADCGlobalNames attribute exists on Exchange Server 5.5 after it is upgraded to Service
Pack 3. The MsExchADCGlobalNames attribute exists in Active Directory after the ADC
installation has been run. When ADC finds an object and replicates to a target object, it writes to
this attribute.
Troubleshooting Failures-to-Match
Typically, troubleshooting failures-to-match involves connecting to the Exchange 5.5 directory
with the LDP utility and dumping the object and the Assoc-NT-Account to a text file. Next,
connect to Active Directory with LDP to find both the object that was expected to match, and the
object either created or matched to. Then dump both objects, the SID and/or SIDHistory, to a text
file. Review all of the text files and compare the SID, msExchADCGlobalNames, and/or
SIDHistory manually to verify whether or not the Assoc-NT-Account from the Exchange 5.5
mailbox matches the objectSID or SIDHistory of the Active Directory user.
Failed.ldf File
During replication between Exchange 5.5 and Active Directory, if ADC fails to replicate to a
target directory, a Failed.ldf file is written. This file is located by default in
<installDrive>\Program Files\MSADC\MSADC\<NameOfCA>. Two files may be created and
appended during failures, EX55-2Failed.ldf and Win2000Failed.ldf. Both files log failures and
contain additional information regarding what may be the root cause of the failure. You can open
.ldf files with a text editor.
Ldif.err File
The Ldif.err file is created during setup. It records errors that may have occurred during schema
import.
C H A P T E R 9
Advanced Configuration
The configuration of the connection agreements allowed through the Microsoft Management
Console (MMC) interface is sufficient for most deployments, both small and large. However, in
deployments where there is a very complex Exchange site or Active Directory® topology, you
can make some advanced customizations to Active Directory Connector (ADC). This chapter
details two of the most common areas of customization.
It is important that you thoroughly test and document any advanced customizations to ensure
good supportability. Testing the behavior of any changes described in this chapter, including
Lightweight Directory Access Protocol (LDAP) search filters, schema mapping, and object
matching rules, is the responsibility of the customer. Microsoft cannot support issues that arise as
a result of modification in any of these areas. If you have made any of these customizations and
subsequently call Microsoft Product Support Services about problems with Microsoft®
Exchange 2000 Server, be sure to let the Product Support Services staff know about the changes
that you have made.
Tools
Several tools are available to make the configuration changes detailed in this chapter. Two of
these tools are the Active Directory Administration Tool Ldp utility (ldp.exe) and the
Active Directory Service Interfaces editor (ADSIEdit.msc). Both tools are included in the
Microsoft Windows 2000 Server Resource Kit
(http://go.microsoft.com/fwlink/?LinkId=6545).
Following are instructions for using the tools:
• ldp.exe Use the Connect option to contact the Active Directory server, and then bind to
Active Directory as an administrator account. After authentication occurs, on the View
menu, click Tree, and then type the LDAP path to the configuration naming context. For
example, if the domain name is corp.example.com, the LDAP path to type is:
cn=Configuration,dc=corp,dc=example,dc=com
To expand and collapse subcontainers and their object members, double-click containers in
the left pane. To locate the Active Directory Connector resources, expand the Services node,
then Microsoft Exchange, and finally Active Directory Connections.
Chapter 9: Advanced Configuration 87
• ADSIEdit.msc Install the Microsoft Windows® 2000 Server Resource Kit. Alternatively,
you can register the ADSIEdit.dll library (as an in-process server) using Regsvr32.exe, and
then open ADSIEdit.msc, which is an MMC snap-in. The ADSI editor provides an easy–to–
use graphical user interface (GUI), but it is not as powerful as the Ldp utility (ldp.exe).
Changing the LDAP Search

Filter Rule
It is not recommended that you edit the LDAP search criteria manually. The main reason it is not
recommended is that whenever you make any changes to the connection agreement using the
Active Directory Connector Management snap-in, any changes to the filter are lost and will have
to be set again manually.
When configuring a connection agreement, you can set the object class to be included in the
replication cycle. This can be done for Mailbox, Custom Recipient, Distribution List, User,
Contact, and Group objects. When you make this selection, you set an attribute on the connection
agreement called msExchServerXSearchFilter, in which X equals 1 for Active Directory and X
equals 2 for the Exchange 5.5 directory. This string represents an RFC 2254 rule (LDAP search
filter). When you look at this attribute by using a tool, such as ldp.exe, you see the following:
msExchServer1SearchFilter (Active Directory)
(|(objectClass=user)(objectClass=contact)(objectClass=group))
msExchServer2SearchFilter (Exchange directory)
(|(objectClass=organizationalPerson)(objectClass=remote
address)(objectClass=groupOfNames))
The rules query for all recipient objects in the directory (organizationalPerson is a mailbox,
remote-address is a custom recipient, and groupOfNames is a distribution list). The vertical bar,
or pipe, at the beginning of the string indicates this is an OR filter.
Note
For more information about LDAP search filters, see RFC 2254 at
http://www.faqs.org/rfcs/rfc2254.html.
With tools such as ldp.exe, you can modify this rule so that the connection agreement uses a
more granular search criterion than the default when replicating objects between the two
directories. For example, you can configure a specific connection agreement to replicate the
Exchange mailbox objects in the Sales and Marketing departments to Active Directory:
(&(objectClass=organizationalPerson)(|
(department=Sales)(department=Marketing)))
Or, you can have a connection agreement that replicates only users whose last name starts with
the letter A:
(&(objectClass=organizationalPerson)(sn=a*))
Changing the Attribute

Mapping Table
By default, ADC uses its own rule for matching attributes between the two directories. For
example, the Department attribute in the Exchange Server 5.5 directory is mapped automatically
to the department field in Active Directory. In some scenarios, you may want to change this map
for a custom solution. For example, you can map the Exchange Custom-Attribute-3 attribute
(called Extension-Attribute-3 in LDAP) to the Active Directory employeeID attribute.
These matching rules are held on the Default ADC Policy object for ADC (not connection
agreement-specific) in a field called msExchServer1SchemaMap for Active Directory-to-
Exchange mapping and msExchServer2SchemaMap for Exchange-to-Active Directory mapping.
You can view or change this mapping table by using a tool, such as ldp.exe, in binary mode. The
format of the property is very specific, and you must make changes carefully.
Appendixes
A P P E N D I X A
Schema Updates Made by the

Exchange 2000 Server Active
Directory Connector
The schema updates shown in the following tables are applied to a Microsoft® Exchange Server
version 5.5 site when a Microsoft Exchange 2000 Server Active Directory Connector (ADC) is
installed and configured to write to that site. These updates are also applied to a site when a
server is upgraded to Exchange Server 5.5 Service Pack (SP) 3. You must have Schema Admin
permissions to update the schema.
Table A.1 Top class (modify)
Attribute Value
MayContai 1.2.840.113556.1.2.61
n 8
MayContai 1.2.840.113556.1.2.61
n 9
MayContai 1.2.840.113556.1.2.62
n 0
MayContai 1.2.840.113556.1.2.62
n 1
Table A.2 ADC-Global-Names attribute (add)
Attribute Value
objectClass Attribute-Schema
AccessCategory 1
Appendix A : Schema Updates Made by the Exchange 2000 Server Active Directory Connector 91
Attribute Value
AttributeID 1.2.840.113556.1.2.621
AttributeSyntax 2.5.5.12
IsSingleValued FALSE
AdminDisplayName ADC-Global-Names
description msExchADCGlobalNam
es
OMSyntax 64
Heuristics 5
ExtendedCharsAllowed 0
SearchFlags 1
Table A.3 Object-GUID attribute (add)
Attribute Value
AccessCategory 1
AttributeID 1.2.840.113556.1.2.61
8
AdminDisplayName Object-GUID
description objectGUID
MAPIID 35949
OMSyntax 4
Attribute Value
Heuristics 3
SearchFlags 1
Table A.4 Replication-Signature attribute (add)
Attribute Value
AccessCategory 1
AttributeID 1.2.840.113556.1.2.61
9
IsSingleValued TRUE
AdminDisplayName Replication-Signature
description Replication-Signature
MAPIID 35950
OMSyntax 4
Heuristics 3
SearchFlags 0
Table A.5 Unmerged-Attributes attribute (add)
Attribute Value
AccessCategory 1
Appendix A : Schema Updates Made by the Exchange 2000 Server Active Directory Connector 93
Attribute Value
AttributeID 1.2.840.113556.1.2.62
0
AdminDisplayName Unmerged-Attributes
description unmergedAtts
MAPIID 35951
OMSyntax 4
Heuristics 3
SearchFlags 0
Table A.6 Schema-Version attribute (modify)
Attribute V
alu
e
RangeUppe 2506
r
Table A.7 Tagged-X509-Cert attribute (modify)
Attribute Value
Description userSMIMECertificat
e
Heuristics 19
A P P E N D I X B
Manipulating Mailbox to Active

Directory Account Replication
In most Microsoft® Exchange Server version 5.5 environments, there are multiple mailboxes
with the same primary Microsoft Windows NT® 4.0 Server account associated with them. In the
Microsoft Active Directory® directory service, a mailbox is not a directory object, it is an
attribute of a User or Group object. A mailbox-enabled object can have only one mailbox
attribute associated with it. Therefore, for two Exchange 5.5 mailboxes that have the same
primary Windows NT account associated with them to be replicated successfully to Active
Directory, all mailboxes except one need to be marked as resource mailboxes. One account is
either created enabled or matched to an existing Active Directory user account, and the other
mailbox is replicated in as a disabled user account (that is, if Active Directory Connector (ADC)
is set to create disabled users).
Example
In Exchange 5.5 there are two mailboxes: Mailbox1 and Mailbox2. The primary Windows NT
account is User1. When ADC replicates the first mailbox, the attributes of that mailbox will be
set on the Active Directory-enabled user account. Assuming Mailbox1 is replicated first, then
User1 will have its mailbox and other attributes set to match Mailbox1. When Mailbox2 is then
picked up and replicated in, a disabled user account is created with the name of the mailbox alias,
and User1 is the mailbox owner. However, a key attribute, named msExchMasterAccountSid, is
not set on the disabled user because it is already in use on the User1 account.
Solution
Force a disabled user account for Mailbox1. The default for ADC when replicating in two
mailboxes with the same Windows NT account is to link to an enabled user account, and then
create a disabled Active Directory account for the other mailbox.
To link Mailbox2 to User1, and have Mailbox1 be linked to a disabled user account whose
primary mailbox owner is User1, do the following: On the properties of Mailbox1, Custom
Attribute-10, type NTDSNoMatch. This forces a disabled user account for Mailbox1 and
Mailbox2 to be linked to the enabled User1 account. When you set NTDSNoMatch on a mailbox,
this also ensures that the msExchMasterAccountSid value is set on the disabled user. ADC sets
msExchMasterAccountSid to "SELF", which is a reference to the objectSID of the disabled user
itself.
A P P E N D I X C
Attributes of a Connection
Agreement
Use the Ldp utility (ldp.exe) to look at the attributes of the connection agreement in ADC. The
connection agreement objects are located at:
cn=Name of CA,cn=Active Directory Connections,cn=Microsoft Exchange,
cn=Services,cn=Configuration,dc=<domain>
The connection agreement is divided into three groups of attributes:
• General Attributes. Connection agreement object attributes (first section of the output
when viewed with ldp.exe).
• Exchange Server-specific Attributes. Attributes and values associated with the target
Microsoft® Windows® 2000 domain controller. The name of each attribute begins with the
prefix msExchServer1.
• Windows Server-specific Attributes. Attributes and values associated with the target
Microsoft Exchange Server version 5.5 server. The name of each attribute begins with the
prefix msExchServer2.
General Attributes
msExchHomeSyncService
Attribute syntax: single-valued distinguished name
The distinguished name of the ADC service that is responsible for running this connection
agreement.
msExchCASchemaPolicy
Attribute syntax: single-valued distinguished name
The distinguished name of the ADC policy that this connection agreement uses, which
contains the schema maps, object matching rules, and other configuration data.
Normally set to CN=Default ADC Policy,CN=Active Directory Connections,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC<domain>
versionNumber
The version number of the connection agreement. This is used, for example, to ensure that a
Windows 2000 ADC does not try to run an Exchange 2000 Config CA. As of Exchange
2000 Server SP2, the current value is 16908295, or 0x01020008. Connection agreements
created with the commercially released or SP1 version will have a slightly different value.
ActivationStyle
Controls the connection agreement replication.
0 = Never, 1 = selected times, 2 = Always
ActivationSchedule
A bitmap of when the connection agreement is scheduled to run. Each bit is one 15-minute
increment. Begins at 12:00 A.M. (midnight) through 11:45 P.M.
msExchADCOptions
A set of flags that control ADC replication. The flags are:
0x00000004 Replicates secured objects from Active Directory.
0x00000008 Indicates an inter-organizational connection agreement.
0x00000800 Replicates memberships of hidden distribution lists.
0x00001000 Replicates from Windows first on a two-way connection agreement.
msExchDoFullReplication
If True, all objects will be synchronized on the next replication cycle.
msExchIsBridgeheadSite
Specifies whether "This is a primary Connection Agreement for the connected Exchange
Organization." is selected, and thus whether ADC can create new objects in the
Exchange 5.5 directory.
msExchRemotePrivateISList
Contains a list of the Exchange distinguished names of all of the private Information Stores
in the site, separated by the § symbol (Hex 0x00A7).
msExchRemoteServerList
Contains a list of the Exchange distinguished names of the message transfer agent (MTA)
objects for all servers in the site, separated by the § symbol (Hex 0x00A7).
Appendix C : Attributes of a Connection Agreement 97
msExchReplicateNow
If True, ADC performs a replication cycle immediately for this connection agreement. This
flag is usually set by the Active Directory Connector Management snap-in. Because it exists
within the configuration naming context that is replicated around the forest, you can set this
value remotely.
msExchIsConfigCA
Specifies whether or not a connection agreement is a Config CA. Do not modify.
msExchExchangeSite
Contains the Exchange 5.5 distinguished name of the site that the Exchange server is in.
For example: ou=Site,o=org
msExchInterOrgAddressType
For inter-organizational connection agreements, controls whether or not Custom
Recipients/Contacts retain their existing targetAddress when replicated, or if the
targetAddress is updated to the primary SMTP address of the object.
msExchSynchronizationDirection
Specifies whether the connection agreement is one-way Exchange to Windows, one-way
Windows to Exchange, or two-way.
0 = Two-way, 1 = Windows to Exchange, 2 = Exchange to Windows
msExchADCObjectType
Specifies whether a connection agreement is a user connection agreement or a Config CA.
0 = User CA, 1 = Config CA
Windows Server-Specific Attributes

msExchServer1IsBridgehead
Specifies whether "This is the primary Connection Agreement for the connected Windows
Domain." is selected, and thus whether ADC can create new objects in Active Directory.
msExchServer1AlwaysCreateAs
Specifies the type of object ADC should create to represent an unmatched mailbox.
0 = Contact, 1 = Disabled User, 2 = Enabled User
msExchServer1AuthenticationCredentials
The credentials for connecting to the Windows server.
For example: Domain\User name
msExchServer1AuthenticationType
Specifies the authentication protocol to be used.
4 = NTLM (Windows Challenge/Response)
msExchServer1DeletionOption
Specifies whether ADC will replicate deletes from Exchange to Windows.
0 = Replicate deletes, 1 = write deletes to an .ldf file
msExchServer1ExportContainers
Specifies which containers to export from Windows, using the distinguished name of the
container.
msExchServer1Flags
Special flags that apply when replicating with Windows. Defaults to 0.
0x2 = Do not overwrite RDN with the Exchange 5.5 Alias attribute. For more information
about this flag, see Microsoft Knowledge Base article 269843, "XADM: ADC Overwrites
Display Name with Exchange Server 5.5 Display Name"
msExchServer1HighestUSN
Attribute syntax: single-valued large (64 bit) integer
The highest update sequence number (USN) last found against the Windows 2000 domain
controller that the connection agreement is replicating with. ADC uses this value to
determine which objects it has already replicated from Active Directory.
Keeps track of the highest USN of all of the domain controllers in the forest. By keeping
track of the USN values on all servers that correspond with the highest USN on the local
server, if the connection agreement is pointed to a different domain controller, ADC will not
have to do a full replication from Windows.
Note
If your organization has more than 800 domain controllers in the forest, you may
need to set a registry key to control how many values are stored in this attribute.
For more information about this problem, see Microsoft Knowledge Base article
314950, "XADM: The ADC Does Not Work in an Environment That Contains More
Than 800 Domain Controllers" (http://support.microsoft.com/?kbid=314950).
msExchServer1ImportContainer
Specifies the distinguished name of the default destination in Active Directory where ADC
should create new objects.
msExchServer1LastUpdateTime
Attribute syntax: single-valued Generalized-time attribute
Timestamp in Coordinated Universal Time (Greenwich Mean Time) of the last change from
the source Active Directory container that the connection agreement is aware of.
Note
This value is stored only for backward-compatibility reasons, and it is no longer
used. It may not accurately reflect the last update time.
msExchServer1NetworkAddress
The host name of the domain controller that is the Windows endpoint of the connection
agreement.
msExchServer1PageSize
Specifies the Lightweight Directory Access Protocol (LDAP) page size to use when
replicating with Active Directory. The default value is 20.
msExchServer1Port
Specifies the LDAP port to use when connecting to the Active Directory server. The default
port is 389.
msExchServer1SearchFilter
Specifies the LDAP search filter that ADC uses when searching for objects to export from
Active Directory. The value will differ depending on the objects being exported and the type
of connection agreement. For example, for a User connection agreement that is set to
replicate users, groups, and contacts, the value is: (|
(objectClass=user)(objectClass=contact)(objectClass=group))
msExchServer1SSLPort
Specifies the LDAP port used for Secure Sockets Layer (SSL) communications with the
Active Directory server. The default port is 636.
msExchServer1Type
Specifies the type of server.
0 = Active Directory domain controller
Exchange Server-Specific Attributes

msExchServer2AuthenticationCredentials
The credentials for connecting to the Exchange server.
For example: Domain\User name
msExchServer2AuthenticationType
Specifies the authentication protocol that is used.
4 = NTLM (Windows Challenge/Response)
msExchServer2DeletionOption
Specifies whether ADC will replicate deletes from Windows to Exchange.
0 = Replicate deletes, 1 = Write deletes to a .csv file
msExchServer2ExportContainers
Specifies which containers to export from Exchange, using the distinguished name of the
container.
msExchServer2Flags
Special flags that apply when replicating with Exchange. The default is 0.
No special flags currently exist.
Attribute syntax: single-valued large (64 bit) integer
The USN last found against the Exchange server or Site Replication Service (SRS) the
connection agreement is replicating with. ADC uses this to determine which objects it has
already replicated from the Exchange directory.
msExchServer2ImportContainer
Specifies the distinguished name of the default destination in Exchange where ADC should
create new objects.
msExchServer2LastUpdateTime
Attribute syntax: single-valued Generalized-time attribute
Timestamp in Coordinated Universal Time (UTC) of the last change from the source
Exchange container that the connection agreement is aware of.
Note
This value is stored only for backward-compatibility reasons, and it is no longer
used. It may not accurately reflect the last update time.
msExchServer2NetworkAddress
The host name of the Exchange server or SRS that is the Exchange endpoint of the
msExchServer2PageSize
Specifies the LDAP page size to use when replicating with Exchange. The default value is
20.
msExchServer2Port
Specifies the LDAP port to use when connecting to the Exchange server or SRS. The default
port is 389; however, when replicating with an SRS the port is 379. If the Exchange 5.5
server's LDAP port has been changed from 389 to a different value, this attribute must be
changed too.
msExchServer2SearchFilter
Specifies the LDAP search filter that ADC uses when searching for objects to export from
Exchange. The value will differ depending on the objects being exported and the type of
connection agreement. For example, for a User connection agreement that is set to replicate
mailboxes, distribution lists, and custom recipients, the value is: (|
(objectClass=organizationalPerson)(objectClass=remote-
address)(objectClass=groupOfNames))
msExchServer2SSLPort
The LDAP port used for SSL communications with the Exchange server. The default port is
636.
msExchServer2Type
Specifies the type of server.
1 = Exchange 5.5 server or SRS.
A P P E N D I X D
ADC Matching Rules
Active Directory Connector (ADC) can identify objects in two directories, determine whether
they should be linked, and then either write to the objects so that they are linked, or if the
connection agreement is set as primary, create a new object. ADC uses matching rules when
replicating objects. When replicating from Microsoft® Exchange Server version 5.5 to the Active
Directory® directory service, ADC matches when the primary Microsoft Windows NT® Server
account matches the security identifier (SID) or SIDHistory of the Active Directory user.
Table D.1 Default object matching rules
Exchange 5.5 LDAP Active Directory LDAP attribute

attribute
Assoc-NT-Account = ObjectSid
Extension-Attribute-10= Forces a contact to be created for this Exchange 5.5

NTDSContact object
Extension-Attribute- Forces a disabled user account to be created for this

10=NTDSNoMatch Exchange 5.5 object
Assoc-NT-Account = SIDHistory
Important
The only object matching rules tested extensively by Microsoft are the default
matching rules. Microsoft does not support custom object matching rules. You must
test any modifications in a lab environment to ensure that any custom matching rule
behavior meets your needs.
Use ADSIEdit or ldp.exe to view the matching rules. The matching rules are stored on the
Default ADC Policy object in the following container in Active Directory:
CN=Active Directory Connections,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=<Domain>,DC=<com>
Appendix D: ADC Matching Rules 103
The matching rules consist of two attributes:

• MsExchServer1ObjectMatch contains rules for how objects in Active Directory are
matched to Microsoft Exchange 5.5 objects.
• msExchServer2ObjectMatch contains rules for how objects from the Exchange 5.5
directory are matched to objects in Active Directory.
By default, these two attributes are NULL.
Note
The rules that are stored in Active Directory must be one contiguous string; however,
in the following, they have been separated into two lists to make them easier to
read.
Note
The following default matching rules are current as of Exchange 2000 Server SP 3.
Before making changes to the object matching rules, please contact Microsoft
Product Support Services to validate whether the default matching rules are current.
The default values are stored within ADC, and the only way to obtain the current
rules is by contacting Microsoft.
When ADC reads these attributes and determines that no custom matching rules have been
added, it uses the following set of matching rules.
Current Matching Rules for msExchServer1ObjectMatch

Objectmatch#publicFolder$top#person$Public-
Folder$Top#legacyExchangeDN$$exchange_dn#distinguishedName#sid_Match#
ObjectMatch###ObjectSID#Assoc-NT-Account#sid_match#
ObjectMatch###NotNull#objectGUID#veto-previous#
ObjectMatch#$$rootdelimiter#o#
ObjectMatch#$$deletionattribute#Is-Deleted#
ObjectMatch#$$flags#df_tombstone#
Current Matching Rules for msExchServer2ObjectMatch

Objectmatch#person$Public-
Folder$Top#publicFolder$top#distinguishedName#legacyExchangeDN$$exchange_dn#sid_Mat
ch#
ObjectMatch###Assoc-NT-Account#ObjectSID#sid_match EscapeBinaryBlob#
ObjectMatch##user$organizationalPerson$person$top#Extension-Attribute-10#"NTDS
Contact"#veto-previous#
ObjectMatch##user$organizationalPerson$person$top#Extension-Attribute-
10#"NTDSNoMatch"#veto-previous#
ObjectMatch###NotNULL#legacyExchangeDN#veto-Previous#
ObjectMatch###Assoc-NT-Account#sidhistory#sid_match EscapeBinaryBlob#
ObjectMatch##user$organizationalPerson$person$top#Extension-Attribute-10#"NTDS
Contact"#veto-previous#
ObjectMatch##user$organizationalPerson$person$top#Extension-Attribute-
10#"NTDSNoMatch"#veto-previous#
ObjectMatch###NotNULL#legacyExchangeDN#veto-Previous#
ObjectMatch#$$rootdelimiter#dc#
ObjectMatch#$$deletionattribute#IsDeleted
Format of ADC Matching Rules

The format of the matching rules is as follows:
name#soc#toc#sa#ta#flags#
Table D.2
N
ObjectMatch
ame
soc Source object-class value
toc Target object-class value
sa Source attribute or attribute value
ta Target attribute or attribute value
flags Flags that define the behavior of this matching rule
The following are descriptions of each of the fields in a matching rule.

Name value
The name value is the Section Name, and it must be set to "ObjectMatch".
Object-class value
Must contain the entire object-class hierarchy with a dollar delimiter ($) between each
object-class. For example:
user$organizationalPerson$person$top
If the object-class value is left blank, it is assumed that all objects apply.
Attribute value
There are five possible formats that you can use as the attribute value:
• Direct attribute:
ldap-display-name
For example: mailNickname
Appendix D: ADC Matching Rules 105
• Value of an attribute with a prefixed string, for which the format is:
[PREFIX] ldap-display-name
For example: [SMTP:] mail
• Converting an LDAP distinguished name to an X500 distinguished name, for which the
format is:
ldap-display-name$$exchange_dn
For example: distinguishedName$$exchange_dn
• Any string value that is enclosed in quotes
• NotNULL
If you set this as the source attribute, the rule applies when the target attribute has any
value except NULL.
Flags
You can set the following flags to control the behavior of the rule:
• Match Types
sid_match - Ensures that data loss is prevented, such as do not propagate deletions to the
target value even if the source value is empty.
guid_match - Assumes that the two objects that are being synchronized have been
previously matched. This is normally only used internally by ADC for matches based on
ADC Global Names.
• veto-previous - Vetoes the previous matching rule but continues with the next matching
rule.
• EscapeBinaryBlob - Used in conjunction with either sid_match or guid_match flags
when the source value is in ASCII and the target value is in binary.
Modifying Object Matching Rules

You can modify the object matching rules using ldp.exe or ADSIEdit, by modifying the values of
msExchServer1ObjectMatch and/or msExchServer2ObjectMatch.
For example, suppose you need to change the matching rules because Extension-Attribute-10 is
already in use in your directory. You need to specify a different attribute for marking resource
mailboxes with NTDSNoMatch. Also, you already have the value Resource set in Extension-
Attribute-9 on all of the resource mailboxes. You could add the following rule to veto a match if
Extension-Attribute-9 is set to Resource:
ObjectMatch###user$organizationalPerson$person$top#Extension-Attribute-
9#"Resource"#veto-previous#
After you add the rule to the default rules, and remove the line breaks, the string for
msExchServer2ObjectMatch reads as follows (new lines added are bold):
New value for MsExchServer2ObjectMatch

Objectmatch#person$Public
Folder$Top#publicFolder$top#distinguishedName#legacyExchangeDN$$exchange_dn#si
d_Match#ObjectMatch###AssocNTAccount#ObjectSID#sid_match
EscapeBinaryBlob#ObjectMatch##user$organizationalPerson$person$top#Extension
Attribute10#"NTDS Contact"#veto
previous#ObjectMatch##user$organizationalPerson$person$top#Extension
Attribute10#"NTDSNoMatch"#veto
previous#ObjectMatch###user$organizationalPerson$person$top#Extensi
on-Attribute-9#"Resource"#veto-
previous#ObjectMatch###NotNULL#legacyExchangeDN#veto
Previous#ObjectMatch###AssocNTAccount#sidhistory#sid_match
EscapeBinaryBlob#ObjectMatch##user$organizationalPerson$person$top#Extension
Attribute10#"NTDS Contact"#veto
previous#ObjectMatch##user$organizationalPerson$person$top#Extension
Attribute10#"NTDSNoMatch"#veto
previous#ObjectMatch###user$organizationalPerson$person$top#Extensi
on-Attribute-9#"Recource"#veto-
previous#ObjectMatch###NotNULL#legacyExchangeDN#veto
Previous#ObjectMatch#$$rootdelimiter#dc#ObjectMatch#$$deletionattribute#IsDele
ted#
In the preceding example, a string has been added that specifies that if custom attribute 9 has a
value of AddedNoMatch, the previous matching rule should be ignored. This creates a disabled
user account for the Exchange Server 5.5 mailbox. Note that the line is added twice. The first
occurrence overrides a match on objectSID, and the second overrides a match on SIDHistory.
If you want to edit the object matching rules, perform the following steps:
1. Edit the original matching rules, provided at the beginning of this section, so that the new
matching string is included. Use a text editor with wordwrap turned off, so that no special
characters are included other than the carriage returns.
2. Start ADSIEdit and connect to the Active Directory Connections container.
3. Expand the Configuration node and then expand the second Configuration node.
4. Expand Services, expand Exchange, and then expand Active Directory Connections.
5. Right-click CN=Default ADC Property, and then click Properties.
6. In the Select the property to view list, choose msExchServer2ObjectMatch.
7. Paste the entire object matching rules string into the Edit Attribute box.
8. Click Set, click Apply, and then click OK.
9. Restart the ADC service.
A P P E N D I X E
Viewing and Modifying the

Attribute Mapping
The Active Directory Connector (ADC) schema map is stored in the Default ADC Policy entry in
the Configuration container of the Microsoft® Active Directory® directory service. This entry is
found in Active Directory at the following location:
CN=Default ADC Policy,CN=Active Directory Connections,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=dcname
The schema map has two attributes:
• msExchServer1SchemaMap Represents mapping from Active Directory to Microsoft
Exchange Server 5.5.
• msExchServer2SchemaMap Represents mapping from Exchange Server 5.5 to
Active Directory.
Because the Exchange 5.5 and Active Directory schemas are different, a set of rules is needed to
allow the attributes in both directories to be populated properly. The primary purpose of the
attribute mapping rules is to provide this set of rules.
These attributes are populated when you install the first ADC in a forest. Two files named
Remote.map and Local.map store the information that is imported to the ADC schema map. The
Remote.map file contains the values for the msExchServer1SchemaMap attribute, and the
Local.map file contains the values for the msExchServer2SchemaMap attribute.
These files are located on the Microsoft Windows® 2000 Server CD in the folder
Valueadd\Msft\Mgmt\Adc. If you want to edit these files before you install ADC, copy
everything in the Valueadd\Msft\Mgmt\Adc folder to a temporary folder, make the necessary
changes to the files, and then install ADC from the temporary folder.
The ADC Setup program does not replace these attributes if the Default ADC Policy entry
already exists. If you have already installed ADC and you want to make changes to these files,
you must delete all of the connection agreements, as well as the Default ADC Policy entry,
before you run the ADC Setup program.
You can also replace the attributes by using a tool that loads a file into an attribute, such as the
Lightweight Directory Access Protocol (LDAP) Data Interchange Format Data Exchange
(LDIFDE) tool. First you need to encode the file in a Base64 format. For more information about
how to Base64 encode, see Microsoft Knowledge Base article 191239, "Sample Base 64
Encoding and Decoding" (http://support.microsoft.com/?kbid=191239).
To view and/or modify the attribute mapping, you need to use a utility, such as ADSIEdit or
ldp.exe, that can read/write to Active Directory. You will also need read/write permissions to the
Active Directory Connections container. It is suggested that you use ADSIEdit to modify the
mapping attributes. You must have permissions to view and modify the configuration naming
context, such as Enterprise Admin or Full Exchange Administrator.
To use ldp.exe to view or modify the attribute mapping between
Exchange 5.5 and Active Directory
1. Connect to a domain controller on port 389.
2. Click Options, click General, and change Value Parsing from String to Binary.
3. Navigate the directory hierarchy to the Active Directory Connections container.
4. Right-click Default ADC Policy and click Search. This should populate the Base
distinguished name to be equal to the distinguished name for the Default ADC Policy
container.
5. On filter type "(objectClass=*), choose Base for Scope, then click Options. In the Attribute
field type msExchServer2SchemaMap. Click OK, then click Run.
This will display the entire attribute mapping for Exchange Server 5.5 to Active Directory to the
right side of the screen. To view the attribute mapping for Active Directory to Exchange 5.5,
complete the preceding steps, but type msExchServer2SchemaMap instead of
msExchServer1SchemaMap.
ADSIEdit is a more intuitive interface for making changes to the attribute mapping. ADSIEdit
provides a non-hexadecimal format, which means that the attribute mapping is now readable and
editing is easier.
To view or edit the mapping attributes using ADSIEdit
1. Connect to a domain controller with ADSIEdit.
2. Traverse the directory hierarchy to the Active Directory Connections container.
3. Click the Active Directory Connections node.
4. Right-click CN=Default ADC Policy, and then click Properties.
5. On the Attributes tab, click the Select a property to view drop-down list. Choose
msExchServer1SchemaMap to display the attribute mapping for Active Directory to
Exchange Server 5.5 replication in the Value field.
6. Put the cursor at the beginning of the value and highlight the entire string. Copy and paste
the string to a text file. Turn off wordwrap before you paste the string.
To view and or change the attribute mapping from Exchange Server 5.5 to Active Directory,
complete the preceding steps, but choose msExchServer2SchemMap.
Appendix E: Viewing and Modifying the Attribute Mapping 109
Changing the Attribute

Mapping Rules Manually
Changing any of the attribute mapping schemes can have adverse effects and can possibly cause
data corruption in the Exchange 5.5 directory or Active Directory. You should carefully consider
and test changes prior to deployment. All information extracted from ldp.exe will be in
hexadecimal format. If you upgrade service packs, you must reapply the custom mapping, using
the new map files that were introduced with the new service pack.
Note
Microsoft Product Support Services may ask that you reapply the default rules if they
believe that custom rules may be causing a problem.
Syntax of Schema Map Files

The following is the syntax for each line in the schema map files:
comment#srcclass#tgtclass#srcattr#tgtattr#prefix#dnsyntax#flags#
The first field in the schema map syntax is a comment, and you can ignore it. The second and
third fields are the source and target object class. You can omit these fields if you want the rule to
apply to all entries, or you can specify both the source and target object class to which the rule
applies. You cannot specify only the source object class or only the target object class. Table E.1
contains definitions for all of the fields in the preceding example.
Table E.1 Definition of fields in an object matching rule
Field Definition
comment Field is ignored and can contain anything
src-class The source object class (optional)
tgt-class The target object class (optional)
src-attr The source attribute name
tgt-attr The target attribute name
prefix SMTP$ or X400$ (special case for proxy address fields)

Field Definition
dn-
A distinguished name-linked attribute
syntax
flags A set of special flags (see Table E.2)
Examples of Syntax for src-class and tgt-class Object Class Fields

The following example is a rule that applies to all object classes.
mycomment###...
The following example is a rule that applies when you want to replicate a group from Active
Directory to a distribution list on the Exchange Server 5.5 directory. Separate all values with a $
to create the object-class format that ADC uses.
mycomment#group$top#groupofnames$person$top
The following example is the reverse of the replication in the second example. Here, the source is
an Exchange Server 5.5 distribution list and the target is an Active Directory group. The source
and target attribute name fields specify the Lightweight Directory Access Protocol (LDAP) name
of the attribute.
mycomment#groupofnames$person$top#group$top#...
Examples of Syntax for src-att and tgt-attr Attribute Name Fields

The following example is an attribute that applies to all object classes. In this example "title"
does not apply to either groups or to distribution lists. In this case, you can add most of the
attributes without any object-class specification.
comment###title#title#...
The following is an example of one attribute that has a different name in Active Directory and
Exchange Server 5.5.
comment###otherMailbox#ProxyAddresses#...
The following example only applies when ADC replicates a distribution list on Exchange
Server 5.5 to a group in Active Directory, and this schema map syntax maps the member attribute
between them. If you do not want the member attribute to be replicated between distribution lists
and groups, remove this line from the file.
commentl#groupofnames$person$top#group$top#member#member#...
The prefix field is used only in one special case. Do not use the prefix field except as it is used in
the following lines in the Local.map file:
local###mail#ProxyAddresses#SMTP$##120#
local###textEncodedORAddress#ProxyAddresses#X400$##120#
The preceding schema map syntax indicates that when the mail attribute on Exchange Server 5.5
is replicated to the proxyAddresses attribute in Active Directory, the attribute should be added
with the "SMTP$" prefix. The dn-syntax field indicates that the attribute that ADC is replicating
is a distinguished name-linked attribute, and therefore the distinguished name must be resolved
before the attribute is added. For example:
remote#...#...#manager#manager##DN#2#
Flags
The flags field uses a set of flags that indicates how ADC works in certain situations, or whether
or not the Active Directory Connector snap-in displays each attribute. Table E.2 describes each
flag.
Table E.2 Description of flags used in an object matching rule
Flag Description
0x000
Maps a multivalued attribute to a single-valued attribute
1
0x000
Lazy DN conversion
2
0x000
Maps a single-valued attribute to a multivalued attribute
4
0x000
Concatenates a multivalued attribute to a single-valued attribute
8
0x001
Disables replication
0
0x002
The source attribute is an ADC internal attribute
0
0x004
The target attribute is an ADC internal attribute
0
0x010
Hides the attribute in the Active Directory Connector Management snap-in
0
0x020
Merges the attribute into the target (instead of replacing it)
0
0x040 Distinguished name attribute that can only be resolved if Exchange 2000 Server is
0 installed
0x080
Allows mapping of strings to distinguished names and distinguished names to strings
0
Note
The 0x800 flag was introduced with the Service Pack 1 version of ADC.
To combine flags, add the value of the flags and use the hexadecimal number that results
(without "0x"). To best use these flags, observe the way that they are used in the Remote.map and
Local.map files. The following list describes the most important flags:
• The lazy DN conversion flag (0x0002) causes ADC to postpone the resolution of the
attribute, so that resolution of the attribute is the last operation that ADC performs before
ADC replicates the entry. This improves performance because all linked distinguished names
are resolved at the end of the process with fewer searches to the directory service.
• The disable replication flag (0x0010) has the same effect as removing the line from the file.
The Active Directory Connector Management snap-in sets or resets this attribute every time
that you clear or select this attribute to be replicated.
• The hide from the UI flag (0x0100) hides the attribute in the MMC snap-in so that the
attribute cannot be disabled or enabled.
When ADC determines which rule to use to map an attribute, the first choice is a rule that is
complete with object class. If ADC finds such a rule, it uses that rule. If ADC does not find such
a rule, the next choice is a generic rule (without an object class).
Validating Object-Class Matches

In addition to providing rules that allow the attributes in both the Exchange 5.5 directory and
Active Directory to be populated properly, the schema map has a second purpose: to validate
object class matches. For example, if ADC begins to map a distribution list to a user (mapping a
distribution list to a user is invalid), ADC searches the schema map to see if at least one rule is
specified for that mapping. If a rule is specified, the mapping is considered a valid match; if no
rules are specified, the mapping is invalid.
Unmerged Attribute Cleanup

During ADC replication, sometimes ADC needs to write an attribute that is a link to another
attribute in the directory. These are called DN-linked attributes. You cannot write a value to a
DN-linked attribute unless the object to which you are linking exists.
Suppose that a user is a member of a distribution list in Exchange Server 5.5. When you set up
ADC, if the user replicates before the distribution list, ADC is unable to set the member attribute
on the group before the user exists. ADC uses two attributes, unmergedAttributes and
msExchUnMergedAttsPT, to store the unresolvable link on the group until it is able to resolve the
user and add it to the member attribute.
ADC tries to re-resolve the links periodically. ADC will try to resolve the links under the
following circumstances:
• MsExchDoFullReplication=True
• msExchReplicateNow=True
• Every 12 hours during a connection agreement uptime
ADC uses the msExchADCGlobalNames attribute to resolve links. For example, to add User1,
whose Exchange 5.5 distinguished name is "cn=user1,cn=Recipients,ou=Site,o=Org", a group in
Active Directory, ADC uses an LDAP query to find the matching object. The query is:
(msExchADCGlobalNames=EX5: cn=user1,cn=Recipients,ou=Site,o=Org*).
If the user does not have msExchADCGlobalNames in the target directory, ADC cannot resolve
the link.
Specifying an Authoritative
Attribute Source
In certain circumstances, an attribute or attributes must be set as the authoritative source for
changes. One such circumstance is when you have specialized programs that write to
Exchange 5.5, and you have not had the opportunity to adapt the program to write to Active
Directory. Another circumstance is when you have developed a program to write to Active
Directory and want changes to certain attributes to be written or modified only from Active
Directory. Specifying an authoritative attribute source allows all changes that are made to certain
attributes from one directory to be authoritative over the other directory. To modify this behavior,
you need to understand which attributes map from Exchange 5.5 to Active Directory and from
Active Directory to Exchange 5.5. See the information at the beginning of this appendix.
Note
If you disable replication for any attribute, you should test that change completely
before deploying.
The following procedure indicates how you can force an attribute to be the authoritative source.
In this procedure, the goal is to modify the attribute mapping rules to force the telephone number
from Exchange 5.5 to be the authoritative source.
To force an attribute to be the authoritative source
1. In the Active Directory Connection Management snap-in, right-click Active Directory
Connection Management and click Properties.
2. On the From Windows tab, clear the telephoneNumber check box.
3. Click OK and exit the snap-in.
The attribute is mapped to Active Directory and replicated, but only the changes in Exchange 5.5
for this attribute are replicated.
A P P E N D I X F
Move Server Wizard
There are situations where the Microsoft® Exchange Server version 5.5 Move Server Wizard is
needed in a mixed environment to help collapse two organizations, or modify an existing
organization. Using the Move Server Wizard after deploying Active Directory Connector (ADC)
can cause adverse effects, such as deleted Microsoft Active Directory® directory service
accounts.
For example, if a particular Exchange 5.5 site is being synchronized with Active Directory and
the Move Server Wizard is run, all mailboxes that are associated with the server that is being
moved have a delete issued for them. They are re-created in the target organization and site.
When ADC picks up the delete, it replicates the delete into Active Directory and issues a delete
for the corresponding Active Directory account. If the server is moved into another site in the
same organization, ADC will not synchronize the two directory objects. This is because ADC
determines that the object has been deleted and should no longer be replicated.
Note
Using the Move Server Wizard to move a server from one site in an organization to
another site in the same organization is not supported if the objects are being
synchronized with ADC.
To avoid having ADC replicate the deletes into Active Directory, make sure that the connection
agreement that is responsible for replicating the objects on this server has the delete option set to
write to an .ldf file. (Do not import this file after the Move Server Wizard has been used.) Setting
the delete option to write to an .ldf file will prevent ADC from replicating the deletes, and when
the server is moved to the target site the objects will be synchronized.
Note
If deletions were not set to write to a file, and ADC removes the Active Directory
objects, perform the following operations:
1. On the Exchange 5.5 server that was moved, export all objects that were being
replicated using ADC.
2. Open the .csv file created by the export with a text editor or with Microsoft Excel
and remove all of the ADC-Global-Names values for all objects.
3. Import the .csv file using the Exchange 5.5 Administrator program.
When you have completed the three preceding steps, ADC will be able to synchronize
the objects.
If you use the Move Server Wizard to remove an Exchange 5.5 site from a mixed organization
that is being synchronized with ADC, it is recommended that you replicate the deletes. Also, if
you use the Move Server Wizard to move an Exchange 5.5 server from one organization into a
mixed organization, it is recommended that you move the server into a non-mixed site.
A P P E N D I X G
Replicating Distribution Lists

and Groups
Exchange 5.5 Distribution Lists

In Microsoft® Exchange Server version 5.5, a distribution list can have as a member a mailbox
from any site in the organization or another distribution list. This nesting of distribution lists is
not limited, and there are no special requirements for the mailboxes. If a mailbox exists in the
organization, it can be a member of a distribution list. Exchange distribution lists are used for two
functions in Exchange 5.5: as e-mail distribution lists and for specifying access control lists
(ACLs) on public folders.
Windows NT 4.0 Groups

Although Microsoft Windows NT® Server version 4.0 groups are not used extensively within
Exchange 5.5, Windows NT 4.0 supports two types of groups. Both are only security-related and
do not incorporate any e-mail functionality. Characteristics of the groups are as follows:
• Domain Local groups can have membership from any trusted domain, but the scope of the
group is restricted to the local domain. That is, it can only be used to set permissions on a
resource that exists in the same domain as the group itself. Domain local groups cannot be
nested.
• Domain Global groups can have membership from only the local domain, but they have a
global scope. Domain global groups can be referenced in ACLs on resources in any domain.
There is no group type that corresponds to the membership and scope of an Exchange 5.5
distribution list. Domain global groups can have one level of nesting.
Windows 2000 Groups

Microsoft Windows® 2000 Server, like Windows NT 4.0, has domain local and domain global
groups. It adds a new group type, as well as the ability to associate an e-mail address with a
group (mail-enable). The new group type is called universal groups. Universal groups support the
nesting and membership behavior that exists in Exchange 5.5 distribution lists; membership can
be from any domain and the group can be referenced in any domain.
Distribution Groups vs. Security

Groups
In Windows 2000, a group can be mail-enabled, security-enabled, or both. A group that is mail-
enabled is called a distribution group, a group that is security-enabled is called a security group,
and a group that is both is called a mail-enabled security group. Under certain circumstances, you
can convert a distribution group into a mail-enabled security group. For a group to be used to set
permissions on a resource, you must convert the group to a security group.
Windows 2000 Domain Modes and

Group Restrictions
Windows 2000 domains can operate in either mixed or native mode. In mixed mode, the domain
may contain Windows NT 4.0 domain controllers, and it is therefore restricted to supporting only
the group types that Windows NT 4.0 supports. This means that mixed-mode domains cannot
support universal security groups. Universal security groups (USGs) are only supported in
native-mode Windows 2000 domains. In a native-mode Windows 2000 domain, all of the domain
controllers run Windows 2000, and the native mode setting is enabled.
Active Directory Connector and

Distribution Lists
Active Directory Connector (ADC) replicates all Exchange 5.5 distribution lists to Active
Directory as universal distribution groups (UDGs). This group type was selected because the
majority of distribution lists in Exchange 5.5 are used only as distribution lists, not in ACLs. This
means that, immediately after ADC replicates the Exchange 5.5 distribution lists to Active
Directory, they can be used as e-mail distribution groups, but not for assigning permissions in
ACLs.
Access Control Lists and Groups

Because Exchange 5.5 public folders have ACLs and public folders can be replicated to
Exchange 2000, Exchange 2000 needs to be able to represent the permissions that were set in
Exchange 5.5. In the case of folders secured with a distribution list, Exchange Server cannot use
the universal distribution group that ADC created because the group is not a security group.
Appendix G: Replicating Distribution Lists and Groups 119
Universal Security Groups with Mixed-mode

Membership
Windows 2000 supports a USG that has member objects that exist in mixed-mode domains
(though the USG itself must be in a native-mode domain). When a user logs on to a mixed-mode
Windows 2000 domain, a token is constructed that contains the user object's security identifier
(SID) and the SIDs of any global groups of which it is a member. USG membership is only
evaluated at logon and included in the token when the user object exists in a native mode
Windows 2000 domain.
Token Augmentation
To support the interoperation of Exchange Server 5.5 and Exchange 2000 Server, Windows 2000
contains logic to extend the token of the mixed-mode Windows 2000 user to include the SIDs of
the USGs of which it is a member. The logic augments the token as necessary, taking into
account whether the user is in a native-mode or mixed-mode Windows 2000 domain and whether
a disabled user object is involved. For more information about token augmentation and disabled
users, see "Added Complexity from Disabled Users and Mailbox Rights" later in this appendix.
Converting Universal Distribution

Groups to Universal Security Groups
In an Exchange 5.5 environment, you can use a subset of Exchange distribution lists to set
permissions on public folders and mailboxes. To provide this feature in Exchange 2000,
Exchange 2000 allows Windows security groups to be used to set permissions on public folders
and mailboxes. However, overuse of Universal Security Groups when in native-mode
Windows 2000 can lead to slower login response times. Therefore, Exchange 2000 is selective
about converting UDGs to USGs, and only converts UDGs that are being used to set permissions
on public folders or mailboxes.
The conversion process occurs at three points: during upgrade from Exchange 5.5, during public
folder replication with Exchange 5.5, and whenever a user defines permissions on an
Exchange 2000 public folder or mailbox and specifies a distribution group. The Exchange 2000
information store will log events regarding the success or failure of these conversions, and also
evaluate the nested nature of distribution groups.
Disconnecting User Domain Upgrades

from Exchange 2000 Deployment
A primary feature of Exchange 2000 is to allow the installation of Exchange 2000 prior to
converting to Windows 2000 native mode across the Windows 2000 forest. Although USGs do
require a native-mode domain, you can deploy a dedicated native-mode "group management
domain" that is used as the target of an ADC connection agreement for distribution lists. Because
the domain is in native mode, you can successfully convert the UDGs into USGs as necessary,
without impacting the user authentication domains. After the user domains have been upgraded
to native mode, you can move the groups into that domain and you can then remove the group
management domain from the forest.
Added Complexity from Disabled

Users and Mailbox Rights
In some deployments there are instances in which the Exchange 2000 mailbox is actually a
disabled user object, and mailbox rights have been assigned to a user object (or Windows NT 4.0
account) in a trusted domain. This complicates the token augmentation logic because it will need
to check for the presence of the Exchange Master Account SID in the other forest and acquire the
corresponding disabled user object. The disabled user object, not the trusted account, will be a
member of the USG.
After the object is acquired, the augmentation logic can continue, adding the SIDs of the USGs
of which this disabled user is a member to the token. Additionally, when disabled users are used
and the mailbox rights are assigned to a user in a native-mode domain, the
msExchAddGroupsToToken attribute must be set to force the token augmentation logic to be
invoked.
For more information about associating an Exchange 2000 mailbox with a Windows NT user, see
Microsoft Knowledge Base article 278888, "XADM: How to Associate an Exchange 2000
Mailbox with a Windows NT 4.0 Account"
Moving Groups from a Mixed-mode

Domain to a Native-mode Domain
If ADC was originally configured to replicate distribution lists into a mixed-mode domain, you
can move those groups into a native-mode domain using the following procedure:
1. Stop ADC.
2. Export all distribution lists from Exchange Server 5.5 to a .csv file.
3. Delete the object-GUID and ADC-Global-Names attributes using the procedure described in
the Microsoft Knowledge Base article 152854, "XADM: Using Bulk Import to Remove
Data" (http://support.microsoft.com/?kbid=152854).
4. Import the .csv file into Exchange 5.5.
5. Use Active Directory Users and Computers to find and delete all mail-enabled groups that
were created by Active Directory Connector.
6. Change the destination container on the From Exchange tab to be the native-mode domain
for the connection agreement replicating groups.
Appendix G: Replicating Distribution Lists and Groups 121
7. Wait for the actions performed in Step 4 to replicate to the Exchange 5.5 server to which
ADC is connected.
8. Start ADC.
A P P E N D I X H
Four Test Topologies
The testing for Universal Security Groups (USGs) and Public Folder Access Control Lists
(ACLs) falls into four basic topologies. Each topology is shown below with a brief explanation
of the elements that differentiate it from the other topologies. These diagrams represent minimum
installations, and you should do additional testing prior to deploying them in a production
environment.
• Single Native–mode Domain This is the simplest case, in which all user and group
objects are in a native-mode domain. The Microsoft® Exchange 2000 Server store can
convert the universal distribution groups into universal security groups. When the
Exchange 2000 store is evaluating an ACL, the token augmentation logic path does not need
to be invoked, because the user's token will already include the USGs. A variation on this
topology is a forest of multiple native-mode domains.
Figure H.1 Topology One: A fully-upgraded domain

Appendix H: Four Test Topologies 123
• Group Management Domain This scenario probably represents the majority of

customers upgrading from Microsoft Exchange Server version 5.5, as well as many new
customers. The user objects and the Exchange 2000 servers may be in mixed-mode
Microsoft Windows® 2000 Server domains. In order to have universal security groups, there
must be at least one native-mode "group management" domain in the topology that will be
used to host groups. The token augmentation logic is used to add the security identifiers
(SIDs) of the USGs of which the user object is a member into the token prior to evaluation.
Figure H.2 Topology Two: Upgrading from Windows NT 4.0 domains

• Trusts Spanning Forest This topology is useful in a situation in which the user is
logging on with credentials from an explicitly trusted domain and accessing an
Exchange 2000 server in a different forest. The result is an Exchange 2000 disabled user
object that has mailbox rights assigned to an enabled user object in the trusted authentication
domain. This added level of complexity is dealt with through the Exchange Master Account
SID attribute. The token augmentation code determines that this situation exists, finds the
corresponding disabled user object, and augments the token with the SIDs of the universal
security groups of which that object is a member.
Figure H.3 Topology Three: Trusts spanning forests

Appendix H: Four Test Topologies 125
• Windows 2000 Domains Trusting Windows NT 4.0 Domains This topology

depicts a situation in which a new Windows 2000 domain is introduced in parallel to the
original Microsoft Windows NT® Server version 4.0 domain. As a result, a disabled user
object in the domain with Exchange 2000 has mailbox rights assigned to a Windows NT 4.0
account in the trusted authentication domain. As in the topology shown in Figure H.3, the
added level of complexity is dealt with through the Exchange Master Account SID attribute,
and the augmentation logic takes this into account.
Figure H.4 Topology Four: Parallel environment trusting Windows NT

4.0 domains
A P P E N D I X I
Inter-Organization Connection
Agreement
You can set the inter-organization connection agreement option on the Advanced tab of a
connection agreement properties sheet. This option allows Microsoft® Exchange Server
version 5.5 and Microsoft Exchange 2000 servers that are in two separate Exchange
organizations to replicate information. The inter-organization option doesn't handle how objects
are created; it primarily handles how proxies are generated (they are not generated with the inter-
organization option).
If the inter-organization option is not selected, Active Directory Connector (ADC) does not:
• Match Custom Recipients to a mailbox-enabled user.
• Match a mailbox to a user that is only mail-enabled.
• Stamp msExchMasterAccountSID or legacyExchangeDN.
Arbitrating Changes
ADC arbitrates changes to ensure that changes in either the Exchange 5.5 directory or the Active
Directory® directory service are synchronized.
Note
ADC only arbitrates changes when a two–way connection agreement is set. Using
two one-way connection agreements to achieve two-way replication is not supported.
ADC processes changes or creations in several different ways. When a two-way connection
agreement is scheduled to replicate or initiated using "Replicate Now", the ADC service reads the
properties of the connection agreement from Active Directory.
ADC searches the Exchange 5.5 server for objects that are in an export container, and whose
update sequence number (USN) values are greater than what is stored in
msExchServer2HighestUSN.
Appendix I: Inter-Organization Connection Agreement 127
1. If there are changes to replicate, ADC looks at each object that has changed, then goes to the
target object based on the msExchADCGlobalNames value on the source object.
a. If the source Exchange object does not have msExchADCGlobalNames, ADC finds a
match or creates a new object. For more information about the process, see "How Active
Directory Connector Finds, Matches, and Links Objects" in Chapter 7.
b. ADC compares the msExchServer1HighestUSN value on the connection agreement
with the USN of the target object to determine if the target object has been modified.
c. If the target object has not been modified, the change from Exchange 5.5 is written to
the Microsoft Active Directory® directory service object. If the Active Directory object
has been modified and the USN changed is greater than that of the one in Exchange 5.5,
ADC does not write the change and waits for Active Directory to Exchange 5.5
replication.
d. If the USN change on the Active Directory object is equal to the USN change on the
Exchange 5.5 object, ADC uses the whenChanged attribute on each object to determine
which change is newer. ADC uses the currentTime attribute from the Exchange 5.5 and
global catalog server to compensate for any time differences between the servers. If the
Exchange 5.5 change is most recent, it is written to the Active Directory object. If the
Active Directory object is most recent, the connection agreement waits for the Active
Directory to Exchange 5.5 replication.
2. ADC replicates changes from Active Directory to Exchange 5.5. ADC compares the
msExchServer1HighestUSN value against the USN values associated with the objects in the
Active Directory export containers.
3. If there are changes to replicate, ADC checks each object that is changed, then goes to the
target object based on the msExchADCGlobalNames value on the source object.
a. If the source Active Directory object does not have msExchADCGlobalNames, ADC
finds a match or creates a new object. For more information about the process, see
"How Active Directory Connector Finds, Matches, and Links Objects" in Chapter 7.
b. If the Active Directory object has a higher USN changed value than the Exchange 5.5
object, Active Directory writes the change. If there is a conflict, the ADC service
compares the whenChanged timestamps of the objects using the currentTime attribute to
compensate for time differences. If any of the same objects have been changed, the
previous conflict resolution will be known, and only those objects in Active Directory
that are newer will be written.
Using two one-way connection agreements that have overlapping import and export containers to
achieve two-way replication is not supported. For example, suppose you have a From Exchange
to Windows connection agreement set up that is replicating the Site\Recipients container to a
default import container of Domain\Users. You cannot set up another one-way From Windows to
Exchange connection agreement that has Domain\Users as an export container. To achieve the
two-way replication required for mixed sites, you must use a two-way connection agreement.
There are several reasons for this requirement:

• The logic of the one-way connection agreement was not designed to support two-way
replication. A one-way connection agreement assumes that the source object is authoritative,
and the target object is not. A two-way connection agreement treats the objects in both
directories as possible sources.
• One-way connection agreements do not support timestamp checking. Timestamp checking is
the process that a two-way connection agreement uses to ensure that if matching objects are
modified in both directories between replication cycles, the most recent change will apply.
• Two-way connection agreements support back-replication suppression, where the
objectVersion and replicatedObjectVersion attributes of the objects are checked in both
directories before replication. This ensures that if ADC was the last process to modify an
object, ADC does not replicate that change back to the original directory. You cannot
guarantee this behavior with two one-way connection agreements, and thus two one-way
connection agreements can cause replication loops, where both the Exchange and Windows
objects are modified continually.
Example
You have two connection agreements: "Exchange 5.5 to Active Directory" and "Active
Directory to Exchange 5.5". Exchange 5.5 to Active Directory is scheduled to replicate at
24:00 Eastern Standard Time, and Active Directory to Exchange 5.5 is scheduled to replicate
at 24:01 Eastern Standard Time. A change is made to an Exchange 5.5 object at 23:55
Eastern Standard Time, and a change is made to the corresponding object in Active
Directory at 23:54 Eastern Standard Time.
In this situation, the newest change is in Exchange 5.5; however, the change that is on the
object after both have replicated is the change made to the Active Directory object. This is
because the Exchange 5.5 to Active Directory connection agreement replicates its change at
24:00 Eastern Standard Time and is unable to arbitrate the changes. Then the Active
Directory Exchange 5.5 connection agreement replicates. Unable to arbitrate the changes,
the Active Directory Exchange 5.5 connection agreement writes its changes to Exchange 5.5.
The end result is that the oldest change is written.
Replication Loop Prevention

ADC also contains logic to prevent replication looping. Replication loop prevention works in the
following manner. When replicating changes from Exchange 5.5 to Active Directory, ADC
calculates the information from the replication metadata. The calculated value is stored in the
attribute replicatedObjectVersion of the Active Directory object. When replicating changes from
Active Directory to Exchange 5.5, ADC calculates the information in the Exchange 5.5 object-
version. This information is stored on the replicated-object-version attribute on the Exchange 5.5
object. If the object-version matches the replicated-object-version, then ADC will not replicate
the object, because this means the object has not changed since the last replication. ADC will
only replicate the object if the object-version is a higher value than the replicated-object-version.
Appendix I: Inter-Organization Connection Agreement 129
Additional Registry Keys for

ADC
All of the following registry values are stored in this registry key:
HKLM\System\CurrentControlSet\Services\MSADC\Parameters
Note
Making changes to the registry should normally be done to resolve a specific issue.
You should test the change before applying it to a production system. Any of the
following changes, if they are not set carefully, can have adverse effects on the ADC
server or on domain controllers.
Table I.1 Registry keys for Active Directory Connector
Key Value Description
Transaction REG_SZ The directory to which ADC logs all the deletes and failures.
Directory Defaults to MSADC\ in the ADC directory.
Sync Sleep REG_DWORD When ADC is not synchronizing, how long it waits before it
Delay (secs) should poll or resume work. Defaults to 300 seconds.
Max REG_DWORD The maximum length of time ADC will replicate. The default is
Continuous 300 seconds.
Sync (secs)
Password REG_DWORD The number of days ADC stores unused passwords. The default
Expiration is O, and if the default value is used, the actual number of days
depends on the number of passwords stored. This can range from
60 to 180 days.
Export Block REG_DWORD How big a block of USNs ADC exports before ADC commits the
Size connection agreement. The default is 20000. This is the starting
value that ADC uses when replicating. After the first block, the
block size is variable and is set to 10% of the remaining USNs.
Maximum REG_DWORD The maximum allowed export block size. The default is
Export Block 0xFFFFFFFF.
Size
Deletion REG_DWORD If the Exchange store mailbox delete fails, should the directory
Depend On object delete fail? Used as a Boolean, 0 to disable, and 1 to
Store enable. The default is 0.
Key Value Description
ADCI REG_DWORD Sets the remote procedure call (RPC) port for setting passwords
TCP/IP Port on ADC connection agreements, so that it can be accessed
through a firewall. The default is not set, so the RPC port is
defined dynamically.
Disabled REG_SZ Allows you to choose the description that is set when ADC
Windows creates a disabled user. The default is "Disabled Windows user
User Account account". For more information, see Microsoft Knowledge Base
Description article 288084, "XADM: How to Change the Description Set on
Disabled Users by the ADC"
UMAC REG_DWORD Period for unmerged attribute cleanup, in seconds. The default is
Timeout 43200 seconds (12 hours).
Merge Bad REG_DWORD Specifies if bad links on a target object (with incorrect syntax or
Links ADC Global Name values that are in the same site and
organization as the import container) should be stamped on the
source object during back replication. Used as a Boolean value.
The default is 1 (TRUE).
Replication- REG_DWORD Specifies the default Replication-Sensitivity value set on an

Sensitivity object. The default is 20. For more information, see Microsoft
Knowledge Base article 291944, "XADM: Mailboxes Do Not
Have Trust Level When Created in Active Directory"
Max DC REG_DWORD Available with the Exchange 2000 Service Pack (SP) 3 ADC.
State Vector This value sets an upper limit on the number of domain
controllers that ADC keeps track of in the msExchUSNVector
attribute on the connection agreement. This is useful if you have
>800 domain controllers in the environment. For more
information, see Microsoft Knowledge Base article 314950,
"XADM: The ADC Does Not Work in an Environment That
Contains More Than 800 Domain Controllers"
A P P E N D I X J
Additional Resources
Technical Articles
Directory Replication and Background Traffic for Microsoft Exchange 5.5
(http://go.microsoft.com/fwlink/?LinkId=20532)
Resource Kits
Microsoft Exchange 2000 Server Resource Kit
You can order a copy of the Microsoft Exchange 2000 Server Resource Kit from Microsoft
Press® at http://go.microsoft.com/fwlink/?LinkId=6544.
Microsoft Windows 2000 Server Resource Kit
You can order a copy of the Microsoft Windows 2000 Server Resource Kit from Microsoft
Press at http://go.microsoft.com/fwlink/?LinkId=6546.
Microsoft Knowledge Base Articles

The following Microsoft Knowledge Base articles are available on the Web at
http://support.microsoft.com/:
269843, "XADM: ADC Overwrites Display Name with Exchange Server 5.5 Display Name"
(http://support.microsoft.com/?kbid=269843)
316280, "XADM: A Description of the 'ADC Global Names' Attribute"
316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated
Accounts"
191239, "XADM: Sample Base 64 Encoding and Decoding"
152854, "XADM: Using Bulk Import to Remove Data"
303180, "XADM: Active Directory Connector Connection Agreement Requirements for Mixed
Administrative Groups"
296260, "XGEN: How to Configure a Two-Way Recipient Connection Agreement for Exchange
Server 5.5 Users"
278888, "XADM: How to Associate an Exchange 2000 Mailbox with a Windows NT 4.0
Account"
269843, "XADM: ADC Overwrites Display Name with Exchange Server 5.5 Display Name"
256862, "XADM: How to Correct Mismatched Accounts After Active Directory Connector
Replication"
253841, "XADM: Troubleshooting Active Directory Connector Replication Issues"
253840, "XADM: When the Active Directory Connector Commits Changes to Active Directory"
253832, "XADM: Description of the Active Directory Connector Schema Map"
253830, "XADM: How the Active Directory Connector Stores Passwords"
253829, "XADM: Description of the Active Directory Connector Deletion Mechanism"
253827, "XADM: How Exchange Hides Group Membership in Active Directory"
253826, "XADM: How the Active Directory Connector Replicates Subcontainers"
253825, "XADM: How the Active Directory Polling Period Works"
253665, "XADM: How the Active Directory Connector Uses Block Search to Replicate
Changes"
253286, "XADM: "ADC Installation Requirements"
314950, "XADM: "The ADC Does Not Work in an Environment That Contains More than
800 Domain Controllers"
288084, "XADM: "How to Change the Description Set on Disabled Users by the ADC"
Appendix J: Additional Resources 133
For more information, go to: http://www.microsoft.com/exchange.

Did this book help you? Please give us your feedback. On a scale of 1 (poor) to 5 (excellent),
how would you rate this book?

Understanding and Deploying Exchange 2000 Active Directory Connector

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Understanding and Deploying Exchange 2000 Active Directory Connector

Hochgeladen von

Copyright:

Verfügbare Formate

Understanding and

Graham McIntyre, Paul Bowden,

Graham McIntyre, Paul Bowden,

Applies To: Exchange 2000 Server SP3

Project Editor: Lindsay Pyfer

What Will You Learn from This

Who Should Read This Book?

What Terminology Is Used in

How Is This Book Structured?

What Is Active Directory

What Does ADC Consist Of?

Windows 2000 ADC

Exchange 2000 Server ADC Update

Exchange 2000 ADC Service Packs

Exchange 2000 and

Using a Single One-Way

Figure 1.1 Populating Active Directory with a one-way connection agreement

Figure 1.2 Synchronization using two-way connection agreements

Questions to Ask Before

How Many Exchange Sites Does the

How Many Active Directory Domains

Will Master/Account Domains Be

How Is the Container Structure in the

Exchange Server Versions

Where Should ADC Be

Deploying Multiple ADC

LDAP Ports and Protocols

Planning Your Connection

Scenario 1: Two Active Directory

Attribute/Connection Connection agreement Connection agreement

Type Two-way Two-way

From Exchange tab:

Exchange export Americas/Recipients Europe/Recipients

Objects from Exchange Mailboxes/Custom Recipients Mailboxes/Custom Recipient

Default destination corp.contoso.com/Users corp.contoso.com/Users

Attribute/Connection Connection agreement Connection agreement

From Windows tab:

Windows export corp.contoso.com/Users corp.contoso.com/Users

Objects from Users/Contacts/Groups Users/Contacts/Groups

Default destination Americas/Recipients Europe/Recipients

Primary to Exchange Yes No

Primary to Windows Yes Yes

Table 3.2 Connection agreement configuration for Scenario 1, Part 2

Attribute/Connection Connection agreement Asia Connection agreement

Type Two-way Two-way

From Exchange tab:

Exchange export Asia/Recipients Asia/Recipients

Objects from Exchange Mailboxes/Custom Recipients Mailboxes/Custom Recipien

Default destination corp.contoso.com/Users sales.contoso.com/Users

Attribute/Connection Connection agreement Asia Connection agreement

From Windows tab:

Windows export corp.contoso.com/Users sales.contoso.com/Users

Objects from Users/Contacts/Groups Users/Contacts/Groups

Default destination Asia/Recipients Asia/Recipients

Primary to Exchange No Yes

Primary to Windows Yes No

Figure 3.3 Three Exchange sites, two active domains

Scenario 2: Simple Mapping

Table 3.3 Connection agreement configuration for Scenario 2

Attribute/Connection Connection agreement Connection agreement to

Type Two-way Two-way

From Exchange tab:

Exchange export Reading/Recipients Manchester/Recipients

Default destination Washington/Recipients Washington/Internet