Provisioning a local proprietary Active Directory
Migrator for Notes to Exchange tools can provision Active Directory from the Domino source. The typical and most direct method to provision a local AD begins with an Migrator for Notes to Exchange directory export, followed by a directory update by CMN’s Directory Connector, as illustrated here. Your organization may already have an Active Directory running for login and security purposes, and if so Migrator for Notes to Exchange can synchronize the existing AD objects with the Domino objects, and mail-enable the AD objects. In either case, this provisioning step is necessary before any users are migrated.
![](/es-es/technical-documents/image/6196baec-0c96-499c-96bb-c0996b329612)
In many organizations the migrating users are already using AD security objects for network authentication prior to the migration project. In that case, or in any case where Notes users already exist as user objects in Active Directory, CMN’s Directory Connector (and other directory-update tools) will produce duplicate entities in AD. But Migrator for Notes to Exchange includes a Provisioning Wizard that can merge the contact information into the original AD object record, and then delete the contact, leaving a single mail-enabled object in Active Directory. Other Migrator for Notes to Exchange wizards can then mailbox-enable the AD accounts and provision groups in AD.
When provisioning a local Active Directory, be sure to provision all Notes users into AD as mail-enabled objects, without Exchange mailboxes, before you migrate the first user. Provisioning mail-enabled objects into AD will facilitate Exchange-to-Notes mail forwarding, to correctly route mail that arrives (or originates) in Exchange for not-yet-migrated Notes recipients. But Exchange mailboxes would disable Exchange-to-Notes free/busy queries: Exchange cannot send free/busy queries to an external server for a user who already has an Exchange mailbox.
This Exchange free/busy restriction becomes irrelevant if you defer creating users’ mailboxes until just prior to their migration, several steps later. Our standard scenario procedures (in chapter 2 of the Migrator for Notes to Exchange Scenarios Guide) follow this approach for provisioning a local proprietary Active Directory.
Provisioning Office 365
Your organization may already have a local Active Directory running for login and security purposes, and if so Microsoft’s AD sync tool can copy objects from the local AD up to Office 365. But even where no local AD is already in place, many admins find it easiest to first configure and provision a local "staging" AD, so they can provision Office 365 from the local AD with Microsoft’s AD sync tool.
Provisioning Office 365 from a local AD makes possible what Microsoft calls single sign-on, and identity federation, so your users can access Office 365 services with the same corporate credentials (user name and password) they use for the local Active Directory.
The local AD is provisioned the same way whether your ultimate destination is the local AD (see Provisioning a local proprietary Active Directory above), or Office 365 to be provisioned from the local AD.
If you prefer, you could use Migrator for Notes to Exchange tools to provision Office 365 directly from the Domino source, or you could use Microsoft’s Office 365 online admin tools to provision manually—usually with some scripting to automate portions of the work. Note however:
Exchange-to-Notes mail forwarding requires mail-enabled objects in Office 365. But an Exchange-to-Notes free/busy query (an Office 365 user seeking free/busy info for a Notes user) requires that the Notes user not have an Exchange mailbox. (Exchange cannot send a free/busy query to an external server for a user who already has an Exchange mailbox. Exchange can send such queries only to its own mailboxes.)
Therefore, to have both Exchange-to-Notes mail routing and Exchange-to-Notes free/busy queries during the transition period, you must:
• |
Provision all Notes users into Office 365 as mail-enabled objects, but with out mailboxes, before the first users are migrated, and |
• |
Do not create users’ mailboxes until just prior to their migration (per user collection). |
Microsoft's AD sync tool can provision mail-enabled objects from a local AD into Office 365 without simultaneously creating mailboxes, but other provisioning methods create Office 365 mailboxes at the same time they create the mail-enabled user objects.
Of course this Exchange free/busy restriction is irrelevant if you do not intend to configure any free/busy coexistence. In that case, simply provision all users (in all collections) into the hosted AD in the Pre-Migration Preparations, to preserve Exchange-to-Notes mail-forwarding.
Be sure to carefully consider these options before you begin the pre-migration preparations, and note your choices and methods in your Migration Plan.
Diagram before-and-after site configurations
Characterize the configuration of the organization’s servers, both as they are now and how they will be after the migration.
Draw a network map of the pre-migration Notes/Domino environment, showing:
The network map should be a graphical illustration, to help migration planners visualize the relationships between the data volumes of the various servers and the inter-node bandwidths that connect them.
For each server, note also (but not necessarily on the same network map):
Next, draw another network map to show your post-migration Exchange environment: the locations and domain names of all servers, and the data capacity of each server. Then view the pre-migration and post-migration configurations side-by-side, and determine which users from which Notes servers will migrate to which Exchange servers. Make a table to document these before-and-after server assignments for each group of users to be migrated.
Migration scale
The scale of a migration project is a critical planning factor because it determines whether an organization will require email, directory and calendar coexistence during the transition period. (Coexistence is explained in detail in a later section of this chapter.) The scale of a migration is determined primarily by the processing time required to move all of the data from Notes to Exchange. If the scale of your migration lets you move all of your users and their data from one environment to the other in a single weekend, then you can probably get along without any accommodations for coexistence. So how do you assess your migration scale, to determine whether you will need coexistence?
The two most important factors that affect migration processing time are data volume, and the number of migration servers that will be used to migrate the data. Remember the Data Migration Wizard can be run on multiple migration servers running in parallel, applied to different user groups simultaneously. In this way, you might employ a half dozen migration servers to migrate a particular data volume in a single weekend, whereas you would need a half dozen weekends to migrate the same volume via a single workstation.
Data "geography" and bandwidth are the most significant factors affecting the rate of data migration, and migration server hardware (memory, number and speed of CPUs, and disk speed) is also important. Actual throughput rates for the Data Migration Wizard vary widely with the interplay of all relevant factors, but administrators typically report migration rates of 1 to 5 gigabytes per hour.
If the data to be migrated is distributed among servers in dispersed geographic locations, and if the bandwidth among these servers is problematic, then the throughput rate will likely be at the lower end of that range. On the other hand, a migration rate of 5 GB per hour or faster is likely if the source data is centralized and the bandwidth is very good. Much higher rates have been reported under optimal conditions with high-performance workstation hardware.
The chart below can help you estimate the throughput rate for your migration project, but remember that actual rates vary widely and you should not rely on these values as definitive. The chart does not account for hardware factors, and your assessment of your own bandwidth is subjective and arbitrary. You cannot reliably predict your own throughput rate without experimenting in your own environment with your own data.
To estimate the total processing hours of a migration project, first determine the estimated throughput rate. The estimated throughput rates cited here assume that you are operating at an optimum number of migration threads (simultaneous processes), typically 8–12:
Estimated Throughput Rates (GB/hr)
... and then plug that value into this formula:
This formula will help you estimate the number of processing hours required for Quest’s Data Migration Wizard to migrate a particular volume of data under particular conditions, but remember there is much more to a migration project than just processing time. An administrator must also export directory data from Notes sources, provision users and distribution groups into Active Directory, define collections of users and groups, and so forth. You should also allow time to review the Quest wizards’ log files, to verify that the wizards’ run parameters are appropriate and efficient, and to catch and correct any minor problems before they become major problems.
Per-desktop tasks such as installation of the Outlook client, and sometimes the migration of archives (separately, per-user) also must be figured into the plan, and you should also expect an increased demand on the organization’s Help desk. You may find that a couple dozen instances of the Data Migration Wizard running on parallel workstations can migrate thousands of users over a weekend, but you’ll face a support nightmare on Monday morning if you haven’t ramped up your Help desk staff to accommodate all of the likely calls from freshly migrated users.
For a longer-term migration that will span more than just a couple of weeks, you can expect that these other associated admin tasks will get easier and take less time as the project progresses. But these collateral admin tasks make it unwise to attempt a single-weekend migration if the estimated migration processing time exceeds 20 to 30 hours.