立即与支持人员聊天
与支持团队交流

Migrator for Notes to Exchange 4.16.3 - Scenarios Guide

About the Migrator for Notes to Exchange documentation Scenarios overview Migration to a proprietary Exchange
Migration to a proprietary Exchange target Pre-migration preparations Batch migration process Post-migration activities
Migration to Microsoft 365
Pre-migration preparations Batch migration process Post-migration activities
SSDM (per-desktop) migration

Step 9: Review and modify exported data

The data captured by the Directory Export Wizard provides critical input to other Migrator for Notes to Exchange programs, so it is important to verify that the information is accurate and properly formatted. This verification step also provides an opportunity to update addresses and other attributes as necessary before initiating migrations. For example, the content may be modified to facilitate the organization's consolidation to a new SMTP domain as part of the migration process.

If you will provision the hosted AD from a local AD: It is important to verify the matching criteria for the object-merge process (in a later step). A unique matching attribute is required to match each Notes user to the corresponding security object in AD. A matching attribute may already be available, or a custom attribute can be populated in the Domino Directory and extracted, or a matching attribute can be populated into the MNE SQL database via TSV export/import.

If mail-enabled users already exist in a local proprietary Active Direc­tory: Ensure the address listed in the exported TargetAddress column is appropriate. With existing mail-enabled users, Migrator for Notes to Exchange uses the Target­Address to locate the AD object for mailbox creation. The value of the TargetAddress in the SQL database must match a valid SMTP address on the target mail-enabled object. Also, the TargetAlias addresses will be applied as secondary/proxy addresses, so it is important to verify them before proceeding.

Step 10: Define user collections

Many of the Migrator for Notes to Exchange wizards are applied to particular user collections: user-defined subsets of the total universe of Notes users to be migrated. For example, in the batch migration of users by the MNE Data Migration Wizard, the batches are defined by the user collections.

User collections can come in all sizes, from a single user up to the entire universe of users all in a single collection. Collections typically number a hundred or so users per batch when migrating to a local proprietary Exchange, but often are much smaller when migrating to Microsoft 365. The Migrator for Notes to Exchange Pre-Migration Planning Guide (see Batch vs. Per-Desktop Migration in chapter 3) explains how target type influences the optimum number of users per collection, and why it is important to devise a grouping strategy for defining collections—to specify number of users per collection, grouping method, and migration scheduling.

Use the Collection Wizard now to define your user collections. Remove any objects from collections that you do not want to provision into the target AD. Chapter 5 of the Migrator for Notes to Exchange Administration Guide provides instructions and application notes for the Collection Wizard.

NOTE: Notes groups (distribution lists) are usually defined and migrated separately, after all users are migrated. The Post-migration activities at the end of this chapter include the definition of group collections and migration of groups.

Later in this process you can assess per-user data volumes in the Notes source, and adjust your collection definitions if appropriate.

Also: Define custom design classes

Conditional Step: This step applies only if your Notes environment uses any non-standard design classes.

The MNE Notes Migration Manager (the MNE console) lets you identify any non-standard Notes design classes that are associated with Notes NSF files, but that the wizards would not recognize because the names are different from the Notes-standard design classes. The Design Classes table in Notes Migration Manager enumerates all such non-standard design classes, and associates each design class with one or more particular data types: mail, archives, or PABs. If the Data Migration Wizard or SSDM finds an NSF file that doesn’t match any of the program's default design classes for archive, mail or PAB files, the program will look at these tables to find an alternate design class, and thereby determine the file type.

If your Notes environment has any non-standard design classes, use the Manage Design Classes screen in Notes Migration Manager to define them now, as part of this collection-definition step. This feature is fully documented in the Migrator for Notes to Exchange Administration Guide, chapter 1 (see User Collections: Manage Design Classes).

Step 11 (if you provision Microsoft 365 from local AD): Provision local AD

Conditional Step: This step and the next apply only if you intend to provision Microsoft 365 from a local proprietary AD. If you are provisioning Microsoft 365 by Migrator for Notes to Exchange or some other method, the provisioning must occur in the Batch migration process later in this chapter. For now, skip to step 13.

In this step you provision only local Active Directory. The local AD is provisioned the same way whether your ultimate destination is a local proprietary Exchange or Microsoft 365 (to be provisioned from the local AD). The typical and most direct method begins with an MNE directory export (step 8), followed by a bidirectional directory update by the CMN Directory Connector, as noted in the steps that follow. An illustration that follows shows the export of Domino directory data into the MNE SQL server database, which precedes the CMN directory update.

This step is necessary even if you have an existing AD already provisioned with user objects since the AD object records must be synchronized with the latest Notes source object records before migration begins. The step to provision the local AD also includes object merging (if necessary) by the MNE Provisioning Wizard to merge existing AD objects with the corresponding contacts created by the directory update. The Provisioning Wizard eliminates contact duplicates, leaving a single mail-enabled AD object corresponding to each Notes user you intend to migrate.

Quest recommends this process to provision a local Active Directory (after the directory export):

1
Synchronize the Notes/Domino directory with the local AD. Quest recommends using the CMN Directory Connector to perform a bidirectional update between the Domino directory and Active Directory. Other tools and methods are also possible, but CMN was designed to complement the Migrator for Notes to Exchange tools. This synchronization extracts user data from the Notes source and creates corresponding mail-enabled contacts in AD, and vice-versa, to update both directories with routing objects corresponding to the users in the other system (to establish complete directories).
2
Run the MNE Provisioning Wizard for all user collections to con­solidate any contact/object duplicates in AD and to mail-enable objects that are already in AD. The Provisioning Wizard merges the contact information into the original corresponding AD object record, and deletes the contact, leaving a single mail-enabled object in AD for each Notes user. If contacts are not added to AD for directory coexistence, the Provisioning Wizard can (without contacts) mail-enable the existing AD security principals. When no corresponding contacts exist in AD, the wizard pulls attributes and addresses from the MNE SQL database to mail-enable objects.
3
Verify Notes forwarding addresses. A merged AD object address attribute tells future CMN directory updates to not re-copy the corresponding Notes object. The routing addresses must be verified before you continue this process.
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级