Migrator for Notes to Exchange 4.16.3 - Scenarios Guide

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

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

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