Contents Overview 1 Lesson 1: The Cross-forest Specification 2 MIIS Components 8 Lab 8.1: Getting to know MIIS 2003 and GAL Sync Management Agent 26 Lesson 3: Cross-Forest SMTP Mailflow 32 Lesson 4: InterOrg Public Folder Replication 35 Lab 8.2: Cross Forest Practice 47 Appendix A GAL Sync Log and Error Messages 50 Appendix B: GAL Sync Mapping Types 54 Appendix C: GAL Sync Provisioning Rules 67 Acknowledgments 76 Module 8: Cross- Forest/Multi-Forest ii Module 8: Cross-Forest/Multi-Forest 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. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. 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, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, Excel, Exchange Server 5.5, Exchange 2000 Server, Exchange Server 2003, Internet Explorer, Internet Information Server, Word 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 (Groupwise, IBM, Lotus cc:Mail, Lotus Notes, Netscape, Oracle) may be the trademarks of their respective owners. Module 8: Cross-Forest/Multi-Forest 1 Overview  Topic 1 The cross-forest Specification  Topic 2 Microsoft Identity Integration Services (MIIS) 2003 and Global Address List (GAL) Sync  Topic 3 Cross-forest SMTP mail flow  Topic 4 Inter-Org public folder replication At the time of this writing, only RC1 of MIIS 2003 was available for reference. As such, many of the screenshots may be out of date. Additionally, the MIIS product name was renamed prior to the Release To Manufacture RTM in July 2003. Thus, any references to MMS or “Microsoft Meta Directory Services” should be considered MIIS or “Microsoft Identity Integration Services.” Introduction 2 Module 8: Cross-Forest/Multi-Forest Lesson 1: The Cross-forest Specification Introduction Why do customers deploy multiple forests? Customers deploy multiple forests because it is more secure. Since an Active Directory domain was no longer a true security boundary, forests became the entities in which future topologies were planned. Customers want administration autonomy and data isolation. They could achieve this in Exchange 5.5, by simply attaching any new Exchange 5.5 site to an existing organization, and thus form a chain of peer sites with a common GAL. Yet trusts were not necessary between each domain that was the realm of an Exchange 5.5 site. Therefore data could be isolated, and administration could be left in the hands of each site/Windows NT domain administrator. Exchange 2000 introduced an architectural regression. Customers could no longer achieve administration autonomy and data isolation because Exchange 2000 organizations were each bounded by a single forest. This meant that each Global address list was limited to this same boundary. There was no way to attach administrative groups to existing organizations outside of the forest to share a common GAL. Thus, it was extremely difficult to replace traditional site/domain boundaries with multi-domain, single-forest model. For those that tried, they found that transitive trusts and Exchange groups were so invasive that any domain administrators could potentially gain access to other domains’ mailboxes within the forest. Goals: The goal is to deploy multiple forests to achieve core messaging functionality as it works in the single-forest case. This includes - Basic mail functionality - Calendaring Module 8: Cross-Forest/Multi-Forest 3 - Common GAL Important: There are certain features which are not available in Cross-forest deployment, such as the ability to view distribution group membership whose members are stored in another forest. Further, Delegate Access will not be supported across forests. (Currently, a contact cannot be given delegate access to a mailbox). Thus, customers should not expect to achieve full full-feature parity with single-forest installations. Added benefits: - Customers have an alternative to using the Active Directory Connector’s inter-organizational connection agreements, which were not supported for coexistence between different organizations. - Provide an administrative model somewhat similar to peer-to-peer directories as was the case in Exchange 5.5, so that Exchange 5.5 customers may ease into Exchange 2003 without destroying their existing administrative model. The bare requirements to make a multi-forest topology work for just basic messaging (basically sending messages and no free/busy features) is Directory Synchronization and mail flow. Essentially, a synchronized global GAL needs to be available to all forests and a transport route needs to be in place to allow mail to flow between them. Since there is no built-in feature to automate sharing of GAL information between forests, the cross-forest spec combines unrelated technologies to achieve the goals. These technologies include  Microsoft Identity Integration Server (MIIS) to achieve directory synchronization.  Customized SMTP connectors for mailflow between forests.  Optional components (IORepl, x-forest movemailbox) may be added to the cross-forest scenario so that the multi-forest deployments come closer to parity with a single-forest scenario. Components 4 Module 8: Cross-Forest/Multi-Forest MIIS 2003 and GAL Sync Definition This topic covers Microsoft Identity Integration Server version 2003 and the Global Address List Synchronization (Galsync) process, which perform the directory synchronization. Once set up, users in one forest may look up recipients in different forests, and the infrastructure for cross-forest mail flow is established. History of MIIS •Previous version bought from Zoomit, Inc. •Version 2.2 is no longer for “sale.” “Sale” is in quotes because if a customer has a Windows 2000 Advanced Server license, then this product is available at no extra cost. However, in order to implement this product they will need to engage Microsoft Consulting Services (MCS) or an Authorized MIIS Partner. Version 2.2 is a high-touch, complex, difficult to deploy product. As it is particularly difficult to setup and configure, in the hands of the untrained, it is possible to do considerable damage to the connected systems. For this reason MMS 2.2 was never actually sold as a “product” in the true sense. It did not have a SKU, and was not on any parts list from Microsoft. However, Microsoft would license the product to customers who had a Windows 2000 Advanced Server license (at no additional cost), and took a services engagement from MCS, or from an Authorized MIIS Partner. •Version 3.0 (renamed to MMS 2003, then renamed to MIIS 2003) – Rewritten from the ground-up. There is still an MIIS 2003 partner program, and http://www.microsoft.com/windows2000/partners/mms2003.asp lists those that have been trained on MIIS 2003 and are ready to help customers. The 3.0/2003 version is considerably improved, and Microsoft believes customers can use the information (based on scenarios) that ships on the product CD to conduct their own evaluation, design, test and deployment. Module 8: Cross-Forest/Multi-Forest 5 Intro to MIIS 2003 Companies often store data about users and objects in multiple data sources – some within Active Directory forests, but others within other types of data repositories. Therefore, the identity of a user could be scattered across several different locations on several different incompatible platforms. Often, companies need to aggregate (combine) that information into a logical view that represents the sum of all the identify information for a given object. Thus, Metadirectories are utilized for identity management, or for massaging complex data from multiple data sources so that they may be managed easily. Because the concept is so universal, IBM®, Oracle®, Netscape®, and others market their own Metadirectory products. Microsoft’s latest offering is called Microsoft Integrity Information Services (MIIS) version 2003. MIIS 2003 is a service that collects information from different data sources throughout an organization and then combines all or part of that information into an integrated, unified view. This unified view presents all of the information about an object, such as a person or network resource, that is contained throughout the organization. In most organizations, the sources data is typically stored in different directories, databases, and other data repositories throughout the Information Technology (IT) infrastructure. After all of the information about a person or resource is combined in the metadirectory, rules can be applied to decide how this information is managed and how changes to this information flow out to all of the directories that are connected to the metadirectory. Therefore, the metadirectory propagates any changes that originate in one directory to the other directories in the organization. 6 Module 8: Cross-Forest/Multi-Forest Glossary: To use MIIS to manage data, it is important to become familiar with key concepts and definitions that will assist you in understanding the architecture and function of MIIS. Objects and Attributes - Each entry in the Metadirectory is an object, of a specific type, which is comprised of a number of attributes. For example, the entry for Kim Rallsis a specific “Person” object, which possesses attributes (e.g. displayName, Title, Department, telephoneNumber) that are defined for the “Person” Object Type. Examples of other object types include “Computer,” “Group,” and “Organizational Unit.” Although Object Types are similar in function to Lightweight Directory Access Protocol (LDAP) Object Classes, they do not exhibit inheritance, and an object may be of only one type. Metaverse and connected directories - The external sources of data for MIIS are referred to collectively as connected directories. The collection of objects and attributes which are stored and managed in the MIIS system is the metaverse. Because one object in the metaverse is likely to represent entries in more than one connected directory, there will be a conflict if attributes differ for that object in each connected directory. Therefore, it is important to understand which connected directory has authority for each object type and attribute, and therefore which source takes precedence if there is a conflict. This understanding comes primarily from discussions with the business owners of the various systems, and is one of the key requirements for success of a metadirectory implementation project. Management Agents and Connector Space - The data flow between MIIS and a specific connected directory is defined in a Management Agent, and data flows only when a Management Agent is run. Each Management Agent has a connector space. The connector space is an area (separate from the metaverse) in which a management agent stores holograms from which changes in data- state are calculated. A Management Agent may handle all objects in a connected directory or may be configured to manage only a subset of objects and their attributes. Every object and attribute from the connected directory handled by a Management Agent is represented in the connector space. The Management Agent configuration defines which objects are attributes are synchronized into the metaverse. Joins and Projection - If an object from a connected directory is represented in the metaverse, it is said to be joined. The process by which the synchronization engine makes the association between an entry in a connector space and a corresponding entry in the metaverse is known as joining. If an entry in the connector space is to be represented in the metaverse, but no corresponding entry in the metaverse can be found by the Join process, a new metaverse object may be created for this entry (according to how the Management Agent is configured). The creation of a new metaverse object is known as projection, and following projection, the connector space entry will be joined to the new metaverse object. Connectors and Disconnectors - An object in the connector space may or may not be joined to an object in the metaverse. If a connector space object is joined to a metaverse object, it is referred to as a Connector. If it is not joined to a metaverse object, it is referred to as a Disconnector. Module 8: Cross-Forest/Multi-Forest 7 GUIDs and Anchor IDs - Each metaverse object is identified by a unique value know as its Globally Unique ID (GUID). The Join between a connector space object and its corresponding metaverse object is achieved by storing the GUID with each connected connector space object. Similarly, there must be a link between each object in the connected directory and the connector space, so that the Management Agent can manage the entries in the connector space with the corresponding entries in the connected directory. This is achieved through a unique attribute (or a unique combination of attributes) which originates in the connected directory, and is referred to as the Anchor ID. Provisioning and Deprovisioning - It is possible to define object flow rules in MIIS that imply that the presence of an entry in one connected directory requires the presence of a corresponding entry in another connected directory. For example, the existence of an entry in a Human Resources system (representing an employee) might require the existence of an Active Directory account for this employee. In order to enforce this rule, MIIS can be configured to create and remove entries in a connected directory (for example, in Active Directory). The creation of entries is referred to as provisioning and the removal of entries is referred to as deprovisioning. 8 Module 8: Cross-Forest/Multi-Forest MIIS Components There are three basic areas of storage. The unified view (metaverse), connector space (where data manipulation takes place), and the connected data sources from where data is pulled/pushed. The actual manipulation (joins/adds/extension rules) are performed by the Management Agents. There are different Management Agents for different types of data sources. Pertaining to Exchange 2003, there is the Active Directory Global Address List Synchronization Management Agent (GAL Sync Management Agent) where our attention will focus later.  Connected Directory z Source and/or destination for synchronized objects and attributes  Connector Space (CS) z Staging area for all objects that synchronize with MMS z Persists the import and export state on each object z Each MA has its own CS  Metaverse (MV) z Central (SQL) store of identity information z Matching CS entries to a single MV entry is called “join” Active Directory Active Directory Oracle Oracle IPlanet IPlanet SAP,JDEdwards SAP,JDEdwards , , Peoplesoft Peoplesoft , etc. , etc. Connected Connected Data Sources Data Sources Metaverse Metaverse User User Connector Connector Space Space [...]... the Management Agent that will import objects from forest1, select “Management Agents,” and choose “Create.” 14 Module 8: Cross-Forest/Multi-Forest A designer dialog will appear, and the user is prompted through a wizard-like configuration Module 8: Cross-Forest/Multi-Forest 15 16 Module 8: Cross-Forest/Multi-Forest If either organization uses special address types (Notes/Gwise/custom), the checkbox... unaltered, default state You can tell if any changes have been made (even those initially hidden by the “Show All” checkbox) by examining this screen 17 18 Module 8: Cross-Forest/Multi-Forest Module 8: Cross-Forest/Multi-Forest 19 20 Module 8: Cross-Forest/Multi-Forest After selecting the defaults and finishing the Management Agent Designer, create another Management Agent, using the same previous... change to the connected directory Although the Management Agent above was customized for HR databases, a pre-built Management Agent will be available to accomplish replicating global address lists Module 8: Cross-Forest/Multi-Forest 11 The GAL Sync Management Agent The pre-built GAL Sync Management Agent will allow Exchange administrators to easily configure MIIS 2003 without having the need of an MCS... following table, and any one–to-many or many-to-one mappings listed the preceeding or following tables Source Active Directory Metaverse Target Active Directory User Person User Group Group Group 12 Module 8: Cross-Forest/Multi-Forest Microsoft Metadirectory Services 2003 does not handle multi mastering of these objects in any environment All target attributes will typically be overwritten by attributes... provisioned contact In this case, provisioning clears up this duplicate A warning is logged when this join occurs In all other cases (where the joined metaverse object is a provisioned contact), a Module 8: Cross-Forest/Multi-Forest 13 join to an already joined metaverse object is not allowed and an error is logged The following table lists and describes the joins between connector space attributes that.. .Module 8: Cross-Forest/Multi-Forest 9 Management Agents can also read/write to/from flat files For Exchange 2003, we use cell-based Management Agents Regardless of the Management Agent type, the connector space... membership Note that the last seven dialogs in the GAL Sync Management Agent configuration are OK with their defaults, so click “Next” on each one until finished They are shown for reference purposes: Module 8: Cross-Forest/Multi-Forest This dialog is displayed in its unaltered, default state You can tell if any changes have been made (even those initially hidden by the “Show All” checkbox) by examining... This action is called a join because each entry in the connector namespace that represents the same real-world object is joined together, or integrated, as one entry in the metaverse namespace 10 Module 8: Cross-Forest/Multi-Forest To ensure that the entries that are joined together in the metaverse namespace represent the same real-word object, you can configure MIIS to use a unique attribute (such... provisioned in the metaverse and the end result is that any mail-enabled objects in a source forest (users/groups/contacts) are created as contacts in the target forests, as in the following illustration Module 8: Cross-Forest/Multi-Forest 21 Additionally, any master objects that disappear (get deleted) from the source forest will eventually become de-provisioned and disappear from their target forests as well... examining the msExchOriginatingForest attribute In this example, the object came from darkforest.internal The legacyExchangeDN from the source forest is added in the form of the X500 address 22 Module 8: Cross-Forest/Multi-Forest From the msExchPoliciesExcluded, MIIS-generated contacts, by default, have the following checkbox unchecked: “Automatically Update E-mail Address based on recipient policy” . 67 Acknowledgments 76 Module 8: Cross- Forest/Multi-Forest ii Module 8: Cross-Forest/Multi-Forest Information in this document, including URL and. through a wizard-like configuration Module 8: Cross-Forest/Multi-Forest 15 16 Module 8: Cross-Forest/Multi-Forest If either organization