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

8 Understanding and Deploying Exchange 2000 Active Directory Connector

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

What Is Active Directory Connector?

1

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

12 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 1: What Is Active Directory Connector? 13

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

14 Understanding and Deploying Exchange 2000 Active Directory Connector

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

Chapter 1: What Is Active Directory Connector? 15

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.

Deployment Planning

C H A P T E R

2

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.

18 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 2: Deployment Planning

19

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 ADCGenerated 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.

20 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 2: Deployment Planning

21

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

Technical Planning

3

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.

24 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 3: Technical Planning 25

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

26 Understanding and Deploying Exchange 2000 Active Directory Connector

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

Chapter 3: Technical Planning 27

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 agreement Americas <-> corp.contoso.com Type From Exchange tab: Exchange export containers Objects from Exchange Americas/Recipients Europe/Recipients Two-way Connection agreement Europe <-> corp.contoso.com Two-way

Mailboxes/Custom Recipients /Distribution Lists

Mailboxes/Custom Recipient s /Distribution Lists corp.contoso.com/Users

Default destination

corp.contoso.com/Users

28 Understanding and Deploying Exchange 2000 Active Directory Connector

Attribute/Connection Connection agreement agreement Americas <-> corp.contoso.com (Windows) From Windows tab: Windows export containers Objects from Active Directory Default destination (Exchange) Advanced tab: Primary to Exchange organization Primary to Windows domain Table 3.2 Yes corp.contoso.com/Users

Connection agreement Europe <-> corp.contoso.com

corp.contoso.com/Users

Users/Contacts/Groups

Users/Contacts/Groups

Americas/Recipients

Europe/Recipients

No

Yes

Yes

Connection agreement configuration for Scenario 1, Part 2 Connection agreement Asia <-> corp.contoso.com Connection agreement Asia <-> sales.contoso.com Two-way

Attribute/Connection agreement

Type From Exchange tab: Exchange export containers Objects from Exchange

Two-way

Asia/Recipients

Asia/Recipients

Mailboxes/Custom Recipients /Distribution Lists

Mailboxes/Custom Recipien ts /Distribution Lists sales.contoso.com/Users

Default destination (Windows)

corp.contoso.com/Users

Chapter 3: Technical Planning 29

Attribute/Connection agreement

Connection agreement Asia <-> corp.contoso.com

Connection agreement Asia <-> sales.contoso.com

From Windows tab: Windows export containers Objects from Active Directory Default destination (Exchange) Advanced tab: Primary to Exchange organization Primary to Windows domain No Yes corp.contoso.com/Users sales.contoso.com/Users

Users/Contacts/Groups

Users/Contacts/Groups

Asia/Recipients

Asia/Recipients

Yes

No

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

30 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 3: Technical Planning 31

Table 3.3 Connection agreement configuration for Scenario 2 Attribute/Connection agreement Type From Exchange tab: Exchange export containers Objects from Exchange Reading/Recipients Manchester/Recipients Connection agreement to Reading Two-way Connection agreement to Manchester Two-way

Mailboxes/Custom Recipients /Distribution Lists Users

Mailboxes/Custom Recipients /Distribution Lists Users

Default destination (Windows) From Windows tab:

Windows export containers Users Objects from Active Directory Default destination (Exchange) Advanced tab: Primary to Exchange organization Primary to Windows domain Yes Users/Contacts/Groups

Users Users/Contacts/Groups

Reading/Recipients

Manchester/Recipients

No

Yes

Yes

32 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 3: Technical Planning 33

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 thirdparty 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.

