Tài liệu Module 8: Cross- Forest/Multi-Forest pptx

Contents
Overview 1
Lesson 1: The Cross-forest Specification 2
MIIS Components 8
Lab 8.1: Getting to know MIIS 2003 and GAL Sync Management Agent 26
Lesson 3: Cross-Forest SMTP Mailflow 32
Lesson 4: InterOrg Public Folder Replication 35
Lab 8.2: Cross Forest Practice 47
Appendix A GAL Sync Log and Error Messages 50
Appendix B: GAL Sync Mapping Types 54
Appendix C: GAL Sync Provisioning Rules 67
Acknowledgments 76

Module 8: Cross-
Forest/Multi-Forest
ii Module 8: Cross-Forest/Multi-Forest

Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no
part of this document may be reproduced, stored in or introduced into a retrieval system, or

transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2003 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, Excel, Exchange Server
5.5, Exchange 2000 Server, Exchange Server 2003, Internet Explorer, Internet Information Server,
Word are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.

The names of actual companies and products mentioned herein (Groupwise, IBM, Lotus cc:Mail,
Lotus Notes, Netscape, Oracle) may be the trademarks of their respective owners.

Module 8: Cross-Forest/Multi-Forest 1

Overview


 Topic 1 The cross-forest Specification
 Topic 2 Microsoft Identity Integration Services (MIIS) 2003 and Global
Address List (GAL) Sync
 Topic 3 Cross-forest SMTP mail flow
 Topic 4 Inter-Org public folder replication

At the time of this writing, only RC1 of MIIS 2003 was available for reference.

As such, many of the screenshots may be out of date. Additionally, the MIIS
product name was renamed prior to the Release To Manufacture RTM in July
2003. Thus, any references to MMS or “Microsoft Meta Directory Services”
should be considered MIIS or “Microsoft Identity Integration Services.”
Introduction
2 Module 8: Cross-Forest/Multi-Forest

Lesson 1: The Cross-forest Specification


Introduction
Why do customers deploy multiple forests?
Customers deploy multiple forests because it is more secure. Since an Active
Directory domain was no longer a true security boundary, forests became the
entities in which future topologies were planned.
Customers want administration autonomy and data isolation. They could
achieve this in Exchange 5.5, by simply attaching any new Exchange 5.5 site to
an existing organization, and thus form a chain of peer sites with a common
GAL. Yet trusts were not necessary between each domain that was the realm of
an Exchange 5.5 site. Therefore data could be isolated, and administration could
be left in the hands of each site/Windows NT domain administrator.
Exchange 2000 introduced an architectural regression. Customers could no
longer achieve administration autonomy and data isolation because Exchange
2000 organizations were each bounded by a single forest. This meant that each
Global address list was limited to this same boundary. There was no way to
attach administrative groups to existing organizations outside of the forest to
share a common GAL. Thus, it was extremely difficult to replace traditional
site/domain boundaries with multi-domain, single-forest model. For those that
tried, they found that transitive trusts and Exchange groups were so invasive
that any domain administrators could potentially gain access to other domains’

mailboxes within the forest.
Goals:
The goal is to deploy multiple forests to achieve core messaging functionality
as it works in the single-forest case. This includes
- Basic mail functionality
- Calendaring
Module 8: Cross-Forest/Multi-Forest 3

- Common GAL
Important: There are certain features which are not available in Cross-forest
deployment, such as the ability to view distribution group membership whose
members are stored in another forest. Further, Delegate Access will not be
supported across forests. (Currently, a contact cannot be given delegate access
to a mailbox). Thus, customers should not expect to achieve full full-feature
parity with single-forest installations.
Added benefits:
- Customers have an alternative to using the Active Directory
Connector’s inter-organizational connection agreements, which were not
supported for coexistence between different organizations.
- Provide an administrative model somewhat similar to peer-to-peer
directories as was the case in Exchange 5.5, so that Exchange 5.5 customers
may ease into Exchange 2003 without destroying their existing administrative
model.


The bare requirements to make a multi-forest topology work for just basic
messaging (basically sending messages and no free/busy features) is Directory
Synchronization and mail flow. Essentially, a synchronized global GAL needs
to be available to all forests and a transport route needs to be in place to allow
mail to flow between them.

Since there is no built-in feature to automate sharing of GAL information
between forests, the cross-forest spec combines unrelated technologies to
achieve the goals. These technologies include
 Microsoft Identity Integration Server (MIIS) to achieve directory
synchronization.
 Customized SMTP connectors for mailflow between forests.
 Optional components (IORepl, x-forest movemailbox) may be added to
the cross-forest scenario so that the multi-forest deployments come
closer to parity with a single-forest scenario.


Components
4 Module 8: Cross-Forest/Multi-Forest

MIIS 2003 and GAL Sync


Definition
This topic covers Microsoft Identity Integration Server version 2003 and the
Global Address List Synchronization (Galsync) process, which perform the
directory synchronization. Once set up, users in one forest may look up
recipients in different forests, and the infrastructure for cross-forest mail flow is
established.
History of MIIS
•Previous version bought from Zoomit, Inc.
•Version 2.2 is no longer for “sale.” “Sale” is in quotes because if a customer
has a Windows 2000 Advanced Server license, then this product is available at
no extra cost. However, in order to implement this product they will need to
engage Microsoft Consulting Services (MCS) or an Authorized MIIS Partner.
Version 2.2 is a high-touch, complex, difficult to deploy product. As it is

particularly difficult to setup and configure, in the hands of the untrained, it is
possible to do considerable damage to the connected systems. For this reason
MMS 2.2 was never actually sold as a “product” in the true sense. It did not
have a SKU, and was not on any parts list from Microsoft. However, Microsoft
would license the product to customers who had a Windows 2000 Advanced
Server license (at no additional cost), and took a services engagement from
MCS, or from an Authorized MIIS Partner.
•Version 3.0 (renamed to MMS 2003, then renamed to MIIS 2003) – Rewritten
from the ground-up. There is still an MIIS 2003 partner program, and
lists those that
have been trained on
MIIS 2003 and are ready to help customers. The 3.0/2003
version is considerably improved, and Microsoft believes customers can use the
information (based on scenarios) that ships on the product CD to conduct their
own evaluation, design, test and deployment.
Module 8: Cross-Forest/Multi-Forest 5

Intro to MIIS 2003


Companies often store data about users and objects in multiple data sources –
some within Active Directory forests, but others within other types of data
repositories. Therefore, the identity of a user could be scattered across several
different locations on several different incompatible platforms. Often,
companies need to aggregate (combine) that information into a logical view that
represents the sum of all the identify information for a given object.
Thus, Metadirectories are utilized for identity management, or for massaging
complex data from multiple data sources so that they may be managed easily.
Because the concept is so universal, IBM®, Oracle®, Netscape®, and others
market their own Metadirectory products. Microsoft’s latest offering is called

Microsoft Integrity Information Services (MIIS) version 2003.
MIIS 2003 is a service that collects information from different data sources
throughout an organization and then combines all or part of that information
into an integrated, unified view. This unified view presents all of the
information about an object, such as a person or network resource, that is
contained throughout the organization. In most organizations, the sources data
is typically stored in different directories, databases, and other data repositories
throughout the Information Technology (IT) infrastructure.
After all of the information about a person or resource is combined in the
metadirectory, rules can be applied to decide how this information is managed
and how changes to this information flow out to all of the directories that are
connected to the metadirectory. Therefore, the metadirectory propagates any
changes that originate in one directory to the other directories in the
organization.

6 Module 8: Cross-Forest/Multi-Forest

Glossary:
To use MIIS to manage data, it is important to become familiar with key
concepts and definitions that will assist you in understanding the architecture
and function of MIIS.
Objects and Attributes - Each entry in the Metadirectory is an object, of a
specific type, which is comprised of a number of attributes. For example, the
entry for Kim Rallsis a specific “Person” object, which possesses attributes
(e.g. displayName, Title, Department, telephoneNumber) that are defined for
the “Person” Object Type. Examples of other object types include “Computer,”
“Group,” and “Organizational Unit.” Although Object Types are similar in
function to Lightweight Directory Access Protocol (LDAP) Object Classes,
they do not exhibit inheritance, and an object may be of only one type.
Metaverse and connected directories - The external sources of data for MIIS

are referred to collectively as connected directories. The collection of objects
and attributes which are stored and managed in the MIIS system is the
metaverse. Because one object in the metaverse is likely to represent entries in
more than one connected directory, there will be a conflict if attributes differ for
that object in each connected directory. Therefore, it is important to understand
which connected directory has authority for each object type and attribute, and
therefore which source takes precedence if there is a conflict. This
understanding comes primarily from discussions with the business owners of
the various systems, and is one of the key requirements for success of a
metadirectory implementation project.
Management Agents and Connector Space - The data flow between MIIS
and a specific connected directory is defined in a Management Agent, and data
flows only when a Management Agent is run. Each Management Agent has a
connector space. The connector space is an area (separate from the metaverse)
in which a management agent stores holograms from which changes in data-
state are calculated. A Management Agent may handle all objects in a
connected directory or may be configured to manage only a subset of objects
and their attributes. Every object and attribute from the connected directory
handled by a Management Agent is represented in the connector space. The
Management Agent configuration defines which objects are attributes are
synchronized into the metaverse.
Joins and Projection - If an object from a connected directory is represented in
the metaverse, it is said to be joined. The process by which the synchronization
engine makes the association between an entry in a connector space and a
corresponding entry in the metaverse is known as joining. If an entry in the
connector space is to be represented in the metaverse, but no corresponding
entry in the metaverse can be found by the Join process, a new metaverse object
may be created for this entry (according to how the Management Agent is
configured). The creation of a new metaverse object is known as projection,
and following projection, the connector space entry will be joined to the new

metaverse object.
Connectors and Disconnectors - An object in the connector space may or may
not be joined to an object in the metaverse. If a connector space object is joined
to a metaverse object, it is referred to as a Connector. If it is not joined to a
metaverse object, it is referred to as a Disconnector.
Module 8: Cross-Forest/Multi-Forest 7

GUIDs and Anchor IDs - Each metaverse object is identified by a unique
value know as its Globally Unique ID (GUID). The Join between a connector
space object and its corresponding metaverse object is achieved by storing the
GUID with each connected connector space object.
Similarly, there must be a link between each object in the connected directory
and the connector space, so that the Management Agent can manage the entries
in the connector space with the corresponding entries in the connected
directory. This is achieved through a unique attribute (or a unique combination
of attributes) which originates in the connected directory, and is referred to as
the Anchor ID.
Provisioning and Deprovisioning - It is possible to define object flow rules in
MIIS that imply that the presence of an entry in one connected directory
requires the presence of a corresponding entry in another connected directory.
For example, the existence of an entry in a Human Resources system
(representing an employee) might require the existence of an Active Directory
account for this employee. In order to enforce this rule, MIIS can be configured
to create and remove entries in a connected directory (for example, in Active
Directory). The creation of entries is referred to as provisioning and the removal
of entries is referred to as deprovisioning.
8 Module 8: Cross-Forest/Multi-Forest

MIIS Components

There are three basic areas of storage. The unified view (metaverse), connector
space (where data manipulation takes place), and the connected data sources
from where data is pulled/pushed. The actual manipulation
(joins/adds/extension rules) are performed by the Management Agents. There
are different Management Agents for different types of data sources. Pertaining
to Exchange 2003, there is the Active Directory Global Address List
Synchronization Management Agent (GAL Sync Management Agent) where
our attention will focus later.

Connected Directory
z
Source and/or
destination for
synchronized objects
and attributes

Connector Space (CS)
z
Staging area for all
objects that
synchronize with MMS
z
Persists the import
and export state on
each object
z
Each MA has its own
CS


Metaverse (MV)
z
Central (SQL) store of
identity information
z
Matching CS entries to
a single MV entry is
called “join”
Active Directory
Active Directory
Oracle
Oracle
IPlanet
IPlanet
SAP,JDEdwards
SAP,JDEdwards
,
,
Peoplesoft
Peoplesoft
, etc.
, etc.
Connected
Connected
Data Sources
Data Sources
Metaverse
Metaverse
User
User

Connector
Connector
Space
Space


Module 8: Cross-Forest/Multi-Forest 9

Management Agents can also read/write to/from flat files. For Exchange 2003,
we use cell-based Management Agents. Regardless of the Management Agent
type, the connector space 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.
Metadirectory
Metadirectory
Connector Namespace Metaverse Namespace
Sue Fine
Name
Post Office
Location
Employee #
Sue Fine
Name
Post Office

Location
Employee #
Suzan Fine
Full Name
Title
Employee #
Suzan Fine
Full Name
Title
Employee #
Forest1
Forest1
Forest1
1
1
1
Full Name
Title
Employee #
Full Name
Title
Employee #
Suzan Fine
Suzan Fine
Suzan Fine
Name
Post Office
Location
Employee #
Name

Post Office
Location
Employee #
Sue Fine
Sue Fine
Sue Fine
2
2
2
= Management Agents
= Management Agents
Full Name
Title
Employee #
Full Name
Title
Employee #
Suzan Fine
Suzan Fine
Suzan Fine
3
3
Full Name
Title
Employee #
Full Name
Title
Employee #
Suzan Fine
Suzan Fine

Suzan Fine
Name
Post Office
Location
Employee #
Name
Post Office
Location
Employee #
Sue Fine
Sue Fine
Sue Fine
Full Name
Title
Employee #
Name
Post Office
Location
Full Name
Title
Employee #
Name
Post Office
Location
Suzan Fine
Suzan Fine
Suzan Fine
4
4
5

5
5
5
5
Suzan Fine
Name
Post Office
Location
Employee #
Suzan Fine
Name
Post Office
Location
Employee #
Suzan Fine
Suzan Fine
Suzan Fine
Forest2
Forest2
Forest2

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.
10 Module 8: Cross-Forest/Multi-Forest

To ensure that the entries that are joined together in the metaverse namespace
represent the same real-word object, you can configure MIIS to use a unique
attribute (such 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.
Module 8: Cross-Forest/Multi-Forest 11

The GAL Sync Management Agent


The pre-built GAL Sync Management Agent will allow Exchange
administrators to easily configure MIIS 2003 without having the need of an
MCS 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 Director
y
Metaverse Target Active Director
y


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 Director
y
Metaverse Tar
g
et Active Director
y


User Person User
Group Group Group

12 Module 8: Cross-Forest/Multi-Forest

Microsoft Metadirectory Services 2003 does not handle multi mastering of
these objects in any environment. All target attributes will typically be
overwritten by attributes 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
Module 8: Cross-Forest/Multi-Forest 13

join to an already joined metaverse object is not allowed and an error is
logged.
The following table lists and describes the joins between connector space
attributes that 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.”

14 Module 8: Cross-Forest/Multi-Forest



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



Module 8: Cross-Forest/Multi-Forest 15

16 Module 8: Cross-Forest/Multi-Forest




If either organization uses special address types (Notes/Gwise/custom), the
checkbox 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:

Module 8: Cross-Forest/Multi-Forest 17


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.
18 Module 8: Cross-Forest/Multi-Forest



Module 8: Cross-Forest/Multi-Forest 19





20 Module 8: Cross-Forest/Multi-Forest

After selecting the defaults and finishing the Management Agent Designer,
create another Management Agent, using the same previous 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
Module 8: Cross-Forest/Multi-Forest 21

Additionally, any master objects that disappear (get deleted) from the source
forest will eventually become de-provisioned and disappear from their target
forests as well. 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: ;
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=interna
l;
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:;
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:;
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.
22 Module 8: Cross-Forest/Multi-Forest

 From the msExchPoliciesExcluded, MIIS-generated contacts, by default,
have the following checkbox unchecked: “Automatically Update E-mail
Address based on recipient policy”.
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
Module 8: Cross-Forest/Multi-Forest 23

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.