サポートと今すぐチャット
サポートとのチャット

Migrator for Notes to Exchange 4.15.2 - 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's Office 365
Pre-migration preparations Batch migration process Post-migration activities
SSDM (per-desktop) migration

Step 7: Discover Notes information

Migrator for Notes to Exchange needs to know the location of the Notes Address Books (NABs) that will serve as data sources for the Directory Export Wizard in the next step below. Migrator for Notes to Exchange also needs to know the Internet domains that will be used to generate users’ SMTP aliases. Migrator for Notes to Exchange therefore includes Wizards to search through your Notes environment and return the necessary information:

NABs Discovery Wizard: Locates available NABs and lets you specify the ones to be exported.
Internet Domains Discovery Wizard: Identifies associated Internet domains.

Run these two Wizards now, to prepare for the Directory Export Wizard in the next step below. For operational details, see the Migrator for Notes to Exchange Administration Guide.

Step 8: Export Notes directory data

Migrator for Notes to Exchange’s Directory Export Wizard extracts user and group data from the Notes environment and populates Migrator for Notes to Exchange’s SQL database and other data files with this information. Other Quest applications require this data for input values. Run the Directory Export Wizard now to capture the necessary information. For more information and complete operating instructions for the Directory Export Wizard, see the Directory Export Wizard chapter in the Migrator for Notes to Exchange Administration Guide.

Step 9: Review and verify/modify the exported data in the SQL database

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.

Verify the matching criteria for the provisioning process (in a later step below). A unique matching attribute will be required to match each Notes user to a corresponding security object in AD. A matching attribute may already be available, or a custom attribute can be populated in the Domino Directory and exported, 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 Active Directory: Make sure the addresses listed in the TargetAddress column are appropriate, since Migrator for Notes to Exchange will use that value 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 mail-enabled AD object. The TargetAlias addresses also will be applied as secondary/proxy addresses, so it is important to verify them before proceeding.

Conditional Substep: This substep applies only if your target AD is configured for a resource forest and a user forest, with corresponding user accounts.

For the Data Migration Wizard to properly enable mailboxes, and to properly associate the resource accounts with the user accounts, you must configure the Global Default Settings in Notes Migration Manager, and prepare (or verify) the per-user values in a column of the exported directory data. These preparations are necessary for the Data Migration Wizard to properly associate the resource accounts with the user accounts and properly enable mailboxes.

Before you begin, you must determine which column in the SQL Server database will correspond to which AD attribute, for the Wizard to match corresponding user accounts in the resource forest and user forest. The column (AdSearchCol) and attribute (AdAttribute) are both specified in the [ActiveDirectory2] section of the Global Default Settings of Notes Migration Manager:

AdSearchCol: The column in the SQL Server database whose values the program should search for each particular AdAttribute value, to match corresponding user accounts in the resource forest and user forest. Note that the column specified here and its per-user values must exist before the Data Migration Wizard is run.
IMPORTANT: In the current Migrator for Notes to Exchange version, this AdSearchCol parameter value must be set to SearchKey2 for the mailbox-enabling process to succeed. The parameter default is AdSearchCol=SearchKey2.
AdAttribute: The AD attribute whose values the program should read in the AdSearchCol column of the SQL database, to match corresponding user accounts in the resource and user forests. For example:
... tells the Wizard to match AD objects with users such that the value of each AD object’s userPrincipalName attribute matches the value of the corresponding user’s SearchKey2 column in the SQL Server database.
1
Within Notes Migration Manager, select File | Global Default Settings. The program then opens the program’s configuration settings into Windows Notepad. The settings look like the contents of an INI file, but are actually saved as a part of the SQL Server database.
2
In the [ActiveDirectory2] section, set the appropriate parameter value for AdAttribute, as described above.
1
Within Notes Migration Manager, in the Export Notes Directory screen: Click Export objects to TSV. A dialog box will prompt you for a destination folder and filename for the exported file.
3
In the Export Notes Directory screen: Click Import objects from TSV to import the edited .tsv file into the SQL Server database. A dialog box will prompt you for the filename and its location.

Step 10: Define user collections

Many of the Migrator for Notes to Exchange Wizards are applied to particular user collections: user-defined subsets of all Notes users to be migrated. User collections can come in all sizes, from a single user up to the entire universe of users all in one collection. Collections typically number a hundred or so users per batch when migrating to a local Exchange.

The Migrator for Notes to Exchange Pre-Migration Planning Guide (see in chapter 3, Batch vs. Per-Desktop Migration) explains a few factors that are likely to affect your optimum number of users per collection, and why it is important to decide on a grouping strategy for defining collections.

Use the Collection Wizard now to define your user collections. Remember to remove from collections any objects you do not want to provision into the target AD. See the Collection Wizard chapter 5 of the Migrator for Notes to Exchange Administration Guide for more information, application notes and field notes.

Later in this procedure you will be able to assess per-user data volumes in the Notes source, and then adjust your defined collections if appropriate.

Some administrators prefer to provision users in the same user collection to two or more Exchange mail stores. This can be accomplished by updating the SQL database to include appropriate values for the HomeMDB of each user.

The HomeMDB column specifies the Exchange mailbox store for each migrating user and is used when mailbox-enabling users through the Exchange Administrative Operations of the Data Migration Wizard. For example:

Note that the Exchange admin credentials supplied to Migrator for Notes to Exchange must have sufficient rights to create mailboxes on the Exchange server(s) specified in this HomeMDB column. If the HomeMDB column is left blank, the value specified in the Migrator for Notes to Exchange GUI will be used for the destination Exchange mailbox store.

Conditional Substep: This substep applies only if your Notes environment uses any non-standard 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).

関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択