34 Understanding and Deploying Exchange 2000 Active Directory Connector

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 oneway 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 agreement Type From Exchange tab: Exchange export containers Objects from Exchange Default destination (Windows) From Windows tab: Windows export containers Sales/Users Sales/Groups Marketing/Users Marketing/Groups Research/Users Research/Groups Support/Users Support/Groups ExchangeTemp Objects from Active Directory Default destination (Exchange) Users/Groups Sales/Users Sales/Groups Marketing/Users Marketing/Groups Research/Users Research/Groups Support/Users Support/Groups ExchangeTemp Users/Groups Seattle/Recipients Seattle/Distribution List Mailboxes/Distribution Lists ExchangeTemp Boston/Recipients Boston/Distribution List Mailboxes/Distribution Lists ExchangeTemp Seattle Mailbox/Distribution list connection agreement Two-way Boston Mailbox/Distribution list connection agreement Two-way

Seattle/Recipients

Boston/Recipients**

Chapter 3: Technical Planning 35

Attribute/Connection agreement Advanced tab: Primary to Exchange Organization Primary to Windows domain

Seattle Mailbox/Distribution list connection agreement

Boston Mailbox/Distribution list connection agreement

Yes

No

Yes

Yes

Table 3.5 Connection agreement configuration for Scenario 3, part 2 Attribute/Connection agreement Type From Exchange tab: Exchange export containers Objects from Exchange Default destination (Windows) From Windows tab: Windows export containers Objects from Active Directory Default destination (Exchange) Advanced tab: Primary to Exchange organization Yes No External Contacts External Contacts Seattle/Internet Custom Recipients External Boston/Internet Custom Recipients External Seattle Custom recipient connection agreement Two-way Boston Custom recipient connection agreement Two-way

Seattle/Internet

Boston/Internet**

36 Understanding and Deploying Exchange 2000 Active Directory Connector

Attribute/Connection agreement Primary to Windows domain

Seattle Custom recipient connection agreement Yes

Boston Custom recipient connection agreement Yes

Table 3.6 Connection agreement configuration for Scenario 3, Part 3 Attribute/Connectio n agreement Type Pure Exchange 5.5 Mailbox/Distribution list from Exchange to Windows One-way from Exchange to Windows Pure Exchange 5.5 custom recipient from Exchange to Windows One-way from Exchange to Windows

From Exchange tab: Exchange export containers Washington/Recipients Washington/Distribution List Miami/Recipients Miami/Distribution List … <Additional Exchange 5.5 Site/Recipients and Site/Distribution List> Objects from Exchange Default destination (Windows) Advanced tab: Primary to Exchange organization Primary to Windows domain Yes Yes Mailboxes/Distribution Lists ExchangeTemp Custom Recipients External Washington/Internet Miami/Internet … <Additional Exchange 5.5 Site/Internet>

Chapter 3: Technical Planning 37

Figures 3.5 through 3.10 demonstrate these connection agreements.

Figure 3.5 Seattle Mailbox/Distribution list connection agreement

38 Understanding and Deploying Exchange 2000 Active Directory Connector

Figure 3.6 Boston Mailbox/Distribution list connection agreement

Chapter 3: Technical Planning 39

Figure 3.7 Seattle Custom recipient connection agreement

40 Understanding and Deploying Exchange 2000 Active Directory Connector

Figure 3.8 Boston Custom recipient connection agreement

Chapter 3: Technical Planning 41

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

42 Understanding and Deploying Exchange 2000 Active Directory Connector

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. Create two new connection agreements for Washington: one for mailboxes/distribution lists and one for custom recipients.

2.

Chapter 3: Technical Planning 43

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 agreement Type From Exchange tab: Exchange export containers Objects from Exchange Default destination (Windows) From Windows tab: Windows export containers Sales/Users Sales/Groups Marketing/Users Marketing/Groups Research/Users Research/Groups Support/Users Support/Groups ExchangeTemp Objects from Active Directory Default destination (Exchange) Users/Groups Contacts External Washington/Recipients Washington/Distribution List Mailboxes, Distribution Lists ExchangeTemp Custom Recipients External Washington/Internet Washington Mailbox/ Distribution list connection agreement Two-way Washington Custom recipient connection agreement Two-way

Washington/Recipients**

Washington/Internet**

44 Understanding and Deploying Exchange 2000 Active Directory Connector

Attribute/Connection agreement Advanced tab: Primary to Exchange organization Primary to Windows domain

Washington Mailbox/ Distribution list connection agreement

Washington Custom recipient connection agreement

No

No

Yes

Yes

Figures 3.11 and 3.12 represent the two new connection agreements.

Figure 3.11 Washington Mailbox/Distribution list connection agreement

Chapter 3: Technical Planning 45

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.

46 Understanding and Deploying Exchange 2000 Active Directory Connector

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 emailed. 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

Chapter 3: Technical Planning 47

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-mailenabled 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

Resource Usage

4

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 s and wire size) 119 frames 41 KB One change in Active Directory 70 frames 24 KB 89 frames 91 KB 27 frames 9 KB 24 frames 8 KB 210 frames 132 KB Two changes in Active 73 frames Directory 24 KB 98 frames 98 KB 34 frames 11 KB 30 frames 12 KB 236 frames 143 KB Three changes in Active Directory 77 frames 24 KB 96 frames 101 KB 40 frames 14 KB 36 frames 15 KB 249 frames 154 KB One change in the Exchange Server 5.5 directory service Two changes in the Exchange Server 5.5 directory service Three changes in the Exchange Server 5.5 directory service 87 frames 33 KB 103 frames 103 KB 29 frames 10 KB 24 frames 8 KB 243 frames 154 KB 94 frames 37 KB 114 frames 111 KB 32 frames 10 KB 27 frames 10 KB 267 frames 168 KB 107 frames 43 KB 122 frames 115 KB 37 frames 12 KB 30 frames 12 KB 296 frames 182 KB

Test No objects to replicate

ADC to Global Catalog 47 frames 19 KB

Global Catalog to ADC 36 frames 14 KB

ADC to Exchange 5.5/SRS 20 frames 5 KB

Exchange 5.5/SRS to ADC 16 frames 3 KB

50 Understanding and Deploying Exchange 2000 Active Directory Connector

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

How Active Directory Connector Works

5

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 ReplicatedObject-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 nonprimary 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

54 Understanding and Deploying Exchange 2000 Active Directory Connector

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 mailenabled 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 mailenabled 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 Active Directory object Mailbox-enabled User Mail-enabled User Exchange object class mapping Mailbox Custom recipient in the target container Not replicated Custom recipient in the target container Not replicated Distribution list in the target container Distribution list in the target container Not replicated

Non-mail-enabled User Mail-enabled Contact

Non-mail-enabled Contact Mail-enabled Group (type: Distribution) Mail-enabled Group (type: Security) Non-mail-enabled Group (type: 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.

56 Understanding and Deploying Exchange 2000 Active Directory Connector

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

How to Implement Active Directory Connector

6

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.

58 Understanding and Deploying Exchange 2000 Active Directory Connector

Figure 6.1 2. 3. 4.

Active Directory Connector Installation Wizard

Install both Active Directory Connector and the Active Directory Connector Manager and click Next. Enter the installation directory and click Next. 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

60 Understanding and Deploying Exchange 2000 Active Directory Connector

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 2.

General tab properties of a recipient connection agreement

3.

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. 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

Chapter 6 : How to Implement Active Directory Connector 61

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

62 Understanding and Deploying Exchange 2000 Active Directory Connector

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) msExchServer2HighestUSN 0 (For connection agreements that replicate from Exchange) msExchDoFullReplication True

Chapter 6 : How to Implement Active Directory Connector 63

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.

64 Understanding and Deploying Exchange 2000 Active Directory Connector

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 File name Win2000.ldf Ex55.csv Files created by ADC for deletions Purpose Entries deleted from the Exchange directory 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.

Chapter 6 : How to Implement Active Directory Connector 65

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

66 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 6 : How to Implement Active Directory Connector 67

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.

68 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 6 : How to Implement Active Directory Connector 69

Creating Public Folder Connection Agreements
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 agreement 2.

General tab properties of a public folder connection

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 twoway. 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.

70 Understanding and Deploying Exchange 2000 Active Directory Connector

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 agreement 4.

Connections tab properties of a public folder connection

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.

Chapter 6 : How to Implement Active Directory Connector 71

Figure 6.12 agreement

Schedule tab properties of a public folder connection

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) msExchServer2HighestUSN 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.

72 Understanding and Deploying Exchange 2000 Active Directory Connector

Figure 6.13 agreement

Advanced tab properties of a public folder connection

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

After Installation

7

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 AssocNT-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."

74 Understanding and Deploying Exchange 2000 Active Directory Connector

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

76 Understanding and Deploying Exchange 2000 Active Directory Connector

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.

Chapter 7: After Installation 77

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 Attribute syntax: single-valued octet string 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) Attribute syntax: multivalued Unicode string 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) Attribute syntax: single-valued octet string Set to the Invocation-ID of the Exchange 5.5 server on the Connections tab of the connection agreement. Object-GUID (New) Attribute syntax: single-valued octet string 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) Attribute syntax: single-valued octet string Set to the objectGUID of the connection agreement that made the change. Replicated-Object-Version (New) Attribute syntax: single-valued integer 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.

78 Understanding and Deploying Exchange 2000 Active Directory Connector

Figure 7.2 How ADC matches objects from Active Directory to Exchange Server 5.5

Primary vs. Non-Primary Connection Agreements
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.

Chapter 7: After Installation 79

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.

80 Understanding and Deploying Exchange 2000 Active Directory Connector

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

Troubleshooting

8

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

82 Understanding and Deploying Exchange 2000 Active Directory Connector

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 Replication Account management Attribute mapping Description Indicate events that occurred during replication. Indicate events that occurred while attempting to write or delete a Microsoft® Windows® object during replication. Indicate events that occurred while mapping attributes between the Active Directory® directory service and the Microsoft Exchange Server version 5.5 directory. Indicate events that occurred while accessing the directory using Lightweight Directory Access Protocol (LDAP). Indicate events that occurred when the service was started and stopped.

LDAP operations Service controller

There are four logging levels for ADC. Table 8.2 Diagnostic logging levels Level None Description Default logging level. Logs only critical events and error events, including starting and stopping the service, and component installation. 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. Logs events including those associated with the existence of specific objects in the directory.

Minimum

Medium

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 outof-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 connection agreement. 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.

84 Understanding and Deploying Exchange 2000 Active Directory Connector

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

Advanced Configuration

9

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*))

88 Understanding and Deploying Exchange 2000 Active Directory Connector

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-toExchange 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

Schema Updates Made by the Exchange 2000 Server Active Directory Connector

A

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 MayContai n MayContai n MayContai n MayContai n Value 1.2.840.113556.1.2.61 8 1.2.840.113556.1.2.61 9 1.2.840.113556.1.2.62 0 1.2.840.113556.1.2.62 1

Table A.2 ADC-Global-Names attribute (add) Attribute objectClass AccessCategory Value Attribute-Schema 1

Appendix A : Schema Updates Made by the Exchange 2000 Server Active Directory Connector 91

Attribute AttributeID AttributeSyntax IsSingleValued AdminDisplayName description

Value 1.2.840.113556.1.2.621 2.5.5.12 FALSE ADC-Global-Names msExchADCGlobalNam es 64 5

OMSyntax Heuristics

ExtendedCharsAllowed 0 SearchFlags 1

Table A.3 Object-GUID attribute (add) Attribute objectClass AccessCategory AttributeID Value Attribute-Schema 1 1.2.840.113556.1.2.61 8 2.5.5.10 FALSE Object-GUID objectGUID 35949 4

AttributeSyntax IsSingleValued AdminDisplayName description MAPIID OMSyntax

