Migrator for Notes to Exchange can migrate to hosted Exchange services ("the cloud"), typically to Microsoft Office 365. Migration to Office 365 is similar to on-premises migrations, but there are enough differences that we document the processes separately, in separate chapters of this Scenarios Guide (chapters 2 and 3).
The account permissions necessary for migration to Office 365 are different from those needed when migrating to a proprietary Exchange, since the hosted services are shared resources controlled by an external entity (Microsoft). Access to either target type is set at the mailbox level through Remote PowerShell, as described in the Migrator for Notes to Exchange Quick-Start Guide and Pre-Migration Planning Guide (see the System Requirements section in either book).
Office 365 introduced throttling on user connections, which impacts migration performance. The throttling is a per-user limitation that reduces throughput after more than two connections by a single user (including the <MigrationAdmin> user). With previous versions of Exchange Online, migration throughputs of 3-5GB/hr per machine were common. But the Office 365 throttling reduces typical throughput to 500MB/hr or less per machine.
Quest therefore recommends that you use multiple migration machines (or virtual machines) running in parallel to achieve the desired throughput when migrating to Office 365. Use a separate unique <MigrationAdmin> account for each machine, to bypass the Office 365 throttling. Also, each migration machine should be configured with fewer threads (2–4) to optimize throughput.
At this writing, Quest is working directly with Microsoft to test modifications to Office 365 throttling policies and their impact on migration throughput. It may soon be possible to modify the throttling policies to improve migration throughput. However, multiple migration machines with unique migration accounts may still be desirable and/or necessary for more efficient migration to Office 365.
Microsoft AD synchronization tool can provision Office 365 with object data from a local AD by synchronizing the two directories. This provisioning method permits what Microsoft calls single sign-on, or identity federation, so users can access Office 365 services with the same corporate credentials (user name and password) they use for your local AD.
If you will provision Office 365 by Microsoft AD Sync tool from a local AD, you can provision the local AD the same as for a proprietary Exchange target—using Migrator for Notes to Exchange features (with or without Quest CMN). Microsoft AD Sync tool can then provision the hosted AD from the local AD.
If you will not have a local AD, you can use Migrator for Notes to Exchange to provision Office 365 directly from the Notes source, and create the hosted mailboxes. Otherwise, you could provision a hosted AD manually by Microsoft Office 365 admin portal. In that case, many admins use scripting to automate some portions of the process.
NOTE: Exchange-to-Notes mail forwarding requires mail-enabled objects in Office 365. However, 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:
If you cannot provision objects and create mailboxes separately, then one or the other of those two features will be sacrificed. 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.
Therefore, provisioning Office 365 by any method other than by the Microsoft AD Sync tool (from a local AD) makes it impossible to have both Exchange-to- Notes mail forwarding and Exchange-to-Notes free/busy queries during the transition period.
Of course this Exchange free/busy limitation 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.
For most scenarios, inbound external (Internet) mail is not redirected to Office 365 until the last user has been migrated. We leave the MX record pointing to Notes throughout the entire transition period, and Migrator for Notes to Exchange can set Notes-to- Exchange forwarding for users as their collections are migrated. When the last user in the last collection is migrated, we update the MX record to redirect external inbound mail to the new hosted mailboxes.
If you want to keep your Notes environment running for a time after the migration, you should leave the Notes-to-Exchange forwarding in place, so any internal Notes mail is routed to the new hosted Exchange mailboxes.
Since inbound external mail is not routed to Office 365 until after all users have been migrated, Exchange-to-Notes forwarding is necessary only for internal mail from already-migrated Exchange users to not-yet-migrated Notes users. Mail routing in the Exchange-to-Notes direction requires mail-enabled objects in the hosted AD, but Exchange-to-Notes free/busy queries will not work if the Notes user already has an Exchange mailbox. (See the Important note in the preceding section for more information about this.)
If your organization wants both capabilities, you must use Microsoft AD Sync tool to provision Office 365 by directory synchronization from a local AD, because that is the only method that lets you create mail-enabled objects and hosted mailboxes at different times. That is, provisioning from a local AD lets you create mail-enabled objects for all users in the Pre-Migration Preparations, and then create mailboxes later, during the Batch Migration Process—per user collection, just prior to their migration.
© 2020 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Conditions d’utilisation Confidentialité