Module 8: Cross- Forest/Multi-Forestgattner.name/simon/public/microsoft/MS Exchange/70... · Topic...

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


- 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


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.


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.


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.


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.


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 DirectorySource and/or destination for synchronized objects and attributes

Connector Space (CS)Staging area for all objects that synchronize with MMSPersists the importand export state on each objectEach MA has its own CS

Metaverse (MV)Central (SQL) store of identity informationMatching CS entries to a single MV entry is called “join”

Active DirectoryActive Directory

OracleOracle

IPlanetIPlanet

SAP,JDEdwardsSAP,JDEdwards,,PeoplesoftPeoplesoft, etc., etc.

ConnectedConnectedData SourcesData Sources

MetaverseMetaverse

UserUser

ConnectorConnectorSpaceSpace


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 and metaverse components are stored in SQL. Each Management Agent is capable of performing bidirectional replication between a data source and the metaverse. However, at least two Management Agents are necessary for end-to-end replication from a source connected directory to a target connected directory.

Information flow example This graphic shows how data flows from a data source through the metaverse, onward to another system. This is just an example of the ability to merge objects in different data sources which represent the same entity.

MetadirectoryMetadirectoryConnector Namespace Metaverse Namespace

Sue FineNamePost OfficeLocationEmployee #

Sue FineNamePost OfficeLocationEmployee #

Suzan FineFull NameTitleEmployee #

Suzan FineFull NameTitleEmployee #

Forest1Forest1Forest1 111 Full Name Title

Employee #

Full Name Title

Employee #

Suzan FineSuzan FineSuzan Fine

NamePost Office

LocationEmployee #

NamePost Office

LocationEmployee #

Sue FineSue FineSue Fine

222

= Management Agents= Management Agents

Full Name Title

Employee #

Full Name Title

Employee #

Suzan FineSuzan FineSuzan Fine33Full Name Title

Employee #

Full Name Title

Employee #


NamePost Office

LocationEmployee #

NamePost Office

LocationEmployee #

Sue FineSue FineSue Fine

Full Name Title

Employee #Name

Post OfficeLocation

Full Name Title

Employee #Name

Post OfficeLocation


44

55

555Suzan FineNamePost OfficeLocationEmployee #

Suzan FineNamePost OfficeLocationEmployee #


Forest2Forest2Forest2

1. The management agent for the first connected directory creates entries in the connector namespace. The management agent creates these entries (and their attributes) in its portion of the connector namespace.

2. The management agent for the second connected directory creates entries in its portion of the connector namespace. Note that in the preceding illustration, there is an entry for Kim Ralls each of the connected directories. Therefore, there will be two entries in the connector namespace that represent Kim Ralls.

3. The Management Agent for one of the connected directories creates an entry in the metaverse namespace that corresponds to the entry in its connector namespace. Note that an administrator determines which connected directory to use to initially create entries in the metaverse namespace.

4. The management agent for the second connected directory then attempts to match its entry in the connector namespace with the corresponding entry in the metaverse namespace. 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.


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 as an employee number) as the criteria by which entries are joined.

At this point, as shown in the preceding illustration, Kim Ralls represented by an entry in each of the connected directories, by an entry in the portion of the connector namespace for each connected directory, and by the integrated entry in the metaverse namespace.

5. After entries for the same real-world object are joined together in a single entry in the metaverse namespace, you can determine which attributes the metaverse namespace entry contains and from which connected directory the values for these attributes originate. This is determined by something called attribute flow rules.

When attribute values differ, an attribute flow rule specifies which attribute value (from the metadirectory or from the connected directory) takes precedence. For example, in the preceding illustration, if the values for a common attribute in the entries for Kim Ralls are different, attribute flow rules inform the management agents of the value that takes precedence so that the all the entries for Kim Ralls can be synchronized.

If an attribute does change in the entry in the metaverse namespace, the appropriate management agent makes that change in the entry in the connector namespace and then propagates the 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.


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 consultant to help design the attribute and rules. Once configured with the data sources (FQDNs of domain controllers), two GAL Sync Management Agents will be used to replicate mail-enabled objects from each Active Directory forest into the metaverse. As in the example above, it also has the ability to join different objects if certain attributes match. In the GAL Sync Management Agent, flows and joins are discussed below:

The flows that are addressed are the one-to-one mappings listed in the following table.

Source Active Directory Metaverse Target Active Directory User Person Contact

Contact Contact_forest Contact

Group Group Contact

Most of the attributes from the Source Active Directory are preserved and copied into the target Active Directory. For example, a telephone number of UserA in Forest1 will be synchronized to the target contacts UserA in Forest2 and Forest3. However, there are some exceptions where additional rules are called. More detailed information on the mapped attributes and rules are provided in Appendix B: Mapping Rules.

The flows that are not addressed are the one-to-one mappings in the 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


Microsoft Metadirectory Services 2003 does not handle multi mastering of these objects in any environment. All target attributes will typically be overwritten by attributes from the source. Exceptions are proxyAddresses and legacyExchangeDN, which have values assigned in the target forest that must be preserved.

The decision to exclude multi mastering arises from the fact that GAL synchronization should not have multi-mastering of objects as it is necessary for exchange functionality to have a single source object.

When MIIS looks for objects in the “Source Active Directory” column, the objects must match certain criteria to be written into the metaverse:

Object Conditions

User The homeMDB or TargetAddress attribute is defined.

Contains at least one proxyAddress attribute value.

The MSExchHideFromAddressList is not set to ‘true’.

Contains a LegacyExchangeDN attribute value.

Contact The TargetAddress attribute is defined.

At least one proxyAddress attribute value is defined.

The MSExchHideFromAddressList is not set to ‘true’.

Must have a LegacyExchangeDN attribute value, but only if the method of creation for the object was projection and not provisioning.

Group The MSExchHideFromAddressList attribute is not set to ‘true’.

A LegacyExchangeDN attribute value is defined.

Join rules are applied to contact objects only. When you run Management Agents, they will search for joins by using a list of metaverse object attributes. The search attempts to match metaverse object attributes with connector space object attributes. If any of the search criteria are met, then a join is established.

When the Apply Rules run profile is run, the following join rules are applied to contact objects only:

If there is more than one candidate in the metaverse for a join, an exception occurs and an error is logged. The Management Agent cannot determine where to flow the data because it cannot determine which object from which to export data.

If a contact that exists in the authoritative contact organizational unit in the source forest is joined to any object in the metaverse, an error is logged. Contacts in the authoritative contact organizational unit in the source forest are used for projection only. An exception does not occur because contacts are not supposed to flow into the target forest. The error is shown in the Event Viewer logging section.

A join to a metaverse object that is already joined is only allowed if the joined metaverse object is a 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


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 represent target forest attributes and metaverse attributes. These joins are performed during provisioning, when you run the export run profile and contacts are created in the target forest.

Active Directory Contact Attribute Metaverse Attribute Description

TargetAddress TargetAddress If an Active Directory contact object has the same target address as the metaverse person object, then it represents the same entity and a join occurs.

ProxyAddresses LegacyExchangeDN If the proxy address is an x500 proxy: If the LegacyExchangeDN of a metaverse object matches a value in the proxyAddresses of contact, then it represents the same entity and a join occurs.

ProxyAddresses ProxyAddresses If any of the proxyAddresses values in the target forest match any of the proxyAddress value matches in the metaverse, then the proxyAddresses values in the target forest represent the same entity (and a join occurs) or a miscofiguration.

If an object is joined outside the target forest organizational unit, MIIS 2003 logs a warning with information about the object and requires the user to move the data into the target forest organizational unit.

Requirements For GAL Sync, we require an Exchange 2003 schema. An Exchange 2003 server is also required because we need an Exchange 2003 Site Replication Service (SRS) bridgehead server to bring in HomeMDB and HomeMTA attributes from Exchange 5.5, if it is present in the topology.

We do not require that the organization names of each forest be the same. However, if the organization names are not unique, and objects reside in identically-named administrative groups in each forest, there is the potential for duplicate legacyExchangeDNs.

Sample Installation After SQL and MIIS 2003 have been installed, the following steps are sufficient to get the GALs replicated between two forests that have Exchange 2003 installed. To create the Management Agent that will import objects from forest1, select “Management Agents,” and choose “Create.”


A designer dialog will appear, and the user is prompted through a wizard-like configuration


If either organization uses special address types (Notes/Gwise/custom), the checkbox for “Route mail sent to contacts exported into this forest through the source forest” should be checked. This will be propagated to the target contact in forest2. If forest2 does not actually know or can misunderstand the address, then you get an Non Delivery Receipt (NDR). So checking the box forces the mail to be routed to the source forests, which then decodes the mail from the SMTP proxyaddresses to get the new target address of Groupwise/Notes/etc.

The “Specify an administrative group…” checkbox describes how to generate legacyExchangeDNs for any imported contacts. The choice for legacyExchangeDN will be chooseable from a drop-down list enumerating each administrative group in the connected forest. The legacyExchangeDN will eventually be created in the format “/o=org/ou=sitename/cn=recipients” where only the “sitename” field is customizable. This will affect the contacts’ site 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:


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

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


After selecting the defaults and finishing the Management Agent Designer, create another Management Agent, using the same previous steps as depicted, but rather than supplying credentials/containers from forest1, supply information specific to forest2.

When two Management Agents have been created, go to Tools -> Configure Extensions, and select the checkbox for Enable Provisioning Rules extension. (without this step, metaverse objects will not be projected into target forests).

The Management Agents may now be run. When running the Management Agents, you will be given an option to run certain Run Profiles.

Run Profiles Run Profiles specifies the parameters with which to run Forest1 GAL Sync Management Agent and Forest2 GAL Sync Management Agent. For this sample GAL synchronization scenario, five run profiles are created for each Management Agent. The following list describes each run profile type and the order in which it is run.

Run profile Description

Full Import All specified data flows from the Active Directory data source to the Microsoft Identity Integration Services 2003 connector space and metaverse.

Delta Import All changed data flows from the Active Directory data source to the MIIS 2003 connector space and metaverse.

Export All specified data flows from the MIIS 2003 metaverse and connector space to the Active Directory data source.

Full Synchronization Once all specified data source data is staged, all specified data flows from the MIIS 2003 connector space to the metaverse.

Delta Synchronization Once changed data source data is staged, changed data flows from the MIIS 2003 connector space to the metaverse.

Provisioning is disabled before the Full Import and Delta Import run profiles, and then enabled before running the Run Full Synchronization, Export, and Delta Import run profiles. Provisioning is managed in this order because all objects must be in the metaverse before rules may be applied or erroneous states can result.

When all of the imports and exports have been run, they are 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


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. Provisioning and de-provisioning rules are detailed in Appendix C.

forests,DC=adpreptest2,DC=internal 1> cn: Contoso User; 1> displayName: Contoso User; 1> mail: [email protected]; 1> givenName: Contoso; 1> instanceType: 4; 1> distinguishedName: CN=Contoso User,OU=Contacts from other forests,DC=adpreptest2,DC=internal; 1> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=adpreptest2,DC=internal; 4> objectClass: top; person; organizationalPerson; contact; 1> objectGUID: d4f5ead6-d6e2-4cd6-b9ef-651cd96ec0ab; 3> proxyAddresses: X500:/o=Microsoft/ou=First Administrative Group/cn=Recipients/cn=ContosoUser; X400:c=US;a= ;p=Microsoft;o=Exchange;s=User;g=Contoso;; SMTP:[email protected]; 1> name: Contoso User; 1> sn: User; 1> uSNChanged: 36706; 1> uSNCreated: 36706; 1> whenChanged: 5/20/2003 5:1:3 Central Standard Time Central Daylight Time; 1> whenCreated: 5/20/2003 5:1:3 Central Standard Time Central Daylight Time; 1> mailNickname: ContosoUser; 1> mAPIRecipient: TRUE; 1> targetAddress: SMTP:[email protected]; msExchPoliciesExcluded: {26491CFC-9E50-4857-861B-0CB8DF22B5D7}; 1> msExchOriginatingForest: darkforest.internal;

Key observations:

You can determine from which forest an object originated by 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.


From the msExchPoliciesExcluded, MIIS-generated contacts, by default, have the following checkbox unchecked: “Automatically Update E-mail Address based on recipient policy”.

Versioning: Different versions of MIIS:

Microsoft Identity Integration Server 2003, Enterprise Edition: This version has a large variety of Management Agents which allow customers to connect different data sources to provide identity integration/directory synchronization, account provisioning/de-provisioning and password management. This version includes the GAL Sync Management Agent.

Identity Integration Feature Pack for Microsoft Windows Server Active Directory: The feature pack provides fewer management agents, but it still includes the GAL Sync Management Agent. The feature pack is also a free download, unlike the Enterprise Edition. This version was once called the “Standard Edition” before its release.

MIIS 2003 Enterprise or Standard can be used since there are no additional features in the Enterprise release that Exchange 2000 is dependent on.

Similar Management Agents:

Exchange 5.5 Management Agent Exchange 5.5 Bridgehead Management Agent

Do not confuse the GAL Sync Management Agent with the two Exchange 5.5 Management Agents. The Exchange 5.5 Management Agents are only included with MIIS 2003 Enterprise, but are not supported by Enterprise Messaging Support.

Platform Support:

MIIS or Identity Integration Feature Pack may be installed on Windows 2003 Enterprise Edition.

Moving Mailboxes with Migration Wizard: In all versions of Exchange, mailboxes can only be copied across organizations, and there is no built-in function to move mailboxes. Therefore, customers typically resorted to using Exmerge, initially extracting data from the source Exchange organization, and then importing into the target organization. Then, the administrator would delete the mailbox from the source organization.

Though not a significant feature improvement, the Exchange 2003 Migration Wizard has been modified to allow for cross-forest “mailbox moves.” This is somewhat of a misnomer, as the source mailbox is not deleted from its source organization. Nevertheless, Exchange 2003’s Migration Wizard now has a detection mechanism that matches an MIIS-generated contact with a source

Note

Note

Note


mailbox. When such a match is found, the Migration Wizard will automatically delete the MIIS-generated contact and replace it with a mailbox-enabled user object. The purpose of the deletion is to ensure that the identity does not exist more than once in the Global Address list of the target forest. However, the administrator must remember to manually delete the source mailbox. Failure to do so would cause problems with forking of mailboxes (since the original mailbox might still be receiving messages).

Once the source forests’ mailbox-enabled user object is deleted, then MIIS may be turned on again to perform another synchronization – 1) removing the old object from the metaverse and 2) replacing the original mailbox-enabled user object with a mail-enabled contact representing the target forest’s mailbox. This ensures reply-ability to older messages, as well as preventing forking of messages addressed to that mailbox.

List of tested/supported scenarios Single Instance (Hub/Spoke) - Only Single Instance MIIS has been tested. We are only testing where there is a single instance of MIIS among all the forests (hub configuration).

Hub/Spoke configuration is supported.


Active Directory Connector (ADC) - Mixed mode Exchange 5.5/2003 will be supported in the source and target forests. In the source forest, Exchange 5.5 objects will be brought into the source forest Active Directory through the ADC. The ADC-created objects will then be synced to the target forest via MIIS. If Exchange 5.5 is in the target forest, the ADC will bring the MIIS-created objects into the target Exchange 5.5 Directory. The target forest ADC will not do any transformations of the objects when bringing then into the Exchange 5.5 Directory.

All the following topology conditions have been tested, although not necessarily together: Exchange 2003 Native Exchange 5.5/2003 Mixed Exchange 2000 Native Exchange 2000/2003 Mixed Parent Child/Sibling Second Tree Grandchild Windows 2003 Native Forest Windows 2003 Native domain Windows 2000 Native domain Windows 2000 Mixed Domain Windows 2003 Mixed Domain Japanese Domain Controllers German Domain Controllers Japanese Exchange 2003 Japanese Exchange 5.5 German Exchange 2003 Separate SMTP Domain Namespaces Matching SMTP Domain Namespaces Windows 2-Way Trusts 1-Way trusts No Windows Trusts Resource Forests Exchange Tools/Components Tested With: Only SMTP connectivity between Forests ADClean (but some issues found: basically an issue where the object naming conventions due to conflicts are not optimal.) ADMT (but some issues found: IO Repl (InterOrganizational Public Folder Replication Tool

List of untested/unsupported scenarios Hybrid Resource is unsupported.

Mesh configuration of MIIS servers is not supported by the masses; only MCS-approved mesh configurations may be supported.


Resource Forest scenario In this scenario, one forest holds the Exchange mailboxes and the other forest holds the user accounts. The mail-enabled user SID matches MSExchMasterAccountSID of disabled user accounts with mailboxes in another forest. Since there is already a directory replication mechanism (e.g. the intraorg ADC connection agreements), GAL Sync must not be used against these directories.

Looping Forming a replication loop using two non-GAL Sync Management Agents into Active Directory (thereby possibly causing duplicates) will not be supported. The exception to this rule is if there is MCS engagement/approval.

Example of loop:

AD/Exchange 2003 <-- Lotus Notes Connector --> Notes’ Names.nsf <--|

| |

|-------> Gal Sync MA --- Metaverse --- Lotus Notes MA <-----------|

Mail-enabled Public Folders via GAL Sync not tested/supported.

Key Management Server/SMIME certificates via GAL Sync not tested/supported.


Lab 8.1: Getting to know MIIS 2003 and GAL Sync Management Agent

Introduction In this practice lab, you will log onto your virtual PC and briefly examine the MIIS installation.

Log on to the MIISSQLDC Virtual PC 1. From the host computer, navigate to Microsoft Virtual Server’s “Master

Status” page. 2. Power-on the virtual machine called MIISSQLDC. 3. When the Log on dialog box appears, log on to the MIISSQLDC as

Administrator using Password1 as the password. 4. Note that the equivalent of Ctrl-Alt-Delete is RightAlt-Delete, and that you

can toggle full-screen mode with RightAlt-Enter if you are using the Virtual Machine Remote Control Client.

Run Metadirectory Manager 1. Note that there are five main Tools (Windows or Panes), accessible via

toolbar buttons or through the Tools menu; take a look at each: a. Operations (history of Management Agent-run profile execution) b. Management Agents (note the “Search Connector Space” option, and

the panes for displaying Synchronization Statistics and Flow Errors) c. The Metaverse Designer (you can examine the default Object Types

and Attributes) d. Metaverse Search e. The Joiner

Test with simple replication 1. Logon to Forest1DC 2. Open Active Directory Users and Computers. 3. In the Users OU, create a mail-enabled contact

([email protected]) as well as a mailbox-enabled user account ([email protected]).

4. Switch back to the Metadirectory Manager. 5. On the upper-left pane, right-click on the “Forest1DCGALSyncMA”

and choose “Run”. 6. Choose the full import run profile


7. When the Management Agent has finished running, examine the “Synchronization statistics” pane to see what new objects have been added to the metaverse.

8. Does your contact appear to have been added? If not, open the properties of the Forest1 Management Agent, and go to the “Configure GAL” page. Does external.microsoft.com appear in the SMTP-mail suffix managed in the forest? Alternatively, does the Users OU appear in the “Authoritative contacts” container? If neither apply, apply ONE of them.

Examine the MIIS database in SQL Server (you are encouraged to do this from time to time as you practice more)

1. Open SQL Server Enterprise Manager 2. Use the console tree to navigate to the Microsoft Metadirectory Services

database 3. Take a look at some of the Tables by right-clicking the table (e.g.

mms_metaverse or mms_connectorspace) and selecting Open Table and Return all rows

4. Look for the two objects you created, but note that you are advised not to modify these entries directly!

Complete replication into second forest 1. Return to the Metadirectory Manager, and right-click on the Forest2 –

Metaverse Management Agent. 2. Right-click and choose to Run the export profile. 3. Switch to the virtual machine that runs the second forest. 4. From the Administrative Tools menu, load the Active Directory Users

and Computers snap-in. 5. Examine the container structure, and locate where the new contacts have

been replicated. 6. Open the properties of the new contacts, and examine their e-mail addresses

tab. What address types are there?


Q&A/Troubleshooting Question: If I have a problem with synchronization, how would I begin troubleshooting?

Answer: Click on the Synchronization errors for an object

When navigating into the problematic object, select the “Stack Trace” button to view the reason for the sync error.

Question: How can I find errors from previously run profiles?

Answer: Select the operations button, and look at the history of previous Runs.


Question: How can I tell which objects are going to be exported to other forests?

Answer: After you run a “Full Import” on the Management Agent connected to the source forest, look at the synchronization statistics pane (lower left-hand corner of Metadirectory Manager).

You should see “Outbound Synchronization” - <name of target MA>. Underneath that, click on “export attribute flow,” which will be clickable if there are objects pending export into the target forest. You are then presented with a dialog of all the objects, and navigating into their properties will show which attributes will be created/modified.


Question: How do I view objects in a connector space, in general?

Answer: There are a couple of ways:

• View the "mms_connectorspace" table in SQL enterprise manager.

• In metadirectory manager, highlight the Management Agents option at the top of the screen. Then, on the upper-right hand corner, select "Search Connector Space" (To see which of these objects exist in the metaverse, sort by the “Connector” column for values with the “Yes” value.

Question: Under the “Configure GAL” page, what does "Mail to contacts exported from this forest will be routed through this forest" do?

Answer: When checked, it changes how the targetaddress of a contact gets constructed. (Need better answer)

Question: Under the “Configure GAL” page, when selecting the option “Specify an administrative group to enable interoperability with Exchange 5.5 and Active Directory Connector environments,” if I choose “edit,” how come I do not see my admin group the list of administrative groups?

Answer: Customers will often rename their administrative groups after switching to native mode. In LDP or ADSIEdit, search the admin groups’ “Displayname” entries to correlate with the desired admin group.

Question: What happens if same contact is created in both forests, before MIIS is used to sync?

Answer: Join rules apply here, provided that one of the contacts resides within an “authoritative” contacts container, as configured within the “Configure GAL” property sheet. Since the contact will have the same proxy address in both forests, MIIS will know how to "join" the two objects in both forests as the same object in the metaverse.

Question: If there is an error in sync, I can click the "preview” button. But how can I see the preview button for an object that doesn't have an error?

Answer: Search connector space -> open the object found, and select preview button on lower-left dialog. Alternatively, after you have executed a run profile (such as an import), you can preview objects within the underlined statistics in the Synchronization Statistics pane.


Question How can I automate the schedule of the Management Agents so that it acts like an Active Directory connector?

Answer: There’s no integrated functionality to do this. A VB script can spawn WMI code to do this. However, the script would need to be scheduled using the AT command.

Question: Is the GAL Sync Management Agent designed to create objects in different OU’s within a target forest?

Answer: No, all mail-enabled objects from multiple source forests will get dumped into a single OU in a target forest. (Is there an exception?)


Lesson 3: Cross-Forest SMTP Mailflow

This topic covers mailflow and configuration of SMTP connectors used with the cross-forest spec. Additionally, conditional forwarding, a new Windows 2003 feature in DNS, may be used.

Scenario 1: No two Exchange organizations share the same SMTP namespace SMTP connectors are not required if each Exchange organization can resolve the other through DNS. However, if the two forests are separate divisions within the same company, each company division may not be resolvable through internet DNS servers. For that reason, or SMTP connectors may be set up in this fashion:

Introduction


This illustrates one SMTP connector in the source forest, where “Darkforest” is a forest outside of the current forest where the SMTP connector is created. An SMTP connector in the Darkforest organization would also need to be created pointing to the source forest.

Scenario 2: One or more Exchange organizations share SMTP namespace If the SMTP namespaces of each organization is the same, then routing will be difficult since each Exchange organization will believe that it is authoritative for that SMTP domain, and will queue for remote delivery to another organization.

In this circumstance, a secondary proxyaddress must be added to all mail-enabled users, contacts, and groups to distinguish forest membership and allow SMTP routing outside of the forest.

Example: Assuming that domain.com is the shared SMTP domain for two forests, the following steps are used

1. On the recipient policy of forest1, modify the recipient policies to give all GAL objects an additional (secondary) proxyaddress to have a unique SMTP domain that is not present in any other forest. You could use the subdomain approach (SMTP: forest1.domain.com) or anything that does not exist in DNS (SMTP: af39417321095fjlk.random).

2. Repeat the last step for forest2, by modifying the recipient policies to give all GAL objects an additional (secondary) proxyaddress. (SMTP: forest2.domain.com or something random)

3. In each forest, create SMTP connectors with address spaces specific to the opposite forest. Refer to Scenario 1’s screenshots.


4. When you create your GAL Sync Management Agents, on the “Configure GAL” dialog page, add on the forest-specific SMTP namespace the SMTP domain of the secondary proxy address.

The checkbox for “Route mail sent to contacts exported into this forest through the source forest” is meant to cover the scenario where the targetaddress on a source contact is non-SMTP (Groupwise/Notes/x400). This will be propagated to the target contact in forest2. If forest2 does not actually know or can misunderstand the address, then you get an NDR. So checking the box forces the mail to be routed to the source forests, which then decodes the mail from the SMTP proxyaddresses to get the new target address of Groupwise/Notes/etc.

5. When you run the export, GAL Sync will set the targetaddress of the generated contact to this secondary proxy address. Since the targetaddress will not be the same as the authoritative SMTP domain of the sending organization, messages to contacts will be queued for remote delivery.

Possible issues As in any case of a large directory, it may be possible for mail sent to SMTP addresses that do not exist to loop back and forth between organizations’ SMTP connectors because each directory might have an object pointing to the opposite organization. One should check for such contacts in each directory that might cause a loop.

When forests have matching legacyDNs, there may be an issue with how GAL Sync “joins” the two objects in the metaverse. Therefore, one should tread lightly whenever setting-up MIIS between two organizations whose organization names and site names match.


Lesson 4: InterOrg Public Folder Replication

This topic covers Inter-organizational public folder replication. It is designed to replicate public folders between different Exchange organizations. It will also replicate free/busy information between organizations, granted that each organization has either a mail-enabled contact or custom recipient representing the source organization.

History Also known as Exchsync, IO Repl

Released with Exchange 5.5 SP2, and also delivered through Exchange 2000 CD.

Newest incarnation available via Web download (Exchsync package) folder from Web release (ExAllTools) tools. This is also expected to be updated in the future, through Exchange 2003 Service Pack releases.

Components The tool consists of two programs: the Configuration program (exscfg.exe), and the Replication service (exssrv.exe). The Configuration utility creates a configuration file for setting the replication frequency; logging options; folders to be replicated; and accounts to be used. This configuration file is used by the Replication Service to continuously update information between two servers in different organizations. The Exchange Replication Service, using a configuration file created by the Replication Configuration utility, continuously updates information from one server (designated as the Publisher) to one or more Exchange servers (designated as Subscribers). Schedule+ Free/Busy information is replicated from Publisher to Subscriber only. For this reason, you must have two free/busy sessions to bi-directionally update free/busy information. Public folders can be replicated from Publisher to Subscriber or bi-


directionally. You can configure the replication frequency, as well as the logging of message and folder replication, and how much processing power you want devoted to the replication process.

Areas of usage This tool is not supported between two servers that are using different languages. It only supports replication between servers using the same language (for example, English-to-English, French-to-French).

For the two-forest scenario, here are the combinations of organization types where IORepl may be used:

Pure Exchange 5.5 Pure Exchange 2000

Pure Exchange 2003

Exchange 2000/2003

Exchange 5.5/2000/2003

Pure Exchange 5.5 Use earlier version Use earlier version Yes Yes Yes Pure Exchange 2000 Use earlier version Yes Yes Yes Yes Pure Exchange 2003 Yes Yes Yes Yes Yes Exchange 2000/2003 Yes Yes Yes Yes Yes Exchange 5.5/2000/2003 yes Yes Yes Yes Yes

The above is a guideline, but customers choosing not to follow the table above may attempt to use the Exchange 2003 IORepl tool against Exchange 2000 and Exchange 5.5 organizations. Even if replication appears successful, unpredictable behavior might occur as scenarios outside of the above table have not been tested.

Requirements For replication of free/busy information, MIIS and GAL Sync must have already been configured and run so that cross-forest contacts already exist to correspond to external free/busy entries.

The tool must be installed on a computer that has Exchange 2003 Exchange System Manager installed on it. It is possible to install on a workstation/professional Windows platform that only has Exchange System Manager installed. Reference the Exchange 2003 Deployment Tools for more information on installing on creating an Exchange System Manager-only install. Note that Outlook is not supported and must not reside on the same machine on which Exchange System Manager is installed.

A VPN or open-RPC connection must be available between each Exchange organization/Active Directory forest. This is so that MAPI connections may be established.


Although you may use the tool to connect to Exchange 5.5 and Exchange 2000 organizations, you must use the IO Repl versions off the Exchange 2003 Service Packs and Web release. Do not use previous versions.

How to install Installing the InterOrg Replicator Utility for use with Microsoft Exchange Server consists of the following steps:

1. Preparing the Publisher 2. Preparing the Subscribers 3. Installing the InterOrg Replicator utility files 4. Creating a Configuration file 5. Setting up the Replication Service

Preparing the Publisher The first step in configuring the InterOrg Replicator utility is preparing an Exchange server to be a Publisher. The Publisher collects information from an Exchange organization, packages it, and sends it to Subscriber Exchange servers outside the Exchange organization based on a schedule you create. The publisher can be considered as the source server the information is being replicated from.

To prepare the Publisher, you must create a service account and mailbox for the utility to use during the replication process. You also must assign the appropriate permissions to that service account and mailbox, and create a public folder for the utility to use during replication.

It is important to understand that the service account and mailbox that you create must be listed as an owner of each public folder and subfolder you want to replicate, on either the Publisher or the Subscriber. This enables the utility to replicate Anonymous and Default permissions from one organization to the other. Use Microsoft Outlook to change the ownership and the permissions of public folders.

To prepare the Publisher server for InterOrg Replication:

1. Create a Windows NT account and an associated Exchange mailbox for the utility to use as a service account.

2. Using Microsoft Outlook, add the service account mailbox that you created as an owner for every top-level folder and subfolder you want to replicate.

3. Using Microsoft Outlook, create a public folder named ExchsyncSecurityFolder in the root Public Folder and grant Owner permissions to the service account mailbox that you created. Do not specify any Default or Anonymous permissions on this folder; it is used by the Replication Service for additional security and must be present on both the Publisher and Subscriber servers.

Preparing the Subscriber A Subscriber is an Exchange server where you want to replicate information to using the InterOrg Replicator utility. To configure a Subscriber, you must create a Windows NT account and an associated Exchange mailbox that the


utility can use as a service account. Additionally, you must create the public folders that the utility needs for the replication process.

To prepare the Subscriber server for InterOrg Replication:

1. Create a Windows NT account and an associated Exchange mailbox for the utility to use as a service account.

2. Using Microsoft Outlook, create a top-level folder for every portion of the folder hierarchy you are replicating. The utility will create subfolders automatically.

3. Using Outlook, grant Publishing Editor permission for each top-level folder to the service account mailbox that you created.

4. Using Microsoft Outlook, create a public folder named ExchsyncSecurityFolder off of the root public folder and grant Owner permission to the service account mailbox that you created. Do not specify any Default or Anonymous permissions on this folder; it is used by the Replication Service for additional security and must be present on both the Publisher and Subscriber servers.

Note: A Server can be both a publisher and subscriber if you are replicating both ways.

Installing the InterOrg Replicator Utility Files The following files are located in the EXCHSYNC directory on the Web Release download package (available by RTM). Additionally, you may find it on Exchange 2003 Service Pack CD distributions:

Exscfg.exe, the Microsoft Exchange Replication Configuration Program.

Exssrv.exe, the Microsoft Exchange Replication Service.

1. Create a working directory for the utility to use (C:\Exchsync, for example).

2. Copy the files Exssrv.exe and Exscfg.exe into your working directory.

Creating a Configuration File In order to set up replication, you must create a configuration file. The configuration file will contain replication sessions. Each session will be either a free/busy session or a public folder session.

To create a configuration file for free/busy replication:

1. Double-click Exscfg.exe. 2. On the Session menu, click Add. 3. In the Select Session Type dialog box, select Schedule+ Free/Busy

Replication


4. Type a display name for the session.

5. Type the Publisher and Subscriber server names, and the service account mailboxes that you created for each.

Click Advanced and type the Windows NT domain, service account, and password for each of the Publisher and Subscriber accounts.

6. Click on the schedule button and create a replication schedule that fits your needs.


7. Click on the schedule button and create a replication schedule that fits your needs.

8. Choose the sites for which you want replicate free/busy information for. The default is all sites available

9. Click OK to add the session to the configuration file and then save.

NOTE: Log files report when the service starts or stops, any errors it encounters, and statistical information for each session (for example, number of messages and folders replicated).

NOTE: For each mailbox in the Publisher server that you want to replicate free and busy information to, a corresponding custom recipient must exist on the Subscriber server. The SMTP address of the mailbox is the unique key that is used to match mailboxes to custom recipients.

To create a configuration file for public folder replication:

1. Double-click Exscfg.exe.

2. On the Session menu, click Add. 3. In the Select Session Type dialog box, select Public Folder Replication.


4. Type a display name for the session.

5. In the Maximum Task Number dialog box, enter the number of threads to be used for replication. In the Schedule dialog box, enter the time, day, and frequency for the replication session. If you want the utility to write a log during the replication process, click Logging and set the appropriate parameters.

6. Type the Publisher and Subscriber server names, and the service account mailboxes that you created for each.

7. Click Advanced and type the Windows NT domain, service account, and password for each of the Publisher and Subscriber accounts.

8. Click Folder List to choose which folders you want to replicate. In the Session Folder List dialog box, select the folder or folder hierarchy on the Publisher that you want to replicate, and then select the destination folder on the Subscriber.

9. Click the arrow button once to replicate public folder information only from the Publisher to the Subscriber. Click again to toggle bi-directional replication. You can also toggle on if subfolders replicate, deletions replicate, and default or anonymous permissions replicate.


10. Click OK to add the session to the configuration file and save.

To set up the Replication Service: 1. Double-click Exssrv.exe. The first time you run Exssrv.exe, click

Install. 2. Type the Windows NT account name and password for the account that

will run the service. The account should have the rights to log on locally and can run as a service. The account should be entered with domain/username.

3. Type the path and file name of the configuration file you created. 4. Specify whether or not you want the service to automatically start

when you turn on the computer.


5. After you have installed the Service, click Start or start it from the Control Panel.


Troubleshooting/Q&A There are a number of steps you can take if you encounter problems with the InterOrg Replicator tool. 1. Enable logging on the Public Folders or Free/Busy Session Configuration

tabs. 2. Check the Ex00yymmdd.log and Ex01yymmdd.log log files for any errors. 3. Use the application Event Viewer to make sure there are no errors.

Configure the Event Viewer with a large size (> 5MB), and configure it to wrap as needed.

4. Verify that you have granted the appropriate permissions to root folders and the ExchsyncSecurity Folder or the free/busy folder. Verify the folders are visible and that the account used has access to read and write to the folders. If not, you will receive the following error message.

Event ID 116 Source Exchsync Type Error Category None Mailbox user (username) does not have enough security to replicate to server [servername] on session 'Session Name'. WARNING: Create subfolder access is not available to '[SERVERNAME]\Foldername, skipping. WARNING: Write access is not available to '[SERVERNAME]\ Foldername, skipping. WARNING: Write access is not available to '[SERVERNAME]\ Foldername \ Foldername,skipping. WARNING: Read access is not available to '[SERVERNAME]\ Foldername, skipping. WARNING: Read access is not available to '[SERVERNAME]\ Foldername \ Foldername, skipping.

5. Verify that for each mailbox on the publisher server that you want to replicate free and busy information to, a corresponding custom recipient exists on the subscriber server. If none exists, create one. The SMTP address of the mailbox is the unique key that is used to match mailboxes to custom recipients. If a corresponding custom recipient does not exist, no free and busy information will be published.

6. If no free and busy information is displayed after you verify that the custom recipients do exist, quit, and restart your client. This forces your free and busy information to be written to the server. The next replication cycle will then publish your free and busy information.

Other errors: A 115 error event might indicate (in its description) that the ExchsyncSecurityFolder cannot be located. Verify the name matches exactly and there are no trailing or leading spaces in the name. A 118 error event is a communications or authentication error. The tool has


been unable to contact the server in question, or could not connect via MAPI. Check proper name resolution, network connectivity (trace route and ping), and make sure you have the correct version of MAPISVC.INF and that it is not damaged. If it is a permissions error, you may receive this text in the event description: “Unable to create a temporary MAPI profile to server [SERVERNAME] using mailbox [ioreplaccount] under Windows NT username [ioreplaccount] and domain [ADPREPTEST2] on session 'pf gizmos to dark'.”. Even if you were able to connect using the exscfg.exe utility, the service itself will not allow the account specified during exscfg.exe to log on directly to an Exchange server. In this case, grant the privilege of the specified account to log on locally, or add the account to the server operators group.

A 120 error event is a communications error. We have been able to contact the remote server but we failed to make a connection. Again check network connectivity (trace route and ping) making sure of no packet loss. Verify you have the correct user name and password for the service account mailbox.

Question: Can I install the service through terminal services? Answer: No. When you install the service, it creates an exchsyn.ini file in the %systemroot% directory. This variable will not be the same for a user logged into the terminal session as it is for when a service starts. See Q271813 for more information.

Question: The service is using the credentials of the service to login rather then the credentials specified in the configuration file?

Answer: The Public folder replication tool must be running on a machine that has Exchange System Manager installed, but not Outlook. This has to do with the EMSABP32.DLL. During the SP2 to SP3 timeframe of Exchange 5.5 these DLLs were given to Outlook to develop themselves. During this transition time a change was made to this DLL that allows a way for a service to pass a different set of credential when using MAPI. This change never made it to the Outlook version of the DLL and thus only exists in the Exchange version. The interorg tool uses this functionality and since it does not exist in the Outlook version of the DLL it uses the wrong credentials to log in. If you install Outlook 2000 or greater on the server, it will redirect calls to the Outlook version of the DLL and you again will be passing the wrong credentials. In the past this tool has worked on systems without Exchange server install. This is because at the time of this tools release the only versions of Outlook available were 98 and older. If you installed Outlook 98 first, then the Exchange administrator from SP3, the correct DLL would be copied over top in the system32 directory and thus the tool would work. Installing just the admin program is not enough on its own, as it does not update the MAPISVC.INF file with a transport that the tool can use and it will fail with a 118 event instead.

Question: ExchSync tool will not replicate and reports the following error in the log file “ERROR: Unable to import message change [SK= 6A69F6552DD203D5D6000001231] to folder ‘EX:/o=orgname/ou=Sitename’


on server [Servername], message previously existed but has been deleted.” (s0x010904700128)

Answer: At some point the free/busy messages in the subscriber org for the publishing org users were deleted. The error is produced because the publish org still holds a copy of the free/busy message(s). Since we are using the public folder APIs for this replication it will not allow these messages to be replicated back in, as they have the same message ID. New free/busy messages need to be created in the publishing org in order for replication to continue. This can be done by using the fbscrubber utility to clear out all the free/busy information in the publishing org and then making a change to every user’s calendar so it updates the free/busy information again in the publishing org. (The process of making a change to every user’s calendar may be automated through the fbupdate.exe utility.) Then, exchsync finds the new message IDs and pushes them to the subscriber org.

Question: What if free/busy information for new Custom recipient in the subscribing Org does not get updated?

Answer: The tool keeps track of changes and of what users it has replicated information for in the past. This way it does not have to replicate everything every time. If a mailbox in the publishing Org does not match a Custom recipient in the subscribing org it is marked to do not replicate this mailbox again. If a new Custom recipient is created for this user in the subscribing org after this, it still will not replicate, as it was already marked. This information is kept in a “dat” file in the working directory. If you delete this “dat” file, the interorg tool will perform a complete sync the next time and pick up the new custom recipient.


Lab 8.2: Cross Forest Practice 81

Exercise 1: Observing attributes replicated across forests 1. Create a new mailbox-enabled user in forest1: Jason Carlson 2. Wait until this new user obtains its proxyaddresses. (You may speed-up the

Recipient Update Service (RUS) stamping by updating the domain RUS.) 3. On the MMC box, run a delta import for the forest1MA. 4. In "synchronization statistics" window, click on "Adds" 5. Click on Jason Carlson and choose "Properties" 6. Click on "Preview" button, and then "generate preview" 7. To determine the attributes that would be written by MIIS when it is

exported to Forest2, select "Connector Updates" and on the right-hand side, double-click on the entry that has an "added" operation. An entry on the left-hand side will become highlighted, so expand highlighted object and click on "Export attribute flow." The right-hand pane should display the attributes written by MIIS.

When viewing the attribute flow, do not pay attention to "Initial value" as it is either empty, or inaccurate. Instead, the "Final value" is the correct value to observe

8. Proceed with an export by running the forest2MA. 9. Confirm that the contact is created in the "Contacts from other forests OU"

Exercise 2a: Moving a mailbox object between forests. 1. Open migration wizard on forest2dc. (Start programs Microsoft

Exchange Deployment Migration Wizard) Note that this has changed locations from Exchange 2000.

2. Choose the option: migrate from another Exchange server. 3. For the source server, deselect the checkbox for “5.5 server” and specify

forest1dc, with the administrator account “forest1\administrator” and password of “Password1”

This lab has been set up with a conditional forwarder (configured within DNS). Without it, you would receive an error code 1355 with error message "Unable to logon to the server. Please verify the server name, port, account name, and password."

4. Choose the "Users" OU for placement of the target user accounts in forest2. 5. Finish the migration wizard.

Note

Note


6. In forest2, refresh your view on the "Users OU" and confirm that Jason Carlson appears as a mailbox-enabled user account. Do you notice anything unusual about its proxyaddresses?

(The x500 address is added, and it is used for reply-ability)

7. Refresh your view on the "Contacts from other forests" OU, and note that the Jason Carlson contact object no longer exists.

• At this stage, the administrator should delete (or at least mailbox-disable) the object from the source forest (Forest1) and synchronize the Management Agents to populate a mail-enabled contact in forest1 representing the moved mailbox. However, if the deletion is skipped, and instead Management Agents are synchronized, you will receive the error message in the following steps.

8. Run a delta import for the forest2MA. You should see "Synchronization errors" on the lower-left pane.

9. Click on the error and then click on the "Stack Trace" button. Read the error message.

Exercise 2b: Correcting problem with conflicting authoritative objects:

1. Delete Jason Carlson from the source forest. 2. Run a delta import on forest1MA to pick-up the deletion. 3. Run a delta import on forest2MA to get rid of the thrown exception, and

mark the forest2 object as authoritative. 4. Run an export on forest1MA to project the moved object into forest1 as a

contact. The GALs are now consistent.

Exercise 3: Does deleting target forest contacts cause the source contacts to become deleted?

No, this is not like the ADC.

1. To test, delete the “Laura Norman” contact from forest2. 2. Run an import of forest2MA, and you will see that a "delete" for her contact

is detected. This does not mean that the corresponding object is deleted from forest1.

3. Run an export of forest1MA, and you can verify that Laura Norman user account is not deleted because it is authoritative.

4. To re-add any contacts accidentally deleted from forest2, simply run an import of the forest2MA (which we've already done), and an export of forest2MA.


Exercise 4: Testing mailflow 1. Log onto Laura Norman’s mailbox in Forest1 using Outlook Web

Access.

2. Verify that mailflow works to a user in the opposite forest.

Exercise 5: Sharing address spaces 1. To each exchange org's recipient policy, add an additional address

(Contoso-shared.com). In the recipient policy, ensure that Contoso-shared.com is not selected for “This Exchange Organization is responsible for all mail delivery to this address.”

2. Update each forests’ domain RUS. 3. Both Management Agents must now be modified. Open their properties, and

on the "Configure GAL" dialog, edit the SMTP addresses managed by each forest.

4. Run at least two full imports on each connected directory so that the synchronization rules will pick up the new changes to the user objects. Then run exports on the management agents.

5. Configure SMTP connectors as defined by the cross-forest module. 6. While logged-on as Laura Norman, send an SMTP message to

[email protected]. Note that Jason Carlson’s mailbox is in forest2, so Exchange 2003 must resolve and route to the other organization.


Appendix A GAL Sync Log and Error Messages The following table lists the common Microsoft Metadirectory Services 2003 log and error messages associated with GAL synchronization, along with the troubleshooting prescriptions.

Table A.1 Log and Error Messages Messages Action Join messages

Contact in connector space tries to join to two possible objects in the metaverse and neither of them is a provisioned contact: There are multiple objects representing the

same entity in the metaverse, they are

<forest name, DN of object 1, forest name, DN

of object 2…etc>. Microsoft Identity

Integration Services 2003 cannot join, please

examine the object <DN of object that failed

the join, forest name> and the join rules and

determine what attribute(s) caused the

conflict. Please clean up the object to

allow it to be propagated to other forests if

it is authoritative or use Account Joiner to

connect it to a metaverse object to have MIIS

maintain it.

Examine both metaverse objects, and determine which one is the nonauthoritative one. Ensure that the nonauthoritative one, that reports that it is authoritative because it is a user, group or in the authoritative contacts container, is appropriately tagged as nonauthoritative.

After deletion, run import, full synchronization, and export to make the change effective.

If both are authoritative, determine what attribute caused the target object to join to two objects, and appropriately update the target or source objects to remove this join criteria. For example, if the overlapping proxyAddresses caused the problem, delete the proxyAddress that is common to all three objects from the contact that should not contain it.

Contact in connector space tries to join to two possible objects in the metaverse and one of them is a provisioned contact:

There are multiple objects representing the

same entity in the metaverse, they are

<forest name, DN of object 1, forest name, DN

of object 2…etc>. One of these objects:

<forest name, DN of object> was created by

Microsoft Identity Integration Services 2003.

This object will be deleted and the join will

take place with this object <forest name, DN

of object>.

No action required

Contact from the authoritative contacts organizational unit attempts to join when it should be projected:

There are two authoritative objects

representing the same entity in the

metaverse, they are <forest name, DN of

object 1, type of object; forest name, DN of

object 2, type of object…etc>. One of these

objects <forest name, DN of object from

forest where contact in connector space is

Examine both metaverse objects, and determine which one is the nonauthoritative one. Ensure that the nonauthoritative one that reports that it is authoritative because it is a user, group or in the authoritative contacts container is appropriately tagged as nonauthoritative.

After deletion, run import, full synchronization, and export to make the change effective.


from forest indicated by contact forest> will

be propagated to other forests until this

conflict is resolved by removing or modifying

one of the objects so that they no longer

collide.

Provisioning messages

User - A contact for this user object <CN of

Person> object called contact <DN of contact>

already exists in forest <target forest

name>. If you would like to preserve this

contact and have us manage it, please move

the contact into the Synchronization

organizational unit. If you would like us to

create a new contact and manage it, please

delete this one.

User - Multiple contacts for this user object

<CN of Person> object already exist, they

are: contact 1<DN of contact> already exists

in forest <target forest name> | contact 2

<DN of contact> already exists in forest

<target forest name>. If you would like to

preserve a contact and have us manage it,

please move the contact into the

synchronization organizational unit and

delete all others. If you would like us to


delete all other contacts.

Contact - A contact for this contact object

<CN of contact_forest from forest <source

forest name>called contact <DN of contact>

already exists in forest <target forest

name>. If you would like to preserve this

contact and have us manage it, please move

the contact into the synchronization



delete this one.

Contact - Multiple contacts for this contact

object <CN of contact_forest> from forest

<source forest name> already exist, they are:

contact 1<DN of contact> already exists in

forest <target forest name> | contact 2 <DN

of contact> already exists in forest <target

forest name>. If you would like to preserve

a contact and have us manage it, please move

the contact into the synchronization

organizational unit and delete all others.

If you would like us to create a new contact

and manage it, please delete all other

contacts.

Group - A contact for this Group object <CN

of Person> object called contact <DN of

contact> already exists in forest <target


forest name>. If you would like to preserve

this contact and have us manage it, please

move the contact into the synchronization



delete this one.

Group - Multiple contacts for this Group

object <CN of Person> object already exist,

they are: contact 1<DN of contact> already

exists in forest <target forest name> |

contact 2 <DN of contact> already exists in

forest <target forest name>. If you would

like to preserve a contact and have us manage

it, please move the contact into the

synchronization organizational unit and

delete all others. If you would like us to


delete all other contacts.

Deprovisioning messages

When any object is deprovisioned that is not in the Synchronization organizational unit, the following message is written to the log:

The source object <source object CN>

associated with this target object <target

object name> from forest <target forest name>

has been deleted, the target object should

also be deleted but it is outside the

SYNCHRONIZATION ORGANIZATIONAL UNIT. Please

delete the object manually or move it into

the SYNCHRONIZATION ORGANIZATIONAL UNIT.

Projection messages

User found in the Synchronization organizational unit:

A user object <connector space entry of

object = DN of object, MA name> has been

found in the synchronization organizational

unit, this will not be projected, please move

it out of the synchronization organizational

unit if you want this object to propagate to

other forests.

Group found in the synchronization organizational unit:

A group object <connector space entry of

object = DN of object, MA name> has been

found in the synchronization organizational

unit, this will not be projected, please move

it out of the synchronization organizational

unit if you want this object to propagate to

other forests.

Attribute Flow Messages

When target address cannot be created for a user or a group because there is no match between proxyAddresses and the first SMTP mail domain suffix provided by the administrator, Microsoft Identity Integration Services


2003 throws an exception and logs an error.

Other messages

If changes are made to the XML configuration files to include new objects but not the custom extensions, Microsoft Identity Integration Services 2003 throws an UnexpectedDataException and logs it.

If a user adds a label for a scripted flow rule, join rule, but does not update the custom extensions, Microsoft Identity Integration Services 2003 throws an extension.

Adding an object and using existing attribute flow rules will throw an exception because the administrator must confirm that the flow rules apply to this object type.


Appendix B: GAL Sync Mapping Types

Attribute mapping is defined in one of two types. The following table describes the three attribute mapping types.

Table A.2 Attribute Mapping Types Mapping Type Description Direct Defines a direct relationship between a

single source attribute and a single destination attribute. The destination attribute is assigned the value of the source attribute which cannot be modified by a custom extension. An example would be to map employeeID to userID

Custom Defines a direct relationship between multiple source attributes and a single destination attribute. An example would be to map firstName and lastName to fullName

Constant Defines a single destination attribute and the constant string value that the attribute will have.

Import Attribute flow: Source Forest User to Metaverse Person The following table illustrates the mapping of the Active Directory user object attributes to the metaverse person object attributes.

Source Forest User Object Attribute Metaverse Person Object Attribute Mapping Type

LegacyExchangeDN LegacyExchangeDN Direct

Mail Mail Direct

MailNickname MailNickname Direct

CN CN Direct

TelephoneNumber TelephoneNumber Direct

TargetAddress TargetAddress Rules extension

MSExchMasterAccountSID MSExchMasterAccountSID Direct

MSExchHideFromAddressLists MSExchHideFromAddressLists Direct

HomeMDB homeMDB Direct

ProxyAddresses proxyAddresses Direct

DisplayName displayName Direct

DistinguishedName distinguishedName Direct

SN SN Direct


C C Direct

Company Company Direct

Department Department Direct

Division Division Direct

EmployeeID employeeID Direct

EmployeeType employeeType Direct

GivenName givenName Direct

Manager Manager Direct

O O Direct

Title Title Direct

UserCertificate UserCertificate Direct

UserSMIMECertificate UserSMIMECertificate Direct

streetAddress streetAddress Direct

St St Direct

postalCode postalCode Direct

Co Co Direct

physicalDeliveryOfficeName physicalDeliveryOfficeName Direct

msExchAssistantName msExchAssistantName Direct

otherTelephone otherTelephone (multi-valued) Direct

homePhone homePhone Direct

otherHomePhone otherHomePhone (multi-valued) Direct

facsimileTelephoneNumber facsimileTelephoneNumber Direct

Mobile Mobile Direct

telephoneAssistant telephoneAssistant Direct

Pager Pager Direct

Info Info Direct

L (Locality-Name) L (Locality-Name) Direct

MapiRecipient MapiRecipient Rules extension

Initials Initials Direct

—- MSExchOriginatingForest Rules extension

The following logic is applied to the import attribute flow mapping from the source forest user object to the metaverse person object:

1. If a user object has HomeMDB specified, then Microsoft Identity Integration Server 2003 treats it as a mailbox-enabled user, and if does not have it specified, then it is a mail-enabled user.

a. If it is a mailbox-enabled user, the TargetAddress is constructed by matching the value in proxyAddresses with the first value of SMTP mail domain suffixes managed by that forest. If no match is found, Microsoft Identity Integration Server 2003 logs an error.


b. If it is a mail-enabled user and the administrator of the source forest required that all mail to contacts flow through the source forest, then Microsoft Identity Integration Server 2003 constructs a targetAddress based on the matches between proxyAddresses and SMTP mail domain suffixes managed by the source forest, or else Microsoft Identity Integration Server 2003 flows the targetAddress directly. If there are multiple matches, one is selected. If no match is found irrespective of the administrator’s setting, Microsoft Identity Integration Server 2003 flows the targetAddress directly.

2. ProxyAddresses flow directly because Microsoft Identity Integration Server 2003 assumes that there will only be one primary SMTP proxyAddress from the authoritative source object.

3. MapiRecipient: If there is a mailbox associated with the user account, then Microsoft Identity Integration Server 2003 sets the value of the MapiRecipient attribute of the metaverse person object to TRUE, or if it is present, then Microsoft Identity Integration Server 2003 sets the value of the MapiRecipient attribute of the metaverse person object to the same value as the MapiRecipient attribute of the mailbox.

4. MSExchOriginatingForest: This value is generated by using the DN to construct a DNS forest name. Therefore CN=MyName,CN=Users,DC=Fabrikam,DC=com could be translated as ‘Fabrikam.com,’ being the DNS name of the forest and the attribute populated in the metaverse person object attribute and flowed out to the contact in the target forest. The process is as follows:

a. Parse leftwards until the first Domain Congroller

b. Extract out everything after the ‘=’ up to the separator ‘,’

c. Put a dot after the extracted string and check if any other “DC” appears to the left. Return to step a if one does or else return the string.


Import Attribute Flow: Source Forest Contact to Metaverse Contact_Forest

The following table describes the mapping of the Active Directory contact object attributes to the metaverse contact_Forest object attributes.

Source Forest Active Directory Contact Object Attribute

Metaverse contact_forest Attribute

Mapping Type

LegacyExchangeDN LegacyExchangeDN,

Forest_LegacyExchangeDN Rules extension

Mail Mail Direct


CN CN Direct


targetAddress targetAddress Rules extension

Secretary Secretary Direct


proxyAddresses proxyAddresses Direct

displayName displayName Direct

distinguishedName distinguishedName Direct

Name Name Direct

SN SN Direct

C C Direct




employeeID employeeID Direct

employeeType employeeType Direct

givenName givenName Direct


O O Direct

Title Title Direct


St St Direct


Co Co Direct



otherTelephone otherTelephone Direct



otherHomePhone otherHomePhone Direct


mobile mobile Direct


Pager Pager Direct

Info Info Direct


MapiRecipient MapiRecipient Direct


--- MSExchOriginatingForest SCRIPTED

The following logic is applied to the import attribute flow mapping from the source forest contact object to the metaverse contact_forest object:

1. If the contact is from the forest specified in the contact_forest object type, then the import attribute flow is generated as follows: the multivalued LegacyExchangeDN attribute of the contact object in Forest1 flows directly to the multivalued Forest1_LegacyExchangeDN attribute of the contact_Forest1 object. This is a direct import attribute flow that is not part of a rules extension.

2. If the contact is not from the forest specified in the contact_forest object type, then the import attribute flow generated is as follows: the multivalued LegacyExchangeDN attribute of the contact object in Forest2 flows directly to the multivalued Forest2_LegacyExchangeDN attribute of the contact_Forest2 object. This is a direct import attribute flow that is not part of a rules extension.

3. If the administrator of the forest specified in contact_forest requires that all mail to contacts flow through the source forest, then Microsoft Identity Integration Server 2003 constructs a targetAddress based on the matches between proxyAddresses and SMTP mail domain suffixes managed by the source forest; otherwise Microsoft Identity Integration Server 2003 flows the targetAddress directly. If there are multiple matches, Microsoft Identity Integration Server 2003 will select one. If no match is found irrespective of the administrator’s setting, then Microsoft Identity Integration Server 2003 should flow targetAddress directly.

4. ProxyAddresses flow directly because Microsoft Identity Integration Server 2003 assumes that there will only be one primary SMTP proxyAddress from the authoritative source object.

5. MSExchOriginatingForest: This value is generated by using the DN to construct a DNS forest name. Therefore: CN=MyName,CN=Users,DC=Fabrikam,DC=com could be translated into ‘Fabrikam.com,’ being the DNS name of the forest and the attribute populated in the metaverse person object attribute, and flowed out to the contact in the target forest. The process would be as follows:

d. Parse leftwards until the first DC

e. Extract out everything after the ‘=’ up to the separator ‘,’

f. Put a dot after the extracted string and check if any other “DC” appears to the left. Return to step a if one does or else return the string.


Import Attribute Flow: Source Forest Group to Metaverse Group The following table describes the mapping of the Active Directory group object attributes to the metaverse group object attributes.

Source Forest Active Directory Group Object Attribute Metaverse Group Object Attribute Mapping Type

LegacyExchangeDN LegacyExchangeDN Direct

Mail Mail Direct


CN CN Direct

ProxyAddresses targetAddress Rules extension


ProxyAddresses proxyAddresses Direct

DisplayName DisplayName Direct


—- MSExchOriginatingForest Rules extension

The following logic is applied to the import attribute flow mapping from the source forest group object to the metaverse group object:

7. Microsoft Identity Integration Server 2003 constructs a targetAddress based on the matches between proxyAddresses and the first SMTP mail domain suffix managed by the source forest. If no match is found, Microsoft Identity Integration Server 2003 logs an error.

8. ProxyAddresses flow directly because Microsoft Metadirectory Services 2003 assumes that there will only be one primary SMTP proxyAddress from the authoritative source object.

9. MSExchOriginatingForest: This value is generated by using the DN to construct a DNS forest name. Therefore CN=MyName,CN=Users,DC=Fabrikam,DC=com could be translated into ‘Fabrikam.com,’ being the DNS name of the forest and the attribute populated in the metaverse person object attribute and flowed out to the contact in the target forest. The process is as follows:

a. Parse leftwards until the first DC

b. Extract out everything after the ‘=’ up to the separator ‘,’

c. Put a dot after the extracted string and check if any other “DC” appears to the left. Return to step a if one does or else return the string.

Import Attribute Flow: Target Forest Contact to Metaverse Person The following table describes the mapping of the target forest contact object to the metaverse person object.


Target Forest Contact Object Attribute

Metaverse Person Object Attribute Mapping Type

LegacyExchangeDN Forest_LegacyExchangeD

N Direct.

The value of LegacyExchangeDN of the contact object is assigned from the target forest to the multiple attributes called “Forest”_LegacyExchangeDN.

Import Attribute Flow: Target Forest Contact to Metaverse Group The following table describes the mapping of the target forest contact object to the metaverse group object.

Target Forest Contact Object Attribute

Metaverse Group Object Attribute Mapping Type

LegacyExchangeDN Forest_LegacyExchangeD

N Direct.

The value of LegacyExchangeDN of the contact object is assigned to the multiple attributes called “Forest”_LegacyExchangeDN.


Export Attribute Flow: Metaverse Person to Target Forest Contact The following table describes the mapping of the metaverse person object attributes to the target forest contact object.

Metaverse Person Object Attribute

Target Active Directory Contact Object Attribute

Mapping Type

LegacyExchangeDN Added to ProxyAddresses Rules

extension

Forest_LegacyExchangeDN(s) Not propagated Not propagated

Mail Mail Direct


CN CN Direct


TargetAddress targetAddress Direct


MSExchMasterAccountSID Not propagated Not propagated


HomeMDB Not propagated Not propagated

ProxyAddresses Added to proxyAddresses Rules extension



Name Name Direct

SN SN Direct

C C Direct








O O Direct

Title Title Direct

MapiRecipient MAPI_RECIPIENT Direct

UserCertificate UserCertificate Direct

UserSMIMECertificate UserSMIMECertificate Direct


St St Direct



Co Co Direct









Pager Pager Direct

Info Info Direct



MSExchOriginatingForest MSExchOriginatingForest Direct

The following logic is applied to the export attribute flow mapping from the metaverse person object to the target forest contact object:

1. The legacyExchangeDN of the contact object is generated and assigned as follows:

a. It must equal the legacyExchangeDN of the msExchAdminGroup object in Active Directory at “CN=Administrative Groups,CN=Exchange Org Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=...”.

b. All separators in the legacyExchangeDN must be lower case (/o=, /ou=, /cn=).

c. It must have a GUID generated and appended to it.

2. The multivalued LegacyExchangeDN of the person object is added to the proxyAddresses of the contact.

3. The primary SMTP proxyAddress of the source object, propogated through the metaverse object, is the one that Microsoft Identity Integration Server 2003 wants to propagate as the primary SMTP on all target objects in all the forests. The proxyAddress attribute is cleared and all the values in the metaverse are flowed to the target value. Therefore, whatever the primary SMTP proxyAddress is on the source, it is flowed from the source object to the metaverse to the target.

Export Attribute Flow: Metaverse Person to Target Forest User The following table describes the mapping of the metaverse person object attributes to the target Active Directory forest user object.

Note In addition to the above, an Exchange administrative group maps to the LegacyExchangeDN target contact object attribute.


Metaverse Person Attribute Target Active Directory User Object Attribute

Mapping Type

Forest_LegacyExchangeDN(s) ProxyAddresses Rules extension

Microsoft Metadirectory Services 2003 ensures that ProxyAddresses of Active Directory user objects contain all the Forest_LegacyExchangeDN attributes, where Forest is not the same as the forest from which the user account is coming.

Export Attribute flow: Metaverse contact_forest to Target Forest Contact

The following table describes the mapping of the metaverse contact_Forest object attributes to the target Active Directory forest contact object.

Metaverse contact_forest Object Attribute

Target Active Directory Contact Object Attribute Mapping Type

LegacyExchangeDN Added to ProxyAddresses Rules extension

Forest_LegacyExchangeDN(s) Added to ProxyAddresses Rules extension

Mail Mail Direct


CN CN Direct


TargetAddress targetAddress Direct



proxyAddresses proxyAddresses Direct



Name Name Direct

SN SN Direct

C C Direct








O O Direct

Title Title Direct


StreetAddress streetAddress Direct


St St Direct

PostalCode postalCode Direct

Co Co Direct









Pager Pager Direct

Info Info Direct




The following logic is applied to the export attribute flow mapping from the metaverse contact_forest object to the target forest contact object:

1. The legacyExchangeDN of the contact object is generated and assigned as follows:

It must equal the legacyExchangeDN of the msExchAdminGroup object in Active Directory at “CN=Administrative Groups,CN=Exchange Org Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=...”.

All separators in the legacyExchangeDN must be lower case (/o=, /ou=, /cn=).

It must have a GUID generated and appended to it.

2. The values of the multivalued LegacyExchangeDN of the contact_forest object are added to the proxyAddresses attribute of the contact.

3. The primary SMTP proxyAddress of the source object, through the metaverse object, is the one that Microsoft Identity Integration Server 2003 wants to propagate as the primary SMTP on all target objects in all the forests. The proxyAddress attribute is cleared and all the values in the metaverse are flowed to the target value. Therefore, whatever the primary SMTP proxyAddress is on the source, it is flowed from the source object to the metaverse to the target.

4. Ensure that ProxyAddresses of Active Directory contact_forest contain all the Forest_LegacyExchangeDN attributes where Forest is not the same as the forest from which the user account is coming. This is done as part of a rules extension.

If the contact is from the forest specified in the contact_forest object type, then the values of the multivalued LegacyExchangeDN attribute for the contact_forest object flow to the proxyAddresses attribute of the target forest contact object.

If the contact is not from the forest specified in the contact_forest object type, then there is no export attribute flow generated for the Forest(s)_LegacyExchangeDN attribute.


Export Attribute flow: Metaverse Group to Target Forest Group The following table describes the mapping of the metaverse group object attributes to the target Active Directory forest group object attribute.

MV Group Attribute AD Group Attribute Mapping Type Forest_LegacyExchangeDN(s) ProxyAddresses Rules extension

Microsoft Identity Integration Services 2003 ensures that ProxyAddresses of Active Directory user objects contains all the Forest_LegacyExchangeDN attributes where Forest is not the same as the forest from which the user account is coming.


Export Attribute Flow: Metaverse Group to Target Forest Contact

The following table describes the mapping of the metaverse group object attribute to the target Active Directory forest contact object attribute.

Metaverse Group Object Attribute Target Active Directory Contact Object Attribute Mapping Type

(NOT an metaverse attribute) Administrator user interface setting: Exchange Administrative Group

LegacyExchangeDN Rules extension

LegacyExchangeDN Added to ProxyAddresses Rules extension

Mail Mail Direct


CN CN Direct

TargetAddress TargetAddress Direct


proxyAddresses ProxyAddresses Rules extension

DisplayName DisplayName Direct

distinguishedName DistinguishedName Direct



The following logic is applied to the export attribute flow mapping from the metaverse contact_forest object to the target forest contact object:

1. The LegacyExchangeDN of the contact object is generated and assigned as follows:

a. It must equal the LegacyExchangeDN of the msExchAdminGroup object in Active Directory at “CN=Administrative Groups,CN=Exchange Org Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=...”.

b. All separators in the legacyExchangeDN must be lower case so (/o=, /ou=, /cn=).

c. It must have a GUID generated and appended to it.

2. The values of the multivalued LegacyExchangeDN attribute of the group object are added to the proxyAddresses attribute of the contact.

3. The primary SMTP proxyAddress of the source object is the one that Microsoft Identity Integration Server 2003 wants to propagate as the primary SMTP on all target objects in all the forests. The proxyAddress attribute is cleared and all the values in the metaverse are flowed to the target value. Therefore, whatever the primary SMTP proxyAddress is on the source, it is flowed from the source object to the metaverse to the target.


Appendix C: GAL Sync Provisioning Rules

The changes made to the metaverse during the import of source Active Directory forest data initiate the provision operation, which creates, connects, and disconnects objects in the connector space based on the changes to the metaverse.

There are three objects that are affected by provisioning rules:

User

Group

Contact

For all objects, the provisioning rule depends on the scenario for that object and occurs within the identity integration process shown in Figure 4.3. Some of the rules shown in Figure 4.3 do not apply to all scenarios.

Identity Integration Process

User Object Provisioning Rules The following table lists various scenarios in which a user object is provisioned and the specific provisioning logic that applies to that scenario. The first run profile is a full import with the staging only option and provisioning enabled. The next two run profiles are delta synchronization only and the final run profile is export.


User Object Provisioning Rules

Scenario Provisioning Logic

For a mail-enabled or mailbox-enabled user in the source forest, no corresponding contact exists in the target forest.

Provisioning case 1: If an object is a person and it does not have a connector to any contact, then a connector is added and creates a contact in the target forest in the target Active Directory forest organizational unit with the same name. If a contact with that name already exists, create a contact with the following string concatenation logic: target forest contact -> common name = Person -> common name + Person->department.

For example, if the target forest contact common name is Mike Danseglio, this name is concatenated with the department name Fabrikam, and propagated to the metaverse as Mike Danseglio (Fabrikam).

Mail-enabled or mailbox-enabled user in the source forest and there is a contact in the target forest corresponding to this user in the synchronization OU.

Provisioning case 2: For a metaverse person entry for both Management Agents, if the number of connectors is equal to 1, and the connector for the contact is inside the target forest organizational unit:

• If common name (cn) of connector equals the cn of a metaverse object concatenated with a suffix (the suffix may have been added to avoid name collisions), no provisioning occurs.

• If cn of connector does not equal the cn of a metaverse object concatenated with a suffix, the source object has been renamed. Consequently, the connector must also be renamed.

Mail-enabled or mailbox-enabled user in the source forest and there is a contact in the target forest corresponding to this user who is not in the synchronization OU.

Provisioning case 3: For a metaverse person object for both Management Agents, if the number of connectors is equal to 1 and the distinguished name (DN) of that connector indicates that it is outside the target forest organizational unit, an error is logged to indicate that the contact already exists and must be moved or deleted.

Mail-enabled or mailbox-enabled user in the source forest and there is more than one contact in the target forest corresponding to this user in the synchronization OU.

An error is logged indicating that you must move the incorrect data, contact to the synchronization OU, or delete the data because contacts that are outside the synchronization OU cannot be managed by Microsoft Identity Integration Services 2003.

Provisioning case 4: For a metaverse person object for both Management Agents, if the number of connectors is greater than 1, the following rules are applied to every connector:

• If the connector was created by provisioning (that is, by Microsoft Identity Integration Server 2003), it is disconnected.

• If the connector was created by another process and joined (it may or may not be in the Microsoft Identity Integration Server 2003 target forest organizational unit, no operation is performed and an error is logged describing that there are duplicate contacts, that all except one must be deleted, and that one must be moved into the Microsoft Identity Integration Services 2003 target forest organizational unit to be managed by Microsoft Identity Integration Services 2003.


Mail-enabled or mailbox-enabled user exists and there is more than one contact in the target forest corresponding to this user. The additional contacts may or may not be in the synchronization OU.

An error is logged indicating that you must move the incorrect data, contact to the synchronization OU, or delete the data because contacts that are outside the synchronization OU cannot be managed by Microsoft Identity Integration Server 2003, and it does not allow duplicate contacts in the same forest representing the same source object.

For a metaverse person object for both Management Agreements, if the number of connectors is equal to 1 and the distinguished name (DN) of that connector indicates that it is outside the target forest organizational unit, an error is logged to indicate that the contact already exists and must be moved or deleted.

User is deleted. When a deletion is received, the following process occurs:

1. Connector is disconnected from metaverse object, (connector space and metaverse link tables lose an entry).

2. Disconnector is deleted. (connector space entry table loses an entry).

3. Metaverse deletion is called and the rule determines if it is a master/source object, and deletes the object from the metaverse if is a master.

4. When the object from metaverse is deleted, deprovisioning is called and deletes connector objects for all contact objects linked to that metaverse person object.

5. After export, Contacts are deleted from Active Directory if they are in the synchronization OU.

User is changed. When a change is received, the following process occurs:

1. Connector space filter rules will fail.

2. Connector is disconnected from metaverse object. Connector space and metaverse link tables lose an entry.

3. Disconnector is deleted. Connector space entry tables loses an entry.

4. Metaverse deletion is called and the rule determines if it is a master/source object, and deletes the object from the metaverse if is a master.

5. When object from metaverse is deleted, deprovisioning is called and deletes connectors for all contact objects linked to that metaverse person object.

6. Connector space filter rules succeed.

7. Connector changes.

8. Import attribute flow is reevaluated.

9. Provisioning case 2 succeeds and objects in connector space are updated.

Contact Object Provisioning Rules The following lists various scenarios in which a contact object is provisioned and the specific provisioning logic that applies to that scenario. The first run profile is a full import with the staging only option and provisioning is enabled. The next two run profiles are delta synchronization only and the final run profile is export.

Contact Object Provisioning Rules



A contact object in the source forest, but there is no contact in the target forest corresponding to this contact; and the contact meets the projection requirements outlined in the projection section.

Provisioning case 1: For the metaverse contact_forest entry for both Management Agents, if there is no connector, add a connector for a contact in the Microsoft Identity Integration Services 2003 target forest organizational unit.

If an object is in the contact_forest and it does not have a connector to any contact, then add a connector to create a contact in the Microsoft Identity Integration Services 2003 target forest organizational unit with the same name. If a contact with that name already exists, create a contact with the following string concatenation logic: target forest Active Directory contact -> common name = contact_forest -> common name + contact_forest->department.

A contact object exists in the source forest, but there is no contact in the target forest corresponding to this contact; and the contact does not meet the projection requirements outlined in the projection section of this document.

If projection rules are not satisfied, an exception is identified and that object is not propagated into any other forest. Also errors are logged.

A contact object in the source forest and there is a contact in the target forest corresponding to this contact in the Microsoft Identity Integration Services 2003 synchronization OU.

Provisioning case 2: For the metaverse contact_forest entry for both Management Agents, if the number of connectors is 1, and the connector for the contact is inside the target forest organizational unit:

• If the cn of a connector equals the cn of any metaverse object concatenated with a suffix (the suffix may have been added to avoid name collisions), no operation is performed.

• If the cn of a connector does not equal the cn of any metaverse object concatenated with a suffix, then the source object has been renamed. Consequently, the connector must also be renamed, and if there is a name collision as a result of this rename, resolve the collision using the same logic as in the first contact object provisioning rule.

A contact object exists and there is a contact in the target forest corresponding to this contact, but not in the synchronization OU.

An error is logged, informing administrators repair the discrepancy and either move incorrect data (contact) to the synchronization OU, or delete it, because contacts that are outside the synchronization OU are not managed by this process.

Provisioning case 3: For the metaverse contact_forest entry for both Management Agents, if the number of connectors is 1 and the DN of that connector indicates that it is outside the Microsoft Identity Integration Services 2003 target forest organizational unit, an error is logged, describing that the contact already exists and must be moved or deleted.


A contact object exists and there is more than one contact in the target forest corresponding to this contact. (The additional contacts may or may not be in the synchronization OU.

An error is logged, informing administrators that they must repair the data and either move the contact data to the synchronization OU or delete it because contacts outside the synchronization OU are not managed and duplicate contacts in the same forest representing the same source object are not allowed.

Provisioning case 4: For the metaverse contact_forest entry for both Management Agents, if the number of connectors is greater than 1, the following rules are applied to every connector:

• If the connector was created by provisioning (i.e. by Microsoft Identity Integration Services 2003), it is disconnected.

• If the connector was created by another process and joined (may or may not be in the Microsoft Identity Integration Services 2003 target forest organizational unit), no operation is performed and an error is logged describing that there are duplicate contacts, and that all except one must be deleted, and that one must be moved into the Microsoft Identity Integration Services 2003 target forest organizational unit to be managed by Microsoft Identity Integration Services 2003.

Contact object outside the synchronization OU, in authoritative contacts container, is deleted.

When the deletion is received, the following process occurs:


2. Disconnector is deleted. (Connector space entry tables lose an entry.)

3. Metaverse deletion is called and the rule checks if it is a master/source object. The contact_forest object will be deleted if the source Active Directory object deleted was in the authoritative contacts OU and if the contact is from the forest in contact_forest.

4. Deprovisioning is called, and because the management agent is not for the forest mentioned in contact_forest, and the connector is for an object in the synchronization OU, then it deprovisions to delete the contact in the Active Directory.

Contact object outside the synchronization OU, or the outside authoritative contacts container, is deleted.

When the deletion is received, the following process occurs:

1. Connector is disconnected from metaverse object, (connector space metaverse link tables lose an entry).

2. Disconnector is deleted. (Connector space entry tables lose an entry.)

3. Metaverse deletion is called and the rule checks if it is a master/source object. The contact_forest object is deleted if the source Active Directory object deleted was in the authoritative contacts OU and if the contact is from forest mentioned in contact_forest. In this scenario, it was not in the authoritative OU, and therefore it is not deleted.


Contact outside the synchronization OU, or in the authoritative contacts OU, is changed.

The following process occurs:

1. Import with provisioning enabled.

2. Connector space filter rules fail.

3. Deletion is received.


5. Disconnector is deleted. (connector space entry tables lose an entry.)

6. Metaverse deletion is called and the rule will check if it is a master/source object. The contact_forest object will be deleted if the source Active Directory object deleted was in the authoritative contacts OU and if the contact is from forest in contact_forest.

7. Deprovisioning is called, and because the management agent is not for the forest mentioned in contact_forest, and the connector is for an object in the synchronization OU, then it is deprovisioned to delete the contact in the Active Directory.




Provisioning case 2 succeeds and objects in the connector space are updated.

Contact object is outside the synchronization OU, or the outside authoritative contacts OU is changed.


1. Import with provisioning enabled.


3. Deletion is received.


5. Disconnector is deleted. (connector space entry tables loses an entry.)

6. Metaverse deletion is called and the rule checks if it is a master/source object. It is not, because it is a contact outside of the authoritative contacts OU, therefore no further processing occurs.




10. Provisioning case 3 or 4 succeed.

Contact object in the synchronization OU is deleted (not by Microsoft Identity Integration Services 2003).


1. Connector disappears, provisioning is called, and the next export creates the object again.

2. Provisioning case 1 applies.

Contact object in the synchronization OU is created (not by Microsoft Identity Integration Services 2003).


1. Joins to something and, when provisioning is called, it will log an event.

2. Provisioning cases 2, 3, or 4 apply.


Contact object is modified in synchronization OU (not by Microsoft Identity Integration Services 2003).

If there is an import attribute flow defined for contact to person, then it will flow back to the source object to which that contact is joined. Nothing on the source object is overwritten, only the LegacyExchangeDN is added to the proxyAddresses of this attribute.

If there is no import attribute flow defined for contact to source object, it is rewritten during the next export so that no synchronized information is flowed back, just data from that forest. Exceptions are LegacyExchangeDN and proxyAddresses, because proxyAddresses of any object should not be overwritten and because legacyExchangeDN is assigned by the target forest.

Group Object Provisioning Rules The following table lists various scenarios in which a group object is provisioned and the specific provisioning logic that applies to that scenario. The first run profile is a full import with the staging only option and provisioning is enabled. The next two run profiles are delta synchronization only and the final run profile is export.

Group Object Provisioning Rules


Mail enabled or mailbox enabled group object in the source forest and there is no contact in the target forest corresponding to this group.

Provisioning case 1: For the metaverse group entry for both Management Agents, if there is no connector, a connector is added for a contact in the Microsoft Identity Integration Services 2003 target forest organizational unit.

If the object is a group and it does not have a connector to any contact, then a connector is added in the Microsoft Identity Integration Services 2003 target forest organizational unit to create a contact in the target forest with the same name. If a contact with that name already exists, a contact is created with the following string concatenation: target forest AD contact -> common name = Group -> common name + Group+1.

Mail enabled or mailbox enabled group in the source forest and there is a contact in the target forest corresponding to this group in the synchronization OU.

Provisioning case 2: For the metaverse group entry for both Management Agents, if the number of connectors is 1, and the connector for the contact is inside the Microsoft Identity Integration Services 2003 target forest organizational unit:

• If the cn of the connector equals the cn of metaverse object concatenated with a suffix (for potential name collision logic renames), then no operation is performed.

• If the cn of the connector does not equal the cn of metaverse object concatenated with a suffix, then the source object has been renamed. Consequently, the connector must also be renamed and if there is a name collision as a result of this rename, it must be resolved using the same logic as in the first group object provisioning rule.

Mail enabled or mailbox enabled group in the source forest and there is a contact in the target forest corresponding to this group is NOT in the synchronization OU.

An error is logged to inform the administrator to repair this situation and either move the corrupt data/contact to the synchronization OU or delete it because contacts that are outside the synchronization OU are not managed by Microsoft Identity Integration Services 2003.

For the metaverse group entry for both Management Agents, if the number of connectors is 1, and the DN of that connector indicates that it is outside the Microsoft Identity Integration Services 2003 target forest organizational unit, an error is logged that describes that the contact already exists and must be moved or deleted.


Mail enabled or mailbox enabled group in the source forest and there is more than one contact in the target forest corresponding to this group. (The additional contacts may or may not be in the synchronization OU.)

An error is logged to inform the administrator to repair this situation and either move the corrupt data/contact to the synchronization OU or delete it because contacts outside the synchronization OU are not managed and duplicate contacts in the same forest representing the same source object are not allowed.

Provisioning case 4: For the metaverse person entry for both Management Agents, if the number of connectors is greater than 1, then for every connector:

• If the connector was created by provisioning (that is, by Microsoft Identity Integration Services 2003), it is disconnected.

• If the connector was created by another process and joined (may or may not be in the Microsoft Identity Integration Services 2003 target forest organizational unit), no operation is performed and an error is logged, describing that there are duplicate contacts, and that all except one must be deleted, and that one must be moved into the Microsoft Identity Integration Services 2003 target forest organizational unit to be managed by Microsoft Identity Integration Services 2003.

Group object is deleted. When a deletion is received, the following process occurs:


2. Disconnector is deleted. (connector space entry tables lose an entry.)

3. Metaverse deletion is called and the rule checks if it is a master/source object, deletes the object from the metaverse if it is a master.

4. When object from metaverse is deleted, deprovisioning is called and deletes connectors for all contact objects linked to that metaverse group object.

Group object is changed.

When a change is received, the following process occurs:



3. Disconnector is deleted. (connector space entry table loses an entry).

4. Metaverse deletion is called and the rule checks if it is a master/source object, then deletes the object from the metaverse if is a master.

5. When object from metaverse is deleted, deprovisioning is called and deletes connectors for all contact objects linked to that metaverse group object.




Provisioning case 2 succeeds and objects in connector space are updated.

Metaverse Object Deletion Rules The next table lists the three metaverse object deletion rules extensions.


Metaverse Deletion Rules

Rule Description

User If the object that was deleted is a person, then it is deleted from the metaverse.

Contact If the Management Agent where the connector disappeared is from contact_forest, then it is deleted.

Group If the object that was deleted is a group, then it is deleted from the metaverse.

Deprovisioning Rules The next table lists the three deprovisioning rules.

TDeprovisioning Rules

Rule Description

User When the metaverse person object is deleted, the contact object is deleted if it is in the synchronization organizational unit. If not, it is logged.

Contact When the metaverse contact_forest object is deleted, the contact object is deleted if it is in the synchronization organizational unit. If not, it is logged.

Group When the metaverse group object is deleted, the contact object is deleted if it is in the synchronization organizational unit. If not, it is logged.


Acknowledgments Microsoft Employee

Vincent Yim

External Websites:

http://www.microsoft.com/windowsserver2003/technologies/directory/miis/default.mspx

Module 8: Cross- Forest/Multi-Forestgattner.name/simon/public/microsoft/MS Exchange/70... · Topic...

Documents

Transcript of Module 8: Cross- Forest/Multi-Forestgattner.name/simon/public/microsoft/MS Exchange/70... · Topic...