92 Understanding and Deploying Exchange 2000 Active Directory Connector

Attribute Heuristics

Value 3

ExtendedCharsAllowed 0 SearchFlags 1

Table A.4 Replication-Signature attribute (add) Attribute objectClass AccessCategory AttributeID Value Attribute-Schema 1 1.2.840.113556.1.2.61 9 2.5.5.10 TRUE Replication-Signature Replication-Signature 35950 4 3

AttributeSyntax IsSingleValued AdminDisplayName description MAPIID OMSyntax Heuristics

ExtendedCharsAllowed 0 SearchFlags 0

Table A.5 Unmerged-Attributes attribute (add) Attribute objectClass AccessCategory Value Attribute-Schema 1

Appendix A : Schema Updates Made by the Exchange 2000 Server Active Directory Connector 93

Attribute AttributeID

Value 1.2.840.113556.1.2.62 0 2.5.5.10 FALSE Unmerged-Attributes unmergedAtts 35951 4 3

AttributeSyntax IsSingleValued AdminDisplayName description MAPIID OMSyntax Heuristics

ExtendedCharsAllowed 0 SearchFlags 0

Table A.6 Schema-Version attribute (modify) Attribute V alu e 2506

RangeUppe r

Table A.7 Tagged-X509-Cert attribute (modify) Attribute Value

Description userSMIMECertificat e Heuristics 19

A P P E N D I X

Manipulating Mailbox to Active Directory Account Replication

B

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

Attributes of a Connection Agreement

C

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>

96 Understanding and Deploying Exchange 2000 Active Directory Connector

versionNumber Attribute syntax: single-valued integer 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 Attribute syntax: single-valued integer Controls the connection agreement replication. 0 = Never, 1 = selected times, 2 = Always ActivationSchedule Attribute syntax: single-valued octet string 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 Attribute syntax: single-valued integer 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 Attribute syntax: Boolean If True, all objects will be synchronized on the next replication cycle. msExchIsBridgeheadSite Attribute syntax: Boolean 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 Attribute syntax: single-valued Unicode string 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 Attribute syntax: single-valued Unicode string 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 Attribute syntax: Boolean 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 Attribute syntax: Boolean Specifies whether or not a connection agreement is a Config CA. Do not modify. msExchExchangeSite Attribute syntax: single-valued Unicode string Contains the Exchange 5.5 distinguished name of the site that the Exchange server is in. For example: ou=Site,o=org msExchInterOrgAddressType Attribute syntax: single-valued Unicode string 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 Attribute syntax: single-valued integer 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 Attribute syntax: single-valued integer 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 Attribute syntax: Boolean 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 Attribute syntax: single-valued integer Specifies the type of object ADC should create to represent an unmatched mailbox. 0 = Contact, 1 = Disabled User, 2 = Enabled User

98 Understanding and Deploying Exchange 2000 Active Directory Connector

msExchServer1AuthenticationCredentials Attribute syntax: single-valued Unicode string The credentials for connecting to the Windows server. For example: Domain\User name msExchServer1AuthenticationType Attribute syntax: single-valued integer Specifies the authentication protocol to be used. 4 = NTLM (Windows Challenge/Response) msExchServer1DeletionOption Attribute syntax: single-valued integer Specifies whether ADC will replicate deletes from Exchange to Windows. 0 = Replicate deletes, 1 = write deletes to an .ldf file msExchServer1ExportContainers Attribute syntax: multivalued Unicode string Specifies which containers to export from Windows, using the distinguished name of the container. msExchServer1Flags Attribute syntax: single-valued integer 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" (http://support.microsoft.com/?kbid=269843). 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. msExchServer1HighestUSN Attribute syntax: multivalued Unicode string 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 Attribute syntax: single-valued Unicode string

