Understanding and Deploying Exchange 2000 Active Directory Connector

Understanding and Deploying Exchange 2000 Active Directory Connector

Graham McIntyre, Paul Bowden, Bryan Hunt

Understanding and Deploying Exchange 2000 Active Directory Connector

Graham McIntyre, Paul Bowden, Bryan Hunt

Applies To: Exchange 2000 Server SP3

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

AcknowledgmentsProject 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 ContentsUnderstanding and Deploying Exchange 2000 Active Directory Connector....................................................................................1 Understanding and Deploying Exchange 2000 Active Directory Connector...................................................................................iv Introduction.................................................................................5 Overview...................................................................................5What 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?.......................................10What 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 .............................................................16Questions 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...................................................................22Exchange 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.......................................................................48Server 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...................................52Initial 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.......................57ADC Installation..................................................................... ..................57 Configuring Attribute Replication and Object Matching...........................58 Creating Connection Agreements........................................ ....................60 Creating Public Folder Connection Agreements.......................................69

Chapter 7...................................................................................73 After Installation......................................................................73How 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.......................................................................81Event 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..........................................................86Tools............................................................................ ............................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....................................95General Attributes....................................................................... .......95 Windows Server-Specific Attributes............................................ ........97 Exchange Server-Specific Attributes..................................................99

Appendix D..............................................................................102 ADC Matching Rules..............................................................102Format of ADC Matching Rules........................................... ..............104 Modifying Object Matching Rules.....................................................105

Appendix E..............................................................................107 Viewing and Modifying the Attribute Mapping.......................107Changing 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..............................117Exchange 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............................126Arbitrating Changes....................................................................... ........126 Replication Loop Prevention.............................................. ...............128 Additional Registry Keys for ADC................................. ..........................129

Appendix J................................................................................131 Additional Resources.............................................................131Technical 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. NoteThe information in this book is based on Microsoft Windows 2000 Server Service Pack (SP) 2 and Microsoft Exchange 2000 Server SP2.

What Will You Learn from This Book?This book provides detailed answers to the following questions: What is ADC?

6 Understanding and Deploying Exchange 2000 Active Directory Connector

What should I consider before implementing ADC? How does ADC work? How do I install ADC? How do I configure connection agreements? How does ADC match objects? How does the schema map work? How do object matching rules work? What is the difference between recipient, public folder, and configuration connection agreements? How do I troubleshoot Active Directory Connector?

Who Should Read This Book?This book is intended for Active Directory and Exchange administrators who are responsible for deploying Exchange 2000. This book provides both high-level and detailed information about deploying Active Directory Connector to facilitate a migration from Exchange 5.5 to Exchange 2000 Server.

