Migrator for Notes to Exchange 4.15.2 - Scenarios Guide

Step 9: Review and (if necessary) modify the 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 (to occur 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 Migrator for Notes to Exchange’s SQL database via TSV export/import.

If mail-enabled users already exist in a local proprietary Active Direc­tory: Make sure 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 therefore 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 Migrator for Notes to Exchange’s Data Migration Wizard, the user batches are defined by Migrator for Notes to Exchange 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 Office 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. Remember to remove from collections any objects 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: Remember, Notes groups (distribution lists) are usually defined and migrated separately, after all users have been 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 will be able to assess per-user data volumes in the Notes source, and then adjust your collection definitions if appropriate.

Also: Define custom design classes

Migrator for Notes to Exchange’s Notes Migration Manager (the Migrator for Notes to Exchange "console") lets you identify any non-standard Notes design classes that may be associated with Notes NSF files, but that the Wizards would not otherwise recognize because their 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 will provision Office 365 from a local AD): Provision the local AD

In this step we provision only the local AD. The local AD is provisioned the same way whether your ultimate destination is a local proprietary Exchange, or Office 365 (to be provisioned from the local AD). The typical and most direct method begins with an Migrator for Notes to Exchange directory export (step 8 above), followed by a bidirectional directory update by CMN’s Directory Connector, as noted in the substeps below. The illustration shows the export of Domino directory data into Migrator for Notes to Exchange’s SQL server database, which precedes the CMN directory update.

This step is necessary even if you have an existing AD that is already provisioned with user objects, since the AD object records must be synchronized with the latest Notes source object records before migration begins. This step to provision the local AD also includes object merging (if necessary) by Migrator for Notes to Exchange’s Provisioning Wizard, to merge any existing AD objects with the corresponding contacts created by the directory update. The Provisioning Wizard thus eliminates the 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):