Appendix C : Attributes of a Connection Agreement 99

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 Attribute syntax: single-valued Unicode string The host name of the domain controller that is the Windows endpoint of the connection agreement. msExchServer1PageSize Attribute syntax: single-valued integer Specifies the Lightweight Directory Access Protocol (LDAP) page size to use when replicating with Active Directory. The default value is 20. msExchServer1Port Attribute syntax: single-valued integer Specifies the LDAP port to use when connecting to the Active Directory server. The default port is 389. msExchServer1SearchFilter Attribute syntax: single-valued Unicode string 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 Attribute syntax: single-valued integer Specifies the LDAP port used for Secure Sockets Layer (SSL) communications with the Active Directory server. The default port is 636. msExchServer1Type Attribute syntax: single-valued integer Specifies the type of server. 0 = Active Directory domain controller

Exchange Server-Specific Attributes
msExchServer2AuthenticationCredentials Attribute syntax: single-valued Unicode string The credentials for connecting to the Exchange server.

100 Understanding and Deploying Exchange 2000 Active Directory Connector

For example: Domain\User name msExchServer2AuthenticationType Attribute syntax: single-valued integer Specifies the authentication protocol that is used. 4 = NTLM (Windows Challenge/Response) msExchServer2DeletionOption Attribute syntax: single-valued integer Specifies whether ADC will replicate deletes from Windows to Exchange. 0 = Replicate deletes, 1 = Write deletes to a .csv file msExchServer2ExportContainers Attribute syntax: multivalued Unicode string Specifies which containers to export from Exchange, using the distinguished name of the container. msExchServer2Flags Attribute syntax: single-valued integer Special flags that apply when replicating with Exchange. The default is 0. No special flags currently exist. msExchServer2HighestUSN 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 Attribute syntax: single-valued Unicode string 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.

Appendix C : Attributes of a Connection Agreement 101

msExchServer2NetworkAddress Attribute syntax: single-valued Unicode string The host name of the Exchange server or SRS that is the Exchange endpoint of the connection agreement. msExchServer2PageSize Attribute syntax: single-valued integer Specifies the LDAP page size to use when replicating with Exchange. The default value is 20. msExchServer2Port Attribute syntax: single-valued integer 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 Attribute syntax: single-valued Unicode string 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=remoteaddress)(objectClass=groupOfNames)) msExchServer2SSLPort Attribute syntax: single-valued integer The LDAP port used for SSL communications with the Exchange server. The default port is 636. msExchServer2Type Attribute syntax: single-valued integer Specifies the type of server. 1 = Exchange 5.5 server or SRS.

A P P E N D I X

ADC Matching Rules

D

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 attribute Assoc-NT-Account = Extension-Attribute-10= NTDSContact Extension-Attribute10=NTDSNoMatch Assoc-NT-Account = 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.

Active Directory LDAP attribute ObjectSid Forces a contact to be created for this Exchange 5.5 object Forces a disabled user account to be created for this Exchange 5.5 object SIDHistory

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$PublicFolder$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$PublicFolder$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-Attribute10#"NTDSNoMatch"#veto-previous# ObjectMatch###NotNULL#legacyExchangeDN#veto-Previous# ObjectMatch###Assoc-NT-Account#sidhistory#sid_match EscapeBinaryBlob#

104 Understanding and Deploying Exchange 2000 Active Directory Connector

ObjectMatch##user$organizationalPerson$person$top#Extension-Attribute-10#"NTDS Contact"#veto-previous# ObjectMatch##user$organizationalPerson$person$top#Extension-Attribute10#"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 toc sa ta Source object-class value Target object-class value Source attribute or attribute value 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 ExtensionAttribute-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-Attribute9#"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

106 Understanding and Deploying Exchange 2000 Active Directory Connector Objectmatch#person$Public­ Folder$Top#publicFolder$top#distinguishedName#legacyExchangeDN$$exchange_dn#si d_Match#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###user$organizationalPerson$person$top#Extensi