What Terminology Is Used in This Book?To understand this book, make sure you are familiar with the following terms, some of which were taken from the Distributed Systems Guide volume of the Window 2000 Resource Kit (http://go.microsoft.com/fwlink/?LinkId=6545): access control entry (ACE) An entry in an access control list (ACL) containing the security ID (SID) for a user or group and an access mask that specifies which operations by the user or group are allowed, denied, or audited. access control list (ACL) A list of security protections that apply to an entire object, a set of the object's properties, or an individual property of an object. There are two types of access control lists: discretionary and system. access token A data structure containing security information that identifies a user to the security subsystem on a computer running Windows 2000 or Microsoft Windows NT. Access tokens contain a user's security ID, the security IDs for groups that the user belongs to, and a list of the user's privileges on the local computer.

Introduction 7

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

How Is This Book Structured?This book is divided into nine chapters and ten appendixes. Chapter 1, "What is Active Directory Connector" This chapter describes Active Directory Connector, its purpose, its features, and how they interact to implement Active Directory in organizations that have already deployed


Exchange 5.5 and to achieve co-existence between Exchange Server 5.5 and Exchange 2000 Server. Chapter 2, "Deployment Planning" This chapter lists the questions that you should ask before you deploy ADC in your organization and the reasons for asking these questions. Chapter 3, "Technical Planning" This chapter describes factors that you need to consider when you plan your ADC deployment. These factors include server version, schema updates, compatibility with Windows 2000 Server, where to install ADC, what you need to know before deploying multiple ADC servers, LDAP ports and protocols, and how to plan connection agreements. Three detailed scenarios are presented to illustrate thorough planning of connection agreements. Information about the public folder connection agreement is also included. Chapter 4, "Resource Usage" This chapter describes the server and network requirements for handling the resources that are consumed when ADC is running, and factors that affect how many resources are consumed. Chapter 5, "How Active Directory Connector Works" This chapter describes the process by which ADC synchronizes Windows 2000 Active Directory with the Exchange 5.5 directory, including discussions of the initial replication, how changes are detected in the Exchange directory and Active Directory, how different classes of objects are mapped between the two directories, what happens when a duplicate object is detected, and how schema discovery accommodates discrepancies between systems with the Exchange 5.5 directory and Active Directory. Chapter 6, "How to Implement Active Directory Connector" This chapter includes step-by-step procedures for implementing ADC, including illustrations of the user interface (UI). Chapter 7, "After Installation" This chapter describes how ADC finds, matches, and links objects, how Active Directory and the Exchange 5.5 directory handle replicated objects, and the two kinds of primary connection agreements. Chapter 8, "Troubleshooting" This chapter describes how to change diagnostic logging options, lists the different ADC event logging messages and logging levels, provides information about managing directory inconsistencies, and lists common issues that may arise after the ADC has been implemented along with tips and tricks for resolving these issues. Chapter 9, "Advanced Configuration" This chapter describes advanced customizations that you might need to make to the ADC in deployments with a very complex Exchange site or Active Directory topology, and the tools you use to make the changes. Appendix A, "Schema Updates Made by the Exchange 2000 Server Active Directory Connector" This appendix shows the schema updates that are applied to an Exchange 5.5 site when an ADC is installed and configured to write to that site, or when a server is upgraded to Exchange 5.5 SP3.

Introduction 9

Appendix B, "Manipulating Mailbox to Active Directory Account Replication" This appendix describes what to do with the multiple mailboxes with the same associated Windows NT account that are allowed in Exchange 5.5 but are not allowed in Active Directory. Appendix C, "Attributes of a Connection Agreement" This appendix lists the three groups of attributes that are contained in a connection agreement and describes each of these attributes. Appendix D, "ADC Matching Rules" This appendix describes the matching rules ADC uses when replicating objects, the format of the matching rules, and how to modify them. Appendix E, "Viewing and Modifying the Attribute Mapping" This appendix describes the location of the ADC schema map, its attributes, and what you need to know to view or edit attribute mapping. Appendix F, "Move Server Wizard" This appendix describes how to avoid or rectify adverse effects that occur if you use the Exchange 5.5 Move Server Wizard after ADC has been deployed. Appendix G, "Replicating Distribution Lists and Groups" This appendix describes the different types of lists and groups that are used in Exchange 5.5 and Exchange 2000, how they are affected by ADC, and includes a procedure for moving groups from a mixed-mode domain to a native-mode domain. Appendix H, "Four Test Topologies" This appendix describes the four basic topologies for testing Universal Security Groups and Public Folder Access Control Lists, and explains the elements that differentiate each topology from the others. Appendix I, "Inter-Organization Connection Agreement" This appendix describes the inter-organization connection agreement option that can be set on the Advanced tab of a connection agreement properties sheet and what happens if you do not select this option. This appendix also includes a discussion of how changes are arbitrated so that they can be synchronized between directories, and a list of additional registry keys for ADC. Appendix J, "Additional Resources" This appendix contains additional resources to help you maximize your understanding of the Active Directory Connector information that is discussed in this book.

C H A P T E R

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 ADCThe 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 ADCThe 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 UpdateThe 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 PacksExchange 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 DirectoryExchange 2000 no longer includes a directory service of its own; instead, it uses Active Directory, provided by Windows 2000, for object browsing, access control, and name resolution. For companies that have already deployed Exchange 5.5, coexistence between the Exchange 5.5 directory and Active Directory is a vital prerequisite for the Exchange 2000 upgrade process. However, after Exchange 2000 is deployed, Active Directory becomes the global address list for those Microsoft Outlook messaging and collaboration client users who have their mailboxes on


Exchange 2000. Therefore, it is important for the Exchange 5.5 directory and Active Directory to have complete information about each other.

Connection AgreementsInstalling 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 OrganizationIf you are uploading existing Exchange directory data to Active Directory, you can create a single connection agreement between Active Directory and an Exchange 5.5 server that uses the Exchange organization as a source for replication. Because all site information from the entire Exchange organization can be gained from any Exchange 5.5 server in the organization, all of the objects and sites can be pulled through a single connection. The connection is defined as a one way from Exchange agreement, allowing Active Directory data to be updated when the Exchange directory is modified. This has a limitation, however. The highest level that can be exported on a two-way connection agreement is the site level. If you decide to use a single one-way connection agreement to export the entire organization, you should do so only for an initial population of Active Directory. Exchange 2000 cannot be installed until at least one two-way connection agreement is set up. A two-way connection agreement both reads from and writes to both directories and, as such, can only communicate with one Exchange site.


Figure 1.1 Populating Active Directory with a one-way connection agreement Before installing Exchange 2000, you must reconfigure the connection agreements to allow for two-way replication for, at a minimum, the site where you are going to install the Exchange 2000 server. The mixed site needs to be removed from the list of export containers on the From Exchange tab of the one-way connection agreement, because that site now has its own two-way connection agreement. You can create multiple connection agreements (on the same ADC server, if you prefer) if multiple Exchange sites exist in the Exchange 5.5 directory.

Figure 1.2 Synchronization using two-way connection agreements

Configuration Connection Agreements and the Site Replication ServiceA Recipient Connection Agreement replicates recipient objects, such as mailboxes, distribution lists, and contacts, between the Exchange 5.5 directory and Active Directory; however, when an Exchange 2000 server belongs to an existing Exchange 5.5 site, configuration information must be replicated. This replication allows the Exchange 2000 server to be represented in the Exchange site server list so that earlier versions of Exchange can send and receive messages as


seamlessly as if the new server were running Exchange 5.5. Additionally, gateway or route information must be replicated between the two directories to allow Exchange 2000 servers to send messages to specialized connectors that exist on the Exchange 5.5 servers and vice versa. All configuration information is replicated through a unique instance of a connection agreement, which is known as a configuration connection agreement or Config CA. Unlike standard connection agreements, Config CAs are configured automatically by Exchange Server rather than having to be instantiated manually. Additionally, the agreement for replicating configuration-naming context data is between Active Directory and the Exchange Site Replication Service (SRS) rather than between Active Directory and Exchange Server 5.5. The SRS is a component installed by Exchange 2000 Server and is similar to the Exchange 5.5 directory service, although the Name Service Provider Interface (NSPI) is disabled, so clients do not connect directly to the SRS to perform address book operations. When an Exchange 2000 server is installed into an Exchange 5.x site, the SRS is used for intra-site directory replication over remote procedure calls (RPCs). If an Exchange 5.5 directory-replication bridgehead server is upgraded to Exchange 2000, the SRS provides mail-based directory replication to downstream Exchange 5.x sites. Config CAs are named "ConfigCA_SRSNAME", where SRSNAME is the name of the SRS with which the Config CA is associated. You can use the Active Directory Connector Management snap-in to view the properties of Config CAs; however, most properties are read-only and cannot be modified. Like a standard Exchange directory service, the SRS supports direct LDAP calls and listens on port 379 to avoid port contention with other LDAP services running on the computer.

Figure 1.3 Exchange Server 5.5 and Exchange 2000 Server co-existence with the Site Replication Service After replication, all Exchange 5.x sites are represented in Active Directory as administrative groups. Exchange 2000 servers in the administrative group are represented in the Exchange 5.x site. Typically, there is only one Config CA and Site Replication Service per mixed site. The Site Replication Service is on the first Exchange 2000 server installed into an Exchange 5.5 site or the first one to be upgraded. However, additional Site Replication Services can be created in a site by


upgrading an Exchange 5.5 server that is the bridgehead of a Directory Replication Connector, or by using Exchange System Manager to create a new Site Replication Service on an existing Exchange 2000 server in the site.

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 ConnectorBefore you deploy Active Directory Connector, ask the questions listed in this section: How many Exchange sites does the organization have? How many Active Directory domains are being planned? Will domains be upgraded before ADC is deployed? How is the container structure in the existing Exchange system defined? The business sponsor, the Active Directory directory service planning team, the Exchange 2000 Server planning team, and support and administration staff should discuss these issues. The answers to these questions will dictate how you should deploy ADC.

How Many Exchange Sites Does the Organization Have?Creating a deployment plan begins with an assessment of the existing environment. For starters, how many Exchange sites are in the organization? How is the replication topology set up? In which site(s) are you going to deploy Exchange 2000 servers initially? Normally, it is recommended that you set up two-way ADC replication for all sites. This prevents your having to change the ADC configuration later as you begin introducing Exchange 2000

Chapter 2: Deployment Planning

17

servers, and also ensures that any new objects, or changes to existing objects, in either Active Directory or Exchange Server version 5.5, are replicated properly. However, if you have a large number of Exchange 5.5 sites and you plan to deploy Exchange 2000 one site at a time, it may be easier to set up two-way replication for the initial sites where Exchange 2000 will be deployed, and a single one-way connection agreement from Exchange to Windows to populate Active Directory with information from the other Exchange 5.5 sites. When you are ready to deploy Exchange 2000 in another Exchange 5.5 site, remove that site from the existing one-way connection agreement, and create a new two-way connection agreement directly to that site. For an example of how to transition additional Exchange 5.5 sites to using two-way connection agreements, see "Scenario 3: One Domain, Multi-Site, Split Containers" in Chapter 3.

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


Will Master/Account Domains Be Upgraded Before ADC Is Deployed?Each Exchange mailbox is mapped to a primary Microsoft Windows NT account, which is normally mapped to a master-accounts domain. Ideally, each of these account domains should be upgraded to Windows 2000 and Active Directory before ADC is deployed. This is actually not required, however, because only the primary domain controller of these domains requires the upgrade. All other backup domain controllers and member servers can reside in the mixed-mode domain. There are several aspects to consider when determining whether your account domain will be a Windows NT 4.0 domain or an Active Directory domain. After you start to install Exchange 2000 servers, Microsoft Outlook is able to detect only directory objects that are represented in Active Directory, so you may need to configure additional connection agreements as part of the Exchange 2000 deployment process. You need to ensure that all existing Exchange objects, including those mapped to Microsoft Windows NT 4.0 domains, are represented in Active Directory. For example, what if one of your existing Exchange sites has Mailbox objects that have their primary Windows NT account mapped to a pure Windows NT 4.0 domain (that is, a domain in which all domain controllers are running Windows NT 4.0)? If you define a connection agreement for those Mailbox objects, you must decide how those objects are to be created within Active Directory. Because Mailbox objects cannot be mapped to a security object within Active Directory (they only exist in the Windows NT 4.0 domain), by default, a disabled Windows User object is created. This disabled user has a special mailbox store permission, called Associated External Account, to show that the Windows NT 4.0 account is the actual owner of the mailbox. ADC also populates an attribute on the disabled user named msExchMasterAccountSID, which holds the Security ID (SID) of the Windows NT 4.0 account that is the primary Windows NT account of the Exchange 5.5 mailbox. NoteAs 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.


19

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


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.


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

NoteIt 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 VersionsWhen 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 UpdatesWhen 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." NoteYou need Schema Admin permissions to update the schema.

Chapter 3: Technical Planning 23

Installing Exchange Server 5.5 on a Windows 2000 ServerSome 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. NoteThe new options available after ADC installation are supported only on servers and workstations that have the ADC manager component or Exchange 2000 System Manager installed directly on them. The new functionality is in an MMC extension named maildsmx.dll.


Figure 3.1 Creating an Exchange mailbox using Active Directory Users and Computers

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


Figure 3.2 Synchronizing multiple Exchange Server 5.5 sites with ADC

Deploying Multiple ADC ServersYou 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 ProtocolsBy default, the ADC server attempts to communicate with the Exchange directory bridgehead on port 389 (379 for the Site Replication Service), which is the most commonly used LDAP port. In some circumstances, you must configure the connection agreement for another port, one case being when Exchange 5.5 is deployed on a Windows 2000 domain controller. Active Directory


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

Planning Your Connection AgreementsIt 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 SitesExisting Exchange and Windows EnvironmentThree Exchange sites, Americas, Europe, and Asia, have user accounts in two domains, corp.contoso.com and sales.contoso.com. High-speed links exist between all sites and domains. All Exchange mailboxes in the Americas and Europe sites, and some of the Exchange mailboxes in the Asia site have their primary Windows NT accounts mapped to the corp.contoso.com domain. The other Exchange mailboxes in the Asia site have user accounts in the


sales.contoso.com domain. For all sites, all Mailbox, Distribution List, and Custom Recipient objects are in the Recipients container. Each Active Directory domain has all User, Group, and Contact objects in the Users container.

Business and Technical Requirements All replication should be two-way replication. Any new mail-enabled Contact or Group objects created in the corp.contoso.com domain should be created in the Americas site. Any new Custom Recipient, Distribution List, or Resource mailboxes created in Asia should be created in the corp.contoso.com domain.

SolutionTo 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


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


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)



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



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


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 MappingExisting Exchange and Windows EnvironmentTwo 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.

SolutionDeploy one ADC server. Configure one connection agreement for each existing Exchange site. See Table 3.3 for the connection agreement configuration.


Table 3.3 Connection agreement configuration for Scenario 2 Attribute/Connection 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


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 ContainersExisting Exchange EnvironmentSetting up this scenario is relatively complex, given the number of sites, domains, and requirements involved. This scenario involves ADC deployment recommendations in quite a few areas. A large organization, Northwind Traders, plans to deploy Exchange 2000. There are 20 sites in the organization. The Seattle and Boston sites will be the first two sites to install Exchange 2000 servers. The remaining sites, including Washington and Miami, will be upgraded incrementally to Exchange 2000 over the next 12 months. Each site has the standard Recipients container for Mailbox objects, but there is also a Distribution List container in each site for Distribution List objects. Each site also has an Internet container to hold SMTP Custom Recipients for external business partners.


There are four existing Windows NT 4.0 account domains that hold all user accounts. All Exchange mailboxes in the organization have the primary Windows NT account in one of the four domains. The administrators have created a single new Windows 2000 domain, northwindtraders.com, which they plan to migrate all Windows NT accounts into using a 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.

SolutionDeploy one ADC server, initially with six connection agreements: two two-way for Seattle, two two-way for Boston, and two one-way connection agreements to replicate the remaining Exchange 5.5 sites into Active Directory. Create a new container in Active Directory named ExchangeTemp, and use this as the default destination for all mailboxes and distribution lists from Exchange.


As another Exchange site such as Washington or Miami prepares to deploy Exchange 2000, set up two new connection agreements for that site and remove that site from the two existing 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**


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


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


Figures 3.5 through 3.10 demonstrate these connection agreements.

Figure 3.5 Seattle Mailbox/Distribution list connection agreement


Figure 3.6 Boston Mailbox/Distribution list connection agreement


Figure 3.7 Seattle Custom recipient connection agreement


Figure 3.8 Boston Custom recipient connection agreement


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


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

2.


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


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


Figure 3.12 Washington Custom recipient connection agreement

Explanations and NotesBecause this scenario is relatively complex, it merits some additional explanation. Both the Seattle Mailbox/Distribution List and Seattle Custom Recipient connection agreements are set as primary connection agreements. Under most circumstances, this configuration would create duplicate objects. However, in this environment, each connection agreement carries different object classes into the site, so there is no overlap. Note that Default Destination (Exchange) is marked ** for all non-primary to Exchange connection agreements. This is because the default destination is irrelevant for non-primary connection agreements; they will not create new objects. There is one exception: when the default import container is used for non-primary connection agreements (see the following bulleted item). Even though the Mailbox/Distribution List connection agreements to all sites except Seattle are non-primary to Exchange, if you create a new User in Business Unit\User and create a mailbox on an Exchange 2000 server, ADC will still create a new mailbox in the Exchange 5.5 directory. This is because ADC can use the home server to determine in which site the mailbox should be created. However, this does not apply to Exchange 5.5 mailboxes created in Active Directory. For Exchange 5.5 mailboxes created in Active Directory to replicate, the connection agreement must be marked as Primary Exchange.


Originally, all mailboxes and distribution lists for all sites are created in the ExchangeTemp organizational unit. Northwind Traders uses an automated method (not performed by ADC) to move the groups created into the correct Business Unit/Distribution List organizational unit. Note that the disabled users that are created should not be moved. Instead, the Windows NT migration tool creates new users in the correct Business Unit/Users organizational unit. Then, the Active Directory Cleanup Wizard (ADClean) can be run to merge the mail attributes from the disabled user to the migrated account in the correct organizational unit. Running the ADCClean tool deletes the disabled user automatically. After all Windows NT 4.0 account domains have been migrated, the only mailboxes that are left are ones that did not get merged with an enabled user for example, resource mailboxes marked with NTDSNoMatch. Each Mailbox/Distribution List connection agreement has each Business Unit Users and Group container exported because of the requirement that a user in any business unit may have a mailbox in any site. Exporting each container where the enabled user may be put ensures that, after ADClean is used to merge the accounts, ADC will still be able to replicate changes to the user in Active Directory back to its original site. NoteNorthwind 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 AgreementsPublic 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


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. NotePublic 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 ADCDepending 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 ConsumptionFor 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


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 th

Documents

Understanding and Deploying Exchange 2000 Active Directory Connector