지금 지원 담당자와 채팅
지원 담당자와 채팅

On Demand Migration Current - Hybrid Exchange User Guide

Consents and Permissions

The ability for On Demand service principals to access and operate with tenant assets requires explicit permissions. The Tenant Administrator grants these permissions through consents.

Each tenant that is added has granted consent to the initial Core - Basic permission set to the On Demand service principal. Additional consents are required to work with different features of On Demand Migration for Hybrid Exchange.

Granting Consent
  1. Click Tenants from the navigation pane.
  2. Select a tenant and click Edit Consents from the tenant tile.
  3. Click Grant Consent or Regrant Consent for the permissions type.
  4. Click Accept in the Microsoft consents page.

When you have granted the consents, verify that the service principals were successfully created in the target tenant as described in the steps below:

  1. Log in to the Azure admin portal.
  2. Click Enterprise applications from the navigation pane. Then click All applications.
  3. Filter the list if necessary and verify the list of service principals.

This section lists the minimum consents and permissions required by the various On Demand Migration service principals for managing tenants, Microsoft 365 objects and other migration services.

For initial tenant setup
Task Minimum consents and permissions
Add and configure tenants, and grant consent

Core - Basic consent from Target tenant administrator accounts.

Global Administrator role from target tenant administrator accounts.

For Mailbox migration
Task Minimum consents and permissions
All tasks Migration - Basic consent from Target tenant administrator accounts.
Migrate mailboxes Migration - Mailbox Migration consent from Target tenant administrator accounts.

Upgrading Throttling Policies

Exchange Web Services (EWS) are throttled by Microsoft whenever large quantities of data flows through the EWS platform. The On Demand Migration service throughput can be improved by upgrading the following throttling policy parameter setting to Unlimited:

  • EwsMaxBurst - Defines the amount of time that an EWS user can consume an elevated amount of resources before being throttled. This is measured in milliseconds. This value is set separately for each component.
  • EwsRechargeRate - Defines the rate at which an EWS user's budget is recharged (budget grows by) during the budget time.
  • EwsCutoffBalance - Defines the resource consumption limits for EWS user before that user is completely blocked from performing operations on a specific component.

Tenant administrators can upgrade the throttling policies by making a service request with Microsoft.

Desktop Update Agent

To complete a migration project, a lightweight user desktop application called Desktop Update Agent (DUA) must be configured and deployed by administrators and run on users workstations. DUA provides enhanced support, helps ensure the success of cross-tenant migration projects, makes agent delivery easier, and status reporting more informative.

DUA features:

  • Ability to manage user’s application reconfigurations activities from a single view within On Demand Migration.
  • Support for Microsoft 365 application license reset.
  • Support for various client authentication mechanisms.

For more information about downloading, administration and use of DUA, see the Quest On Demand Migration Update Agent Guide.

Test and Pilot Migrations

Any full scale migration should be preceded by test and pilot migrations, to confirm that your migration processes and procedures will accommodate the organization requirements.

  • A test migration uses real users and real data in a segregated test environment, or dummy users and dummy data in your live production environment.
  • A pilot migration uses a small portion of real users and real data in the live production environment.

In either case - a test or pilot migration - the data to be migrated should be a representative sample of the production data, and the test or pilot migration should be run with the Quest applications set for the same configuration and process options that you intend to use for the production migration. it is recommended to select test or pilot users whose usage and data types make them representative of the total user population. Then create and run matching / migration tasks for those accounts, including all range of tasks you are planning to perform. When the tasks are completed, review errors and warnings, if any. See Event Management section for more information.

Quest recommends that you use both test and pilot migrations:

Perform one or more test migrations in a separate test environment, migrating test copies of real users and their real data. The separate test environment ensures that no test process will affect the data or configurations of your production environment. If a test exposes any problems under migration, you can make amendments and then repeat the test by simply dumping the test environment and recreating it from scratch.

When you are confident that your test migrations have sufficiently refined your planned migration, perform a pilot migration for 20 or 30 users to verify if your planned migration is satisfactory for your "real world."

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택