on-Attribute-9#"Resource"#vetoprevious#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###user$organizationalPerson$person$top#Extensi

on-Attribute-9#"Recource"#vetoprevious#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. Start ADSIEdit and connect to the Active Directory Connections container. Expand the Configuration node and then expand the second Configuration node. Expand Services, expand Exchange, and then expand Active Directory Connections. Right-click CN=Default ADC Property, and then click Properties. In the Select the property to view list, choose msExchServer2ObjectMatch. Paste the entire object matching rules string into the Edit Attribute box. Click Set, click Apply, and then click OK. Restart the ADC service.

2. 3. 4. 5. 6. 7. 8. 9.

A P P E N D I X

Viewing and Modifying the Attribute Mapping

E

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).

108 Understanding and Deploying Exchange 2000 Active Directory Connector

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. 2. 3. 4. Connect to a domain controller on port 389. Click Options, click General, and change Value Parsing from String to Binary. Navigate the directory hierarchy to the Active Directory Connections container. 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. 2. 3. 4. 5. Connect to a domain controller with ADSIEdit. Traverse the directory hierarchy to the Active Directory Connections container. Click the Active Directory Connections node. Right-click CN=Default ADC Policy, and then click Properties. 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#src­class#tgt­class#src­attr#tgt­attr#prefix#dn­syntax#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 tgt-attr prefix The source attribute name The target attribute name SMTP$ or X400$ (special case for proxy address fields)

110 Understanding and Deploying Exchange 2000 Active Directory Connector

Field dnsyntax flags

Definition A distinguished name-linked attribute 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

Appendix E: Viewing and Modifying the Attribute Mapping 111

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

112 Understanding and Deploying Exchange 2000 Active Directory Connector

Note
The 0x800 flag was introduced with the Service Pack 1 version of ADC.

Appendix E: Viewing and Modifying the Attribute Mapping 113

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

114 Understanding and Deploying Exchange 2000 Active Directory Connector

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

Move Server Wizard

F

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

116 Understanding and Deploying Exchange 2000 Active Directory Connector

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

Replicating Distribution Lists and Groups

G

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.

118 Understanding and Deploying Exchange 2000 Active Directory Connector

Distribution Groups vs. Security Groups
In Windows 2000, a group can be mail-enabled, security-enabled, or both. A group that is mailenabled 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

120 Understanding and Deploying Exchange 2000 Active Directory Connector

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" (http://support.microsoft.com/?kbid=278888).

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. 2. 3. Stop ADC. Export all distribution lists from Exchange Server 5.5 to a .csv file. 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). Import the .csv file into Exchange 5.5. Use Active Directory Users and Computers to find and delete all mail-enabled groups that were created by Active Directory Connector. Change the destination container on the From Exchange tab to be the native-mode domain for the connection agreement replicating groups.

4. 5. 6.

Appendix G: Replicating Distribution Lists and Groups 121

7. 8.

Wait for the actions performed in Step 4 to replicate to the Exchange 5.5 server to which ADC is connected. Start ADC.

A P P E N D I X

Four Test Topologies

H

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

124 Understanding and Deploying Exchange 2000 Active Directory Connector

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

Inter-Organization Connection Agreement

I

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 interorganization 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.

128 Understanding and Deploying Exchange 2000 Active Directory Connector

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. 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.

Example

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 objectversion. 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 Transaction Directory Value REG_SZ Description The directory to which ADC logs all the deletes and failures. 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 Continuous Sync (secs) Password Expiration REG_DWORD The maximum length of time ADC will replicate. The default is 300 seconds.

REG_DWORD The number of days ADC stores unused passwords. The default 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 Depend On Store REG_DWORD If the Exchange store mailbox delete fails, should the directory object delete fail? Used as a Boolean, 0 to disable, and 1 to enable. The default is 0.

130 Understanding and Deploying Exchange 2000 Active Directory Connector

Key ADCI TCP/IP Port

Value

Description

