Export (0) Print
Expand All
18 out of 21 rated this helpful - Rate this topic

Synchronizing Multiple Exchange 2003 Forests

 

Topic Last Modified: 2006-08-17

This topic provides information about synchronizing multiple Microsoft® Exchange Server forests. Before you perform the procedures listed in this topic, it is strongly recommended that first you read the guide Planning an Exchange Server 2003 Messaging System (http://go.microsoft.com/fwlink/?linkid=21766). The planning guide introduces you to the concepts behind running your Exchange organization in multiple forests. After familiarizing yourself with those concepts, read this section to learn how to synchronize your multiple Exchange organizations.

Specifically, this topic will:

  • Provide you with the requirements necessary to use the GAL Synchronization feature in Microsoft Identity Integration Server (MIIS) 2003.
  • Show you how to configure mail flow between your forests.
  • Show you how to configure extended mail features (such as a shared SMTP domain namespace).
  • Show you how to use the Inter-Organization Replication Tool to synchronize free and busy data and replicate public folders.
  • Show you how to administer the messaging system across forests (for example, how to use Migration Wizard to move mailboxes between forests).

The first two bullets listed are required for basic messaging functionality. The remaining bullets are extended mail features specific to a multiple forest scenario. Essentially, your goal is to make features that were initially designed to function only in a single forest span multiple forests.

Although a single forest topology is recommended because it provides the richest set of messaging features, there are various reasons for implementing multiple forests. Some of these reasons include:

  • You have multiple business units that require data and service isolation.
  • You have multiple business units that have separate schema requirements.
  • You are confronted with a merger, acquisition, or divestiture.

In the multiple forest scenario (Figure 1), a company has multiple Microsoft Active Directory® directory service forests, each containing an Exchange organization. In this scenario, user accounts are not separated from their mailboxes. Instead, a user account and its associated mailbox are in the same forest. However, because a GAL is specific to a single forest, users cannot see users, groups, or contacts in other forests.

2c4b3dc0-c1e1-40b8-941c-4ed604ef11ce

Most mail features were initially designed to function only in a single forest. Therefore, to ensure that these features are available across forests, you must overcome many design constraints. Some of the more advanced features, such as delegating mailbox access and viewing calendars, are not available if users are in different forests. Table 1 lists the available mail features in a multiple forest environment.

Table 1   Available features in a multiple forest environment

Feature Available across forests?

Basic mail flow

Yes. Trusts between forests are not required.

Common global address list (GAL)

Yes, with Microsoft Identity Integration Server (MIIS) 2003.

Free and busy data synchronization

Yes, with the Inter-Organization Replication Tool. In Microsoft Office Outlook®, a meeting organizer can add an attendee from another forest to a meeting request, and the organizer can check the attendee's availability on the Scheduling tab.

Public folder synchronization

Yes, with the Inter-Organization Replication Tool.

Meeting request forwarding

Yes, if you configured GAL Synchronization and set up SMTP authentication.

Distribution groups

Yes. A distribution group from another forest is represented as a contact. You can send mail to a distribution group in another forest (however, you cannot query the membership of the group).

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Yes, with manual configuration. By default, user certificates are not synchronized between forests. You must configure userCertificate to enable S/MIME. Key Management Service in Exchange 2000 and Exchange 5.5 are not supported in a multi-forest environment.

Delivery/read receipts

Yes, if Global Settings are configured correctly. (There are a few options for doing this; see "Configuring Mail Flow Between Forests" later in this topic.)

Shared SMTP namespace across forests

Yes, if each organization has a unique SMTP domain namespace in addition to the shared namespace. Add a recipient policy that specifies the unique SMTP proxy address to each forest. (If Exchange 5.5 is running in the forest, Active Directory Connector (ADC) replicates the second proxy address to the Exchange 5.5 directory as long as two-way connection agreements are set up.)

Public folder permissions

No. When you use the Inter-Organization Replication Tool to replicate a public folder, the administrator for each forest must set the permissions on the folders.

Rules

No. Rules will not function during a cross-forest mailbox move and need to be re-created after the move.

Mailbox delegation

No. Because a user or group from another forest is represented as a contact, you cannot delegate mailbox access to someone in another forest. Contacts cannot be designated in a mailbox's access rights. Also, mailbox delegate permissions are not preserved when you move mailboxes from one forest to another.

Calendar viewing

No. Although you can synchronize free and busy information across forests and use it to schedule meetings, you cannot use the Open Other User's Folder feature in Outlook to view the calendar details for a user in another forest.

Group membership viewing

No. Because a group from another forest is represented as a contact, you cannot view the group's members. Group membership is not expanded until the e-mail message is sent to the source forest.

Connectors to foreign messaging systems

Yes. If one forest is connected to a foreign messaging system, and you are using MIIS 2003, you can replicate the foreign messaging system contacts to other forests.

Send as

No. Users must be located in the same forest.

Front-end server to multiple forests

No. A front-end server cannot proxy requests to a back-end server in a different forest. This limitation applies whether you are using a front-end server for Outlook Web Access or Outlook Mobile Access.

Exchange 2000 Instant Messaging Service

Yes, but the forests cannot share the same namespace

By default, a global address list (GAL) contains mail recipients from a single forest. If you have a multiple forest environment, you can use the GAL Synchronization feature in Microsoft Integration Identity Server (MIIS) 2003 to ensure that the GAL in any given forest contains mail recipients from other forests. This feature creates mail-enabled contacts that represent recipients from other forests, thereby allowing users to view them in the GAL and send mail. For example, users in Forest A appear as contacts in Forest B and vice versa. Users in the target forest can then select the contact object that represents a recipient in another forest to send mail.

If each forest contains at least one Exchange 2003 server, you can use MIIS 2003 to synchronize forests that are running any combination of Exchange 5.5, Exchange 2000, and Exchange 2003. (GAL Synchronization does not work for pure Exchange 5.5 forests.) MIIS 2003 synchronizes the GALs, even if the source or target forest is in mixed mode and is running Active Directory Connector (ADC). In the source forest, ADC synchronizes Exchange 5.5 objects with Active Directory. MIIS 2003 then uses the objects in Active Directory to create the metadirectory objects that it synchronizes with other forests. In the target forest, ADC replicates the contacts into the Exchange 5.5 directory.

To enable GAL Synchronization, you create management agents that import mail-enabled users, contacts, and groups from designated Active Directory services into a centralized metadirectory. In the metadirectory, mail-enabled objects are represented as contacts. Groups are represented as contacts without any associated membership. The management agents then export these contacts to an organizational unit in the specified target forest.

The source forest is authoritative over the mail-enabled objects it supplies to MIIS 2003. If you make changes to the attributes of an object in a target forest, the changes do not propagate back to the source forest.

Consider the following when setting up GAL Synchronization:

  • Each management agent is designed to replicate between one forest and the MIIS 2003 metadirectory. Because of this, a single management agent cannot replicate end-to-end from one forest to another forest. Therefore, a separate management agent is required for each forest participating in the synchronization.
  • To ensure that management agents can export contacts to target forests, the server running MIIS 2003 must connect through LDAP (port 389) to a domain controller in each of the participating forests. Management agents must access domain controllers because of the rules set in MIIS 2003 Gal Synchronization.
  • When setting up a management agent, you must specify an account with the appropriate domain administrator permissions.
  • If one of the forests contains a connector to a foreign messaging system, by default, that forest is authoritative for the contacts; however, this setting can be changed.
  • Users cannot send encrypted mail from one forest to a distribution list in another forest. In cases where forests are connected by an SMTP connector and synchronized with GAL Synchronization, a distribution list is represented as a contact in the target forest, and its membership cannot be expanded.

The servers running MIIS 2003 and Exchange forests must be arranged in either a mesh or a hub–and-spoke configuration. A combination of the two configurations is also supported. However, you cannot connect the forests in a chain. Figures 2 and 3 illustrate the supported topologies.

importantImportant:
The MIIS2003 GAL Synchronization feature does not function in a resource forest model (in which user accounts exist in a separate forest from their mailboxes). Although you can configure MIIS to provision objects between a resource forest and an account forest, you cannot use the GAL Synchronization feature in MIIS2003 to do this. However, you can use GAL Synchronization to synchronize the resource forest and other Exchange forests.
a820a785-ca35-47de-92ac-f529e8afd217

In a hub-and-spoke topology (Figure 2), a single server runs MIIS 2003 and reads all of the data about all of the forests, evaluates changes and conflicts, and propagates the changes to each forest. This topology recommended because it is centrally administered and is the easiest topology to deploy.

importantImportant:
The accounts configured for the server running MIIS2003 must be able to write to all forests. For some organizations, this may pose a security issue.
c66f2005-072b-4f2d-83f1-7e54d080916c

In a mesh topology, each forest contains a server running MIIS 2003. Each forest is responsible for setting up the connections from their server running MIIS 2003 to every other forest. This topology is complex and is not recommended without thorough pilot testing. The main reason for selecting this topology is that other forests do not have to allow write access to their directories. However, read access is still required; the management agents are configured to read directory information from all of the other forests.

For complete information about how to install and configure the GAL Synchronization feature in MIIS 2003, see the following resources:

After setting up GAL synchronization, you must ensure that mail flows properly between organizations and the Internet. For basic mail flow, the only requirement is that a route can be resolved to each adjoining forest. Trusts between the forests are not required.

Mail flow is determined by the network connectivity between forests and the way in which SMTP proxy addresses are configured. The ideal configuration is to have direct network connectivity between the forests with no firewalls. (If there are firewalls between the forests, you must open the appropriate ports.)

noteNote:
No link state information or routing topology information is shared between forests.

You must also set up SMTP connectors between the forests. Furthermore, it is recommended that you enable authentication across the forests. Enabling authentication has the following benefits:

  • User name resolution (the ResolveP2 registry key) between forests is automatic, which means that a user's e-mail address resolves to the user's name that is stored in Active Directory.
  • Additional calendaring features and mail features, such as mail forwarding, are available.

To prevent the forging of identities (spoofing), Exchange 2003 requires authentication to resolve a sender's name to its display name in the GAL. Therefore, in a multiple forest environment, it is recommended that you configure authentication so that users who send mail from one forest to another are resolved to their display names in the GAL, rather than to their SMTP addresses.

To enable cross-forest mail collaboration in Exchange 2003, additional configuration steps are required to resolve contacts outside your organization to their display names in Active Directory. You have two options to enable the resolution of these contacts:

  • Option 1 (recommended)   Use authentication so that users who send mail from one forest to another are authenticated, and their names are resolved to their display names in the GAL.
  • Option 2   Restrict access to the SMTP virtual server that is used for cross-forest collaboration, and then configure Exchange to resolve anonymous e-mail. This configuration is supported, but not recommended. By default, in this configuration, the Exch50 message properties, which are the extended properties of a message, are not persisted when mail is sent from one forest to another.

To understand the benefits of configuring cross-forest mail collaboration, consider the following scenarios of anonymous mail submission and cross-forest authenticated mail submission.

E-mail addresses are not resolved if the submission is anonymous. Therefore, when an anonymous user who attempts to spoof (forge) an internal user's identity sends mail, the return address does not resolve to its display name in the global address list (GAL).

Example:

Kim Akers is a legitimate internal user at Northwind Traders. Her display name in the GAL is Kim Akers, and her e-mail address is kim@northwindtraders.com.

To send mail, Kim must be authenticated. Because she is authenticated, the intended recipients of Kim's mail see that the sender is Kim Akers. In addition, the properties of Kim Akers are displayed as her GAL entry. However, if Ted Bremer attempts to forge Kim's address by using kim@northwindtraders.com in the From line and then sending the mail to the Exchange 2003 server at Northwind Traders, the e-mail address is not resolved to Kim's display name because Ted did not authenticate. Therefore, when this e-mail message displays in Outlook, the sender address appears as kim@northwindtraders.com; it does not resolve to Kim Akers, as authenticated mail from Kim does.

Consider a company that spans two forests: the Adatum forest and the Fabrikam forest. Both these forests are single-domains forests with domains of adatum.com and fabrikam.com respectively. To allow cross-forest mail collaboration, all users in the Adatum forest are represented as contacts in the Fabrikam forest's Active Directory. Likewise, all users in the Fabrikam forest are represented as contacts in Adatum forest's Active Directory.

If a user in the Adatum forest sends mail to Fabrikam forest, and the mail is submitted over an anonymous connection, the sender's address is not resolved, despite the fact the sender exists as a contact in the Active Directory and in the Outlook GAL. This is because a user in the Adatum forest is not an authenticated user in Fabrikam forest.

Example:

Kim Akers is a mail user in the Adatum forest—her e-mail address is kim@adatum.com, and her Outlook GAL display name is Kim Akers. Adam Barr is a user in the Fabrikam forest—his e-mail address is adam@fabrikam.com, and his Outlook GAL display name is Adam Barr. Because Adam is represented as an Active Directory contact in the Adatum forest, Kim can view Adam's e-mail address and resolve it to the display name of Adam Barr in the Outlook GAL. When Adam receives mail from Kim, Kim's address is not resolved; instead of seeing Kim's display name as it appears in the GAL, Adam sees her unresolved e-mail address of kim@adatum.com. Because Kim sent mail as an anonymous user, her e-mail address did not resolve. Although Kim is authenticated when sending mail, the connection between the two forests is not authenticated.

To ensure that senders in one forest can send mail to recipients in other forests, and to ensure that their e-mail addresses resolve to their display names in the GAL, you should enable cross-forest mail collaboration. The following sections explain the two options available for configuring mail collaboration between two forests.

To enable cross-forest SMTP authentication, you must create connectors in each forest that uses an authenticated account from the other forest. By doing this, any mail that is sent between the two forests by an authenticated user resolves to the appropriate display name in the GAL. This section explains how to enable cross-forest authentication.

Using the example of the Adatum forest and the Fabrikam forest (see the "Cross-Forest Mail Delivery" scenario in the previous section), perform the following steps to set up cross-forest authentication:

  1. Create an account in the Fabrikam forest that has Send As permissions. (For all users in the Adatum forest, a contact exists in the Fabrikam forest as well; therefore this account allows Adatum users to send authenticated mail.) Configure these permissions on all Exchange servers that will accept incoming mail from Adatum.
  2. On an Exchange server in the Adatum forest, create a connector that requires authentication using this account to send outbound mail.

Similarly, to set up cross-forest authentication from the Fabrikam forest to Adatum forest, repeat these steps, creating the account in Adatum and the connector in Fabrikam.

Before you set up your connector in the connecting forest, you must create an account in the destination forest (the forest to which you are connecting) that has Send As permissions. Configure these permissions on all servers in the destination forest that will accept inbound connections from the connecting forest.

For detailed steps, see How to Create a User Account in Another Forest with Send As Permissions.

After creating the account with the proper permissions in the destination forest, create a connector in the connecting forest and require authentication using the account you just created.

For detailed steps, see How to Create a Connector and Require Authentication for Cross-Forest Authentication.

Another way you can configure Exchange to resolve contacts outside your organization to their display names in Active Directory is to configure Exchange to resolve anonymous e-mail. Assume that your company spans two forests, from the Adatum forest to the Fabrikam forest.

importantImportant:
Configuring Exchange servers to resolve anonymous mail submissions allows unscrupulous users to submit messages with a falsified return address. Recipients are not able to differentiate between authentic mail and spoofed mail. To minimize this possibility, ensure that you restrict access to the SMTP virtual server to the IP addresses of your Exchange servers.

Perform the following steps to resolve contacts for Adatum users to their display names in the Fabrikam forest:

  1. Create a connector in the Adatum forest that connects to the Fabrikam forest. For detailed steps, see How to Create a Connector and Require Authentication for Cross-Forest Authentication.
  2. On the receiving bridgehead server in the Fabrikam forest, restrict access to the SMTP virtual server by IP address. By doing this, you can ensure that only servers from the Adatum forest can send mail to this server. For detailed steps, see How to Restrict Access by IP Address on a Receiving Bridgehead Server.
  3. On the SMTP virtual server that hosts the connector, enable the Resolve anonymous e-mail setting. For detailed steps, see How to Configure an SMTP Virtual Server to Resolve Anonymous Email Addresses.
  4. Change a registry key to ensure that the extended message properties (Exch50 properties) are persisted across the forests. Otherwise, you can lose important message information. For detailed steps about how to enable an Exchange Server to accept extended message properties sent anonymously, see How to Enable an Exchange Server to Accept Extended Message Properties Sent Anonymously. For detailed steps about how to enable an SMTP virtual server to accept extended message properties anonymously, see How to Enable an SMTP Virtual Server to Accept Extended Message Properties Sent Anonymously.

After you complete these steps, all users who send mail from the Adatum forest to the Fabrikam forest will resolve to their display names in the Fabrikam GAL. Next, you need to repeat steps 1 through 3 for the Fabrikam forest.

As explained earlier, when messages are sent anonymously across forests, the extended message properties on a message are not transmitted. For single companies that implement a cross-forest scenario, these message properties must be transmitted because information about the message can be lost. For example, the SCL property, an extended Exchange property, contains an unsolicited commercial e-mail (spam) rating that is generated by third-party solutions. This property is not transmitted when mail is sent anonymously. So, if a third-party anti-spam solution is deployed in the Adatum forest, and a message received in this forest is destined to a recipient in the Fabrikam forest, the third party solution stamps the SCL property on the message; however, when the message is delivered to the Fabrikam forest, the extended property containing the spam rating is not persisted.

If your Exchange server functions solely as the bridgehead server for cross-forest communication, you may want to configure this setting at the server level.

For detailed steps, see How to Enable an Exchange Server to Accept Extended Message Properties Sent Anonymously.

If you have other SMTP virtual servers on this Exchange server, consider setting this registry key on the SMTP virtual server only. For detailed steps, see How to Enable an SMTP Virtual Server to Accept Extended Message Properties Sent Anonymously.

noteNote:
If you enable this registry key on an Exchange server, the setting applies to all SMTP virtual servers on the Exchange server. If you want to configure a single SMTP virtual server with this setting, enable the registry key on the SMTP virtual server.

Most companies have Internet connectivity and one or more published domain names. If each Exchange organization maintains a separate namespace, contacts that are synchronized between organizations need only one SMTP address for proper routing. However, you may have several Exchange organizations but only a single namespace that represents your company on the Internet (for example, contoso.com). In this case, to retain individual forest namespaces but still route mail properly to the individual forests, you must distinguish the forests from one another.

In addition, to enable or disable mail features such as out-of-office responses, automatic replies, and delivery reports, you may have to configure global settings.

When GAL Synchronization creates contacts from mail recipients in a source forest, it uses SMTP addresses to create a TargetAddress property for each contact. Therefore, when users in a forest send mail to a contact, the mail is delivered to the contact's TargetAddress property, even if the user manually entered the primary reply address. To determine which TargetAddress GAL Synchronization should assign to a contact, it compares the recipient's ProxyAddresses property to the SMTP address for which the Exchange organization is responsible. Each organization must have a unique SMTP domain namespace so that contacts receive a unique TargetAddress. If your forests do not have unique namespaces, you can add a unique SMTP address to the appropriate recipient policies for each Exchange organization that contains users to be replicated across forests. After you do this, messages sent to a contact are routed directly to the source forest, where the target address resolves to the actual mailbox and the message is delivered.

You can also route contacts on a forest-by-forest basis. When setting up management agents for GAL synchronization, you can select whether mail sent to contacts that have been imported into a forest should route back through the source forest. If you have a connector to a foreign messaging system, by default, mail that is intended for a contact is routed to the source forest (the forest that manages the connector); however, the forest administrator can change this routing configuration.

noteNote:
If Exchange 5.5 is running in the forest, ADC replicates the second proxy address to the Exchange 5.5 directory, provided that two-way connection agreements are set up.

As an example of SMTP routing in a multiple forest environment, consider two forests that each have a default recipient policy with an SMTP proxy address of contoso.com. To set up unique namespaces, you would do the following in each Exchange organization:

  • In Organization 1, add an SMTP proxy address of Org1.contoso.com to the default recipient policy.
  • In Organization 2, add an SMTP proxy address of Org2.contoso.com to the default recipient policy.

In both cases, when adding the proxy address, you would select the This organization is responsible for all mail delivery to this address check box. Also, you would leave the contoso.com proxy as the primary address so that, when a user sends mail, their reply address is user@contoso.com (rather than user@Org1.contoso.com or user@Org2.contoso.com).

Another example illustrates mail flow in a hub-and-spoke topology. In this example, multiple Exchange organizations are present, but all users can be addressed in a single domain space (for example, @example.com). In this case, all external mail addressed to @example.com flows into a central hub organization called OrgA. OrgA is configured with secondary SMTP proxy addresses that represent each spoke organization. One of these addresses is @OrgB.example.com. When mail addressed to UserB@example.com arrives at OrgA, the mail resolves to the contact, and the mail is redirected to OrgB. When the message leaves OrgA, the To line is changed to the TargetAddress property to allow for routing, but the Reply To address remains UserB@example.com.

For the following reasons, moving recipients from one organization to another does not prevent users from replying to old e-mail messages:

  • The message retains the legacyExchangeDN property so that recipients can reply to the mail.
  • GAL Synchronization creates a secondary X.500 proxy address for the user who was moved so that old messages can be properly routed to the user's new mailbox based on the legacyExchangeDN property.

For example, UserA sends mail to UserB, who is in the same organization. Later, UserA is moved to a different organization. The mail originally sent by UserA still specifies UserA's legacyExchangeDN property. GAL Synchronization creates a contact for UserA in the old organization and assigns an X.500 address with the old legacyExchangeDN property. This allows UserB to reply to the old mail, which, in turn, is properly routed to the TargetAddress property for UserA. If a mailbox is moved many times, the list of secondary proxy addresses can potentially grow large.

If you want to use an SMTP relay server to route all mail from the Internet to the correct forest, it is recommended that you set up an SMTP relay server. On the SMTP relay server, create SMTP connectors to all of the other forests so that mail routes directly to each forest. This configuration allows you to add SMTP servers as needed for load balancing. You can also add SMTP connectors to route all outbound Internet mail through the new forest. For more information about how to set up SMTP relay servers and SMTP connectors, see "Configuring SMTP" in the Exchange Server 2003 Administration Guide (http://go.microsoft.com/fwlink/?linkid=21769).

In Exchange 2003, if your Active Directory objects are mailbox-enabled or mail-enabled, the Recipient Update Service automatically maintains server-based address lists (such as the GAL). Specifically, the Recipient Update Service assigns default e-mail addresses to all mailbox-enabled or mail-enabled recipient objects, such as user accounts, groups, and contacts. A recipient policy determines the format of generated e-mail addresses.

If you want to preserve existing recipient information, you must adjust the default recipient policy or create a new policy with a higher priority that applies to all relevant objects and assigns default e-mail addresses that correspond to those in the previous messaging system. Use Exchange System Manager to adjust the settings in the default recipient policy. (Expand Recipients and then click Recipient Policies. Default Policy is listed in the details pane.)

To adjust default recipient policy settings, use the E-Mail Addresses (Policy) tab in Default Policy Properties. On this tab, you can change the various address generation rules (for example, generation rules for SMTP addresses). Specifically, you can use placeholders in your e-mail address generation rules. For example, if you want to change from the default address format of <User Logon Name>@<Domain Name> to an address format of <First Name>.<Last Name>@<Domain Name> (for example, Frank.Miller@contoso.com), you must use placeholders for the first and last names. In this example, you would perform the following steps:

  1. On the E-Mail Addresses tab, under Generation rules, select SMTP, and then click Edit.
  2. In SMTP Address Properties, in the Address box, type %g.%s as the beginning of the address definition; (for example, %g.%s@contoso.com). In addition, you can specify how many characters to use (for example, %g%1s@contoso.com results in FrankM@contoso.com). Table 2 lists the address generation rules placeholders.

    Table 2   Placeholders in address generation rules

    Placeholder Description

    %d

    Display name

    %g

    Given name

    %i

    Initials

    %m

    Alias

    %s

    Surname

Because free and busy data is stored in a public folder, you must use the Inter-Organization Replication Tool to replicate free and busy data between forests.

noteNote:
To use the Inter-Organization Replication Tool to replicate free and busy data, the servers must be configured to use the same language.

You can also use the Inter-Organization Replication Tool to replicate all or a portion of public folder content between forests. Specifically, you can use the tool to:

  • Specify individual folders or a group of folders and subfolders, allowing for considerable flexibility.
  • Replicate public folders from publisher to subscriber or bi-directionally.
  • Configure the replication frequency.
  • Configure the logging of message and folder replication.
  • Configure the amount of processing power you want devoted to the replication process.

You can download the Inter-Organization Replication Tool from the Downloads for Exchange 2003 Web site (http://go.microsoft.com/fwlink/?linkid=25097).

To migrate accounts and mailboxes from one Exchange 2000 or Exchange 2003 forest to a separate Exchange 2000 or Exchange 2003 forest, it is recommended that you first use the Active Directory Migration Tool (ADMT), followed by the Exchange Migration Wizard.

First, run ADMT to create active user accounts in Active Directory. It is recommended that you select the option for migrating security identifiers (SIDs) so that ADMT adds the source account's SID to the new target account's SID history attribute. (Migration Wizard uses the SID to match mailboxes to accounts in the next step.)

noteNote:
To migrate SIDs, the target Microsoft Windows® domain must be in native mode.

It is also recommended that you do not disable the user account in the source forest when you run ADMT. Exchange 2003 does not support disabled mailbox accounts without associated external account.

After you migrate the accounts, use Migration Wizard to migrate mailboxes. If you migrated SIDs when you ran ADMT, Migration Wizard uses the SIDs to match mailboxes to the new accounts and converts the accounts to mailbox-enabled user accounts. If you did not migrate the SIDs in the first step, Migration Wizard cannot match a mailbox to an account; instead, the wizard creates a disabled user account to associate with the mailbox.

There may be cases where you have to migrate mailboxes before you migrate accounts. In these cases, Migration Wizard creates disabled user accounts to hold mailboxes and associates new mailboxes with external Microsoft Windows NT® accounts. Later, when you use ADMT to migrate Windows NT accounts, new accounts are created in Active Directory. As a result, Active Directory contains two objects that relate to the same user. To merge these duplicate objects, use the Active Directory Account Cleanup Wizard (Adclean.exe). Adclean.exe is installed with Exchange—you can access it from Exchange System Manager (click Start, point to Programs, point to Microsoft Exchange, point to Deployment, and then click Active Directory Account Cleanup Wizard).

You can download the Active Directory Migration Tool (ADMT), version 2.0 from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=22161).

For more information about ADMT, see the following resources:

  • Windows 2000 Help
  • Microsoft Windows Server™ 2003 Help

After running ADMT to migrate the user accounts, you can use Exchange Migration Wizard to migrate the mailboxes. For detailed steps about how to use the Exchange Migration Wizard, see How to Run the Exchange Server Migration Wizard.

The remainder of this section provides you with the following information about using Exchange Migration Wizard:

  • The tasks that are performed when you create new user accounts
  • How to select the accounts you want to migrate
  • The permissions necessary to run Migration Wizard
  • What data can and cannot be migrated by Migration Wizard
  • How to run Migration Wizard in default mode
  • How to run Migration Wizard in clone mode
  • How to use the Exchange Profile Update tool (Exprofre.exe)
  • How to run Migration Wizard as a batch process
  • Migration Wizard Log file

If you use Migration Wizard to create new user accounts, Migration Wizard performs the following tasks:

  • If matching user objects do not currently exist in Active Directory, user objects are created.
  • If the messaging system directory you are migrating contains information that is not already present in Active Directory, that information is migrated to Active Directory. However, Migration Wizard does not overwrite existing Active Directory information. Only blank fields or multi-value fields are populated.
  • If a user object does not have a mailbox, a mailbox is created.
  • If matching contact objects exist, Migration Wizard deletes the contact object.

To select the accounts you want to migrate, use the Account Migration page of the Migration Wizard.

Furthermore, you can use the Windows Account Creation and Association page to view any matching accounts. If necessary, on this page, you can use the following options to change the account information:

  • To undo a matching account that appears in the Existing Windows Account column and then create a new user account, use the Create New Account page.
  • To edit the Full Name and Login ID for a new Windows account, double-click the account to open Mail Account Properties, and then edit the account information.
noteNote:
To undo a hard match (that is, e-mail addresses that match) return to the Account Migration page and clear the user. Then, before you begin the migration process, edit the user's e-mail address in the migrating messaging system or edit the e-mail address of the Active Directory user object so that the addresses no longer match.

Table 3 lists the permissions necessary to run Migration Wizard

Table 3   Source and target forest permissions for running Migration Wizard

Forest Required permissions or roles

Target forest administrator

  • Exchange Full Administrator role applied at the organization level
  • Domain Administrator
  • Local Machine Administrator

Source forest administrator

  • Exchange Full Administrator role applied at the organization level

Table 4 lists the data that you can migrate from one Exchange 200 or Exchange 2003 forest to a separate forest. Table 5 lists the data that you cannot migrate.

Table 4   Data that can be migrated from Exchange 2000 or Exchange 2003

Data Notes

Directory information

Migration Wizard copies the user information from your source directory, searches Active Directory to find matches, and adds the information to the matching object or creates a new object based on the migrated information.

Mailbox content

Migration Wizard migrates the messages and information in the Calendar, Contacts, Deleted Items, Drafts, Inbox, Journal, Notes, Sent Items, Tasks, and custom folders.

Server side rules

Migration Wizard migrates any server side rules the user has configured.

Out-of-office messages

When run in clone mode, Migration Wizard migrates out-of-office messages for each mailbox.

Offline folder files

When run in clone mode, Migration Wizard retains the user's offline folder files (.ost).

Offline address books

After migrating your user's mailbox their offline address must be updated. For more refer to the Exchange Profile Update tool section in this topic.

Table 5   Data that cannot be migrated from Exchange 2000 or Exchange 2003

Data Notes

Public folders

Migration Wizard does not migrate either public folder content or the public folder hierarchy. This includes messages and other items (such as forms) stored in public folders.

Public folder permissions

Migration Wizard does not maintain public folder properties or permissions for migrated mailboxes. After migration, migrated mailboxes must have their public folder permissions updated in the destination site by the administrator.

Signature validation

Migration Wizard does not maintain signature validation. Users with advanced security might not be able to validate the signatures on messages that were sent before migration.

Encrypted messages

Existing encryption keys will not be available after migration. To avoid the risk of losing access to messages if their keys are lost, users should decrypt encrypted messages before migration.

If possible, before you run Migration Wizard, you should reduce the amount of data to be migrated. You can reduce both directory information and mail data. You can do this by:

  • Instructing users to delete old mail and calendar data.
  • Instructing users to delete old contact data.
  • Deleting old mailboxes from your Exchange server.
  • Advising users not to log on to the mailbox during the migration process.

Furthermore, during the migration process, you can also use Migration Wizard to reduce the amount of data that you migrate. On the Account Migration page, ensure that only the user accounts you want to migrate are selected. Then, on the Migration Information page, use the following options to specify what data should be migrated:

noteNote:
If you run Migration Wizard in clone mode, you cannot filter data by date range or by a specific subject.
  • To migrate messages within a date range, select the Migrate Mail messages within a date range check box. Then, to specify a date range, type a start date in the Date Range box and an end date in the To box.
  • To avoid migrating mail messages with specific subjects, such as a list of words or letters, select the Do not migrate mail messages with specific subjects check box. Then, next to Subject List File, click Browse to locate the file that contains the subjects you want to filter.
    noteNote:
    The files in Subject List File must be saved in Unicode file format.

There are certain features that are available only when you run Migration Wizard in a specific mode. Table 6 lists the Migration Wizard modes and explains which features are available in each mode.

Table 6   Migration Wizard default mode and batch mode features

Mode Features

Default mode

  • Clone Mode
  • Target address
  • Migration Wizard logging

Batch (command line) mode

  • Clone Mode
  • Target address
  • Migration Wizard logging
  • Ability to run multiple instances of Migration Wizard
  • Password mode

In default mode, Migration Wizard performs a mail merge of the messages in your mailboxes. If an existing mailbox exists, the mailbox data is not duplicated. Before copying a message, Migration Wizard checks the last modification date of the message; if the target copy is newer than the source copy, the wizard does not copy the message. This is useful for incremental mailbox copies or failed migrations. For example, if your last migration failed before completion, Migration Wizard now skips the existing messages that were copied successfully. You can also use Migration Wizard to import the messages that were delivered to the source mailbox during or after the last migration.

When using Migration Wizard in default mode, consider the following limitations associated with moving mailboxes across forests:

  • If you run Migration Wizard in default mode, your users lose their .ost files after you migrate mailboxes. As a result, your users must synchronize their .ost files again.
  • If the target message was previously copied by other tools, Migration Wizard may not function unless those tools preserve the PR_SEARCH_KEY
  • The Migration Wizard log file does not output the counters for skipped and replaced messages.
  • Delegate permissions are not preserved during a cross-forest move.
  • Published certificates are not migrated during the move. In addition, you cannot recover Key Management Service certificates after a move. To be recovered, the certificates require a domain name.
  • Client-side rules are not preserved during a cross-forest move.

Running Migration Wizard in clone mode allows you to preserve your user's data, Inbox rules, and user ID's in their mailbox.

Also, if you are using Cached Exchange Mode, use Migration Wizard in clone mode to migrate your user mailboxes (to preserve your user's .ost files), and then use the Exchange Profile Update tool (Exprofre.exe) to update your user's Outlook profiles. For more information about Exprofre.exe, see, "Exchange Profile Update Tool" later in this topic.

The following are limitations associated with moving mailboxes across forests. Plan for these situations, and notify users of the steps they must perform before and after the move:

  • If you are using Cached Exchange Mode, it is recommended that you use the Exchange Profile Update tool after migrating your mailbox to preserve your user's .ost files.
  • For Migration Wizard to run in clone mode, a user target mailbox cannot exist in the destination organization. If a user target mailbox does exist, and the user has logged on to the mailbox, Migration Wizard switches to default mode.
  • Migration Wizard does not support filtering by date and subject.
  • The Migration Wizard log file does not output the counters for skipped and replaced messages.
  • Delegate permissions are not preserved during a cross-forest move.
  • Published certificates are not migrated during the move. In addition, you cannot recover Key Management Service certificates after a move. To be recovered, the certificates require a domain name.
  • Client-side rules are not preserved during a cross-forest move.

One of the new features in Outlook 2003 is Cached Exchange Mode. In Cached Exchange Mode, Outlook 2003 uses an offline folder store file (.ost), which is usually stored on the user's workstation. If you run Migration Wizard in default mode, your users lose their .ost files. As a result, users must synchronize their .ost files again. Depending on your network speed, hardware configuration, number of users, and other factors, re-synchronizing .ost files can be time consuming and performance intensive. You can preserve the user's .ost file by running Migration Wizard in clone mode. You can then use the Exchange Profile Update tool (Exprofre.exe) to update your user's Outlook profiles.

noteNote:
To run Migration Wizard in clone mode, at the command prompt, type D:\Program Files\Exchsrvr\bin\mailmig.exe /m (where D:\Program Files is the drive on which Exchange 2003 is installed). For more information about how to run Migration Wizard, see "Running Exchange Migration Wizard" earlier in this topic.

For more information about Cached Exchange Mode, see Configuring Exchange 2003 for Client Access.

During the migration, if the mailbox is instantiated or initialized by incoming mail, clone mode is cancelled. Specifically, the target address prevents the migrating mailboxes from instantiating or initializing. Migration Wizard moves mailboxes in two stages: First the wizard creates the users and mailboxes, and then it initializes the mailboxes and clones the mailbox data. If the mailbox receives mail before Migration Wizard initializes it, the mailbox is initialized, clone mode is cancelled, and Migration Wizard switches to default mode.

To prevent this, you can run Migration Wizard in batch (command-line) mode with the target address command. The target address command takes the address of the source mailbox and stamps it with a temporary proxy address. This causes any incoming mail to be delivered to the source mailbox. You can then run Migration Wizard again, in default mode, to recover the mail data from the source mailbox. After the migration is complete, Migration Wizard clears this temporary proxy address.

noteNote:
Using the target address match feature in Migration Wizard is available only when running Migration Wizard in batch mode. For more information about using the target address in command-line and batch file migrations, see Batch File and Command Line Migrations for Exchange Server 2003.

If you cancel Migration Wizard before completion with the intent of running the operation again, the directory will still contain some or all of the user objects and mailboxes. Therefore, because some or all of the user objects and mailboxes already exist, Migration Wizard run in default mode (instead of clone mode) the next time you start it. To avoid this situation, after you cancel Migration Wizard, manually remove the user objects from the directory and the mailboxes from the mailbox store before running the wizard again.

The Exchange Profile Update tool (Exprofre.exe) is a stand-alone executable file that automatically updates users' Outlook profiles, allowing users to log onto their relocated mailboxes after the mailboxes have been moved across Exchange organizations or administrative groups. To update the default Outlook profile to reflect the new information, you must run Exprofre.exe on each client computer. It is recommended that you use a logon script to run this tool.

Download the Exchange Profile Update tool from the Downloads for Exchange 2003 Web site (http://go.microsoft.com/fwlink/?linkid=25097).

The Exchange Profile Update tool is supported when used in conjunction with the following operating systems and applications:

  • Microsoft Windows® 2000 (all editions)
  • Microsoft Windows XP (all editions)
  • Windows Server 2003 (all editions)
  • Outlook 2003 and all earlier versions of Outlook
noteNote:
Exprofre.exe does not run if Outlook or another MAPI application is running on a client computer. A warning appears stating that Outlook must be closed to run the tool.

Exprofre.exe uses information from Active Directory and the current default Outlook profiles to perform the following steps:

  • Back up the default profile
  • Look for an X.500 e-mail address indicating that the mailbox has been moved
  • Update the default profile with the new user and server properties
  • Reconfigure the default profile with the new RPC over HTTP front-end server name (optional)
  • Clear the user's nickname file (optional)
  • If the version of Outlook is earlier than Outlook 2003, delete or rename the offline folder store (.ost) file
  • Delete or rename the Favorites (.fav or .xml) file
noteNote:
Exprofre.exe updates only the default profile. Exprofre.exe does not create new profiles; it only modifies existing profiles.

If the tool does not complete successfully, Exprofre.exe creates a backup profile before it modifies the default profile. The backup profile name consists of the old profile name with "backup" added to the end. For example, if the default profile name is "Ted Bremer," the backup profile name is "Ted Bremer backup." If it is necessary to revert to the backup profile, you must ensure that any file name extensions that have been changed are changed back to their original extension and, if necessary, that the file name matches the backup profile name. For example, when the tool creates the backup profile, it renames Ted Bremer's Favorites file to "Ted Bremer.exprofre." To revert to Ted Bremer's backup profile, you must change the extension of the Favorites file back to .fav and the name of the file to "Ted Bremer backup.fav" to match the backup profile name.

Run Exprofre.exe after you move mailboxes from one Exchange organization to another or from one administrative group to another. You can use a logon script or group policy to run the tool for Outlook users.

noteNote:
It is recommended that you use a logon script to run Exprofre.exe so that users' Outlook profiles are updated when they first log on after the mailbox move. For sample commands, see "Sample Command for Moves Across Exchange Organizations" and "Sample Command for Moves Across Administrative Groups" later in this topic.

Table 7 describes the options that are available whether you run exprofre.exe from a command prompt or from within a script, such as from the following script example:

exprofre.exe [/?] [/targetgc=<global catalog server>] [/logfile=<path\filename>] [/v] [/f] [/a] [/r] [/o] [/p=<RPC over HTTP Proxy server>] [/n] [/s] [/q]

Table 7   Exprofre.exe command options

Command option Description

/?

Displays Help.

/targetgc

Specifies the target global catalog server (required).

/logfile

Specifies the path and file name for the log file. The default is exprofre.log in the tmp directory, which is saved on the client computer. You can also redirect the log file to a server share by using the format /logfile=<path\filename>.

/v

Turns on verbose output.

/f

Keeps the favorites file (.fav or .xml). If this option is not specified, the tool renames the extension of the favorites file to .exprofre.

/a

Keeps the offline address book (.oab) files. If this option is not specified, the tool deletes the .oab files and resets Outlook to check the server for an updated set of .oab files.

/r

Specifies read-only mode.

/o

Deletes rather than renames the offline folder store file (.ost). If this option is not specified, the tool renames the extension of the .ost file to .exprofre. (This option is not required for Outlook 2003 or later. The .ost file for Outlook 2003 or later is always unchanged.)

/p

Specifies the front-end proxy server if you are using Outlook 2003 with RPC/HTTP turned on.

/n

Clears the Outlook nickname file (.nk2 or .nick). If this option is not specified, the tool keeps the nickname file.

/s

Updates profiles based on a change in server name rather than a change in the legacyExchangeDN attribute.

If you are moving mailboxes across Exchange organizations (cross-forest moves), it is recommended that you use only the /v and /n command options. All other options should be omitted to enable the tool to use its default settings. Because the user is moving to a new forest, most of the Outlook information stored on the user's workstation will be obsolete and must be updated with information about the new forest. By default, the tool deletes most of this obsolete information.

The following is a sample command for a mailbox move across Exchange organizations:

Exprofre.exe /targetgc=<target global catalog server> /v /n /f

After your Exchange migration is complete, review your installation log located on your Exchange computer (for more information, see Batch File and Command Line Migrations for Exchange Server 2003). The Migration Wizard log contains information about your migration and is used to provide status about your Exchange migrations.

In the event of a migration failure, you can use the log to determine which mailboxes moved successfully and which mailboxes failed to move. Also, after a migration, you can view the status of accounts that were successfully migrated, partially migrated, or that were updated in Active Directory without the content being moved.

noteNote:
After you perform the migration, The Migration Wizard log provides information that helps you take action on only mailboxes that failed to migrate.

The following information is logged during your Exchange migration:

  • The list of accounts and mailboxes that will be moved.
  • An event is logged each time an account is updated in Active Directory.
  • An event is logged when an account migration begins.
  • An event is logged when an account migration succeeds or fails.
noteNote:
For MAPI-based migrations from Exchange 5.5 or Exchange 2000 to Exchange 2003, logging is available only in the SP1 version of Migration Wizard.

The following information is not logged during your Exchange migrations:

  • Mailboxes not migrated due to a termination of the migration process (either manually or because of a fatal error)
  • Migrations from non-Exchange sources

The following is an example of a Migration Wizard log file.

******************************************************

Microsoft Exchange Migration Wizard, v(version number)

Start Logging: [Time]

******************************************************

[Time] Mailboxes to be migrated from server <name server>

Ted Bremer

Kim Akers

Birgit Seidl

Pilar Ackerman

.

.

.

[Linefeed]

[Time] Updating Active Directory

[Time] Updated mailbox information for Ted Bremer in Active Directory on {DCNAME}

[Time] Failed to update mailbox information for Kim Akers in Active Directory on {DCNAME}. Mailbox will not be migrated.

[Time] Found existing mailbox information for Birgit Seidl in Active Directory on {DCNAME} for Birgit Seidl, no update needed

.

.

.

[Linefeed]

[Time] Migrating Mailboxes

[Time] Started migrating mailbox Ted Bremer to server <name server>

[Time] Completed migrating mailbox for Ted Bremer

[Time] Started migrating mailbox Birgit Seidl to server <name server>

[Time] Completed migrating mailbox for Birgit Seidl

[Time] Started migrating mailbox for Pilar Ackerman to server <name server>

[Time] Failed to migrate mailbox for Pilar Ackerman

.

.

.

[linefeed]

[Time] Exchange Migration Wizard completed

[linefeed]

noteNote:
   The time-stamp on the log file is the current date/time format, based on the current local settings of the computer running the Migration Wizard.

Using a control file and a combination of switches, you can configure Migration Wizard (Mailmig.exe), to run as a batch process. For information about specific Migration Wizard command-line reference, control file parameters, and sample control files, see Batch File and Command Line Migrations for Exchange Server 2003.

 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.