Tchater maintenant avec le support
Tchattez avec un ingénieur du support

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

Migration to Microsoft 365

Migrator for Notes to Exchange can migrate to hosted Exchange services, typically to Microsoft 365 Exchange Online. Migration to Microsoft 365 is similar to on-premises migrations, but there are key differences so the processes are described separately in this Scenarios Guide (chapters 2 and 3).

The account permissions required for migration to Microsoft 365 are different from those required when migrating to 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).

Throttling and throughput

Microsoft 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 Microsoft 365 throttling reduces typical throughput to 500MB/hr or less per machine.

Quest recommends that you use multiple migration machines (or virtual machines) running in parallel to achieve the desired throughput when migrating to Microsoft 365. Use a separate unique <MigrationAdmin> account for each machine, to bypass the Microsoft 365 throttling. Also, each migration machine should be configured with fewer threads (2–4) to optimize throughput.

Quest is working directly with Microsoft to test modifications to Microsoft 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 Microsoft 365.

Since Microsoft throttling is applied per administrator account, Migrator for Notes to Exchange runs multiple administrator accounts simultaneously on separate machines, each set to migrate with only one thread at a time. The net throughput becomes a function of the sum of all these multiple accounts’ processing threads—one per administrator account.

MNE includes an Admin Account Pool utility that helps you manage a pool of Microsoft 365 administrator accounts and to coordinate these administrator accounts. For information, see the “Microsoft 365 Admin Account Pool utility” chapter in the NME Administration Guide.

Provisioning and mailbox creation

The Microsoft AD synchronization tool can provision Microsoft 365 with object data from local AD by synchronizing the two directories. This provisioning method permits single sign-on or identity federation so users can access Microsoft 365 services with the same credentials (user name and password) they use for local AD.

If you are provisioning Microsoft 365 using the Microsoft AD Sync tool, from local AD, you can provision the local AD the same as for a proprietary Exchange target—using MNE features (with or without Quest CMN). The Microsoft AD Sync tool can provision the hosted AD from the local AD.

Migrator for Notes to Exchange can also manage mail routing throughout the project and perform several server-administrative tasks commonly associated with migrations.

If you do not have local Active Directory, you can use MNE to provision Microsoft 365 directly from the Notes source and create the hosted mailboxes. Otherwise, you could provision a hosted AD manually using the Microsoft 365 admin portal. Many administrators use scripting to automate some portions of the process.

NOTE: Exchange-to-Notes mail forwarding requires mail-enabled objects in Microsoft 365. However, an Exchange-to-Notes free/busy query (an Microsoft 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.)

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 Microsoft 365 as mail-enabled objects, but without mailboxes, before the first users are migrated.
Do not create user mailboxes until prior to their migration (per user collection).

If you cannot provision objects and create mailboxes separately, one or the other of those two features will be sacrificed. Microsoft's AD Sync tool can provision mail-enabled objects from local AD into Microsoft 365 without simultaneously creating mailboxes, but other provisioning methods create Microsoft 365 mailboxes at the same time they create the mail-enabled user objects.

Provisioning Microsoft 365 by any method other than by the Microsoft AD Sync tool (from local AD) makes it impossible to have both Exchange-to- Notes mail forwarding and Exchange-to-Notes free/busy queries during the transition period.

This Exchange free/busy limitation is irrelevant if you do not intend to configure any free/busy coexistence. In that case, provision all users (in all collections) into the hosted AD in the Pre-Migration Preparations, to preserve Exchange-to-Notes mail-forwarding.

Mail routing

For most scenarios, inbound external (Internet) mail is not redirected to Microsoft 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 Microsoft 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 Microsoft 365 by directory synchronization from a local AD since that is the only method that lets you create mail-enabled objects and hosted mailboxes at different times. Provisioning from a local AD lets you create mail-enabled objects for all users in the Pre-Migration Preparations and to create mailboxes later during the Batch Migration Process—per user collection, prior to their migration.

If you are provisioning using some other method, you must choose whether you want Exchange-to-Notes mail routing or Exchange-to-Notes free/busy queries.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation