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

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,

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

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

„ 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

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

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

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

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

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

z Source and/or destination for synchronized objects and attributes

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

z Central (SQL) store of identity information

z Matching CS entries to

a single MV entry is called “join”

Active Directory Oracle

IPlanet

SAP,JDEdwards, Peoplesoft, etc.

Connected Data Sources

Metaverse

User

Connector Space

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

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 1 Full Name Title

Employee #

Full Name Title Employee # Suzan Fine

Name Post Office Location Employee #

Name Post Office Location Employee #

Full Name Title Employee #

Suzan Fine

3

Full Name Title Employee #

Full Name Title

Employee #

Suzan Fine

Name Post Office Location Employee #

Name Post Office Location

Employee #

Sue Fine

Full Name Title Employee # Name Post Office Location

Full Name Title

Employee #

Name Post Office Location Suzan Fine

Suzan Fine

Name Post Office Location Employee #

Suzan Fine

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

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

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

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:

Contains at least one proxyAddress attribute value

The MSExchHideFromAddressList is not set to ‘true’

Contains a LegacyExchangeDN attribute value

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

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

„ 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

Active Directory

target address as the metaverse person object, then it represents the same entity and a join occurs

LegacyExchangeDN of a metaverse object matches a value in the proxyAddresses of contact, then it represents the same entity and a join occurs

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

source to the Microsoft Identity Integration Services 2003 connector space and metaverse

to the MIIS 2003 connector space and metaverse

connector space to the Active Directory data source

data flows from the MIIS 2003 connector space to the metaverse

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;

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=

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

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

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 approved mesh configurations may be supported

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

2 Open Active Directory Users and Computers

3 In the Users OU, create a mail-enabled contact

(someone@example.com) as well as a mailbox-enabled user account (localguy@forest1.gls)

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

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

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: 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 enabled users, contacts, and groups to distinguish forest membership and allow SMTP routing outside of the forest

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

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

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/2003Pure

Exchange 5.5 Use earlier version Use earlier version 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

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