REG_DWORD Sets the remote procedure call (RPC) port for setting passwords 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. Allows you to choose the description that is set when ADC creates a disabled user. The default is "Disabled Windows user account". For more information, see Microsoft Knowledge Base article 288084, "XADM: How to Change the Description Set on Disabled Users by the ADC" (http://support.microsoft.com/?kbid=288084).

Disabled REG_SZ Windows User Account Description

UMAC Timeout Merge Bad Links

REG_DWORD Period for unmerged attribute cleanup, in seconds. The default is 43200 seconds (12 hours). REG_DWORD Specifies if bad links on a target object (with incorrect syntax or 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). REG_DWORD Specifies the default Replication-Sensitivity value set on an 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" (http://support.microsoft.com/?kbid=291944).

ReplicationSensitivity

Max DC State Vector

REG_DWORD Available with the Exchange 2000 Service Pack (SP) 3 ADC. 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" (http://support.microsoft.com/?kbid=314950).

A P P E N D I X

Additional Resources

J

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 (http://go.microsoft.com/fwlink/?LinkId=6543) 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 (http://go.microsoft.com/fwlink/?LinkId=6545) 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" (http://support.microsoft.com/?kbid=316280) 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts" (http://support.microsoft.com/?kbid=316047) 191239, "XADM: Sample Base 64 Encoding and Decoding" (http://support.microsoft.com/?kbid=191239) 152854, "XADM: Using Bulk Import to Remove Data" (http://support.microsoft.com/?kbid=152854)

132 Understanding and Deploying Exchange 2000 Active Directory Connector

303180, "XADM: Active Directory Connector Connection Agreement Requirements for Mixed Administrative Groups" (http://support.microsoft.com/?kbid=303180) 296260, "XGEN: How to Configure a Two-Way Recipient Connection Agreement for Exchange Server 5.5 Users" (http://support.microsoft.com/?kbid=296260) 278888, "XADM: How to Associate an Exchange 2000 Mailbox with a Windows NT 4.0 Account" (http://support.microsoft.com/?kbid=278888) 269843, "XADM: ADC Overwrites Display Name with Exchange Server 5.5 Display Name" (http://support.microsoft.com/?kbid=269843) 256862, "XADM: How to Correct Mismatched Accounts After Active Directory Connector Replication" (http://support.microsoft.com/?kbid=256862) 253841, "XADM: Troubleshooting Active Directory Connector Replication Issues" (http://support.microsoft.com/?kbid=253841) 253840, "XADM: When the Active Directory Connector Commits Changes to Active Directory" (http://support.microsoft.com/?kbid=253840) 253832, "XADM: Description of the Active Directory Connector Schema Map" (http://support.microsoft.com/?kbid=253832) 253830, "XADM: How the Active Directory Connector Stores Passwords" (http://support.microsoft.com/?kbid=253830) 253829, "XADM: Description of the Active Directory Connector Deletion Mechanism" (http://support.microsoft.com/?kbid=253829) 253827, "XADM: How Exchange Hides Group Membership in Active Directory" (http://support.microsoft.com/?kbid=253827) 253826, "XADM: How the Active Directory Connector Replicates Subcontainers" (http://support.microsoft.com/?kbid=253826) 253825, "XADM: How the Active Directory Polling Period Works" (http://support.microsoft.com/?kbid=253825) 253665, "XADM: How the Active Directory Connector Uses Block Search to Replicate Changes" (http://support.microsoft.com/?kbid=253665) 253286, "XADM: "ADC Installation Requirements" (http://support.microsoft.com/?kbid=253286) 314950, "XADM: "The ADC Does Not Work in an Environment That Contains More than 800 Domain Controllers" (http://support.microsoft.com/?kbid=314950) 288084, "XADM: "How to Change the Description Set on Disabled Users by the ADC" (http://support.microsoft.com/?kbid=288084)

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?

Sign up to vote on this title
UsefulNot useful