Migrator for Notes to Exchange can migrate to hosted Exchange services ("the cloud"), typically to Microsoft’s 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.
Microsoft’s 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.
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. |
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’s 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.
© ALL RIGHTS RESERVED. Términos de uso Privacidad Cookie Preference Center