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 Directory: Make sure the address listed in the exported TargetAddress column is appropriate. With existing mail-enabled users, Migrator for Notes to Exchange uses the TargetAddress 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.
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. |
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).
Conditional Step: This step and the next apply only if you intend to provision Office 365 from a local proprietary AD. If you are provisioning Office 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 ahead to step 13. |
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 Migrator for Notes to Exchange’s Provisioning Wizard (for all user collections) to consolidate any contact/object duplicates in AD and mail-enable objects that were already in AD. The Provisioning Wizard merges each contact’s information into the original corresponding AD object record, and then deletes the contact, leaving a single mail-enabled object in AD for each Notes user. If contacts were 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 Migrator for Notes to Exchange’s SQL database to mail-enable objects. |
3 |
Verify Notes forwarding addresses. Remember that a merged AD object’s address attribute will tell future CMN directory updates to not re-copy the corresponding Notes object. The routing addresses should therefore be verified before continuing in this process. |
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Termini di utilizzo Privacy Cookie Preference Center