When migrating a large number of users in Exchange or Microsoft 365, log-in credentials are required for each user. This is a slow and error-prone process, especially for very large migrations.

Impersonation and delegation offer an easier system for bulk user migrations. Impersonation allows for the use of a single administrative account - created specifically for the migration process - to impersonate and access the user accounts. Delegation is a process where the user grants their authentication credentials to that administrative account.

In short, Impersonation allows for the collection of user information without user input, while delegation collects the data through user input. Both methods allow the migration manager to significantly reduce the time and redundancy necessary to prepare users for migration. 

Delegation vs. Impersonation

Delegation means that a mailbox admin user has been set up with delegated full access rights to each user's mailbox. MigrationWiz will then use delegated rights to log in to individual user mailboxes when performing their migration. 

Impersonation means that the admin account will actually impersonate each mailbox user when performing the migration. This produces a faster migration since the admin account will not be restricted by having to share the throttling quota and connection limits associated with a single administrative account. Instead, the throttling quota of each user is used independently on each user mailbox. You can also disable the throttling quota of each user. This will result in even faster migrations. 

Which process should I use?

If the migration source or destination is Exchange, then we recommend using delegation. This requires fewer steps to configure, and migration speeds are very similar. Setting up delegation is straightforward, as you simply set up the administrator account, disable throttling on the account, and then add the administrator account to the MigrationWiz project.

If the source or destination is Microsoft 365, we recommend using impersonation. The steps to enable impersonation on Microsoft 365 are much more straightforward, you don't have the ability to disable throttling against the admin account on Microsoft 365, so delegation would result in very poor migration speeds.

Using impersonation on Microsoft 365 also provides the following advantages:

• Eliminates most "Connection did not succeed" errors.
• Allows migration of more mailboxes concurrently.
• Reduces the impact of throttling and connection limits.
• Uses an admin account without assigning a license to it.

Setting up Delegation

Any user account that is a part of the domain administrator, schema administrator, or enterprise administrator groups will not have any administrative rights to mailboxes, no matter how many permissions are granted. A security default of Exchange Server is to explicitly deny any user that is a member of these groups. This is why we recommend creating a new user account specific for migration.

1. Set up the 'admin' account to be used for migration, and apply the necessary permissions so that the account has full access to each mailbox. 
2. Disable throttling against this account, if using Exchange 2010+. This step is not required with Exchange 2003 or Exchange 2007, since those versions do not support throttling.
3. Set up the MigrationWiz project, and select Use admin credentials. Enter the username and password of the account that was set up under Step 1 above.

Set up the administrator account to be used for migration, and then apply the necessary permissions so that the account has full access to each mailbox on the source.

1. To create an administrator account (e.g., MigrationWiz), perform the following steps when logged into the Exchange Server.
2. Open the Exchange Management Console.
3. Expand the Recipient Configuration node.
4. Right-click on the Mailbox node.
5. Click on New Mailbox.
6. Click on Next.
7. Click on Next.
8. Enter "MigrationWiz" as the first name.
9. Enter "MigrationWiz" as the user logon name, and optionally select a user principal name (UPN) domain.
10. Enter a password and confirm the password.
11. Click on Next.
12. Click on Browse to select a Mailbox database.
13. Click on Next.
14. Click on New.
15. Click on Finish.
16. To grant the account access, perform the following from the Exchange Server machine:
17. Open the Exchange Management Shell.
18. Enter the following command:
    Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -User MigrationWiz
19. The above command needs to be applied each time a new mailbox is created since permissions are set directly on each mailbox. The administrative account will not have access until the permissions are applied.
20. In the above script, the username "MigrationWiz" should be replaced with the name of the administrative account that was set up, by following the earlier instructions in this article.
21. This username is the Administrative Username that needs to be entered under project source or destination settings, within MigrationWiz, when check marking the box labeled: Use Administrative Login.

Setting up Impersonation

Enable the Application Impersonation role for the admin account. (This step is only required if enabling impersonation on Exchange; it is not required for Microsoft 365.)

Under your MigrationWiz project Advanced Options, select the check box to use impersonation, then complete the following:

1. Make sure to use admin credentials at the Destination.
2. Sign in to the MigrationWiz account.
3. Edit the Project and click on Advanced Options.
4. If migrating from Microsoft 365, under Source, select the check box Use impersonation to authenticate.
5. If migrating to Microsoft 365, under Destination, select the check box Use impersonation to authenticate.
6. Click Save Options.

This option is under both Source and Destination. Refer to the section "Which should be used for different migration scenarios?" above to determine if you should be using impersonation at the Source and/or Destination.

If the above Advanced Options are set to use impersonation on a project, these settings will only become effective for those migrations that are started after saving the settings. Migrations that are already running will be unaffected by any such changes.

1. If using impersonation against Microsoft 365 (either at Source or Destination), then when mailboxes are submitted we automatically run a PowerShell script to enable the application impersonation role against this account. Therefore, it is unnecessary to run any scripts yourself.
2. Following is the remote PowerShell command (on Microsoft 365) that we execute when you submit a mailbox for migration:
   Enable-OrganizationCustomization
   New-ManagementRoleAssignment -Role ApplicationImpersonation -User
3. If using impersonation against Exchange (either at Source or Destination), an extra step is required since on-premises PowerShell is not available for access over the internet, and thus the impersonation cmdlets cannot be run. Therefore, it is necessary to run this script against the on-premises Exchange environment, using an admin account: New-ManagementRoleAssignment -Role ApplicationImpersonation -User

Disable throttling against all mailboxes, to improve the speed of migration. (This step is only required if using impersonation from/to Exchange 2010+; it is not required for Microsoft 365.)

1. On a computer that hosts the Microsoft Exchange Management Shell, open the Microsoft Exchange Management Shell type the following command, then press Enter.
   New-ThrottlingPolicy MigrationWizPolicy
2. Type the following command and press Enter.
   Set-ThrottlingPolicy MigrationWizPolicy -RCAMaxConcurrency $null -RCAPercentTimeInAD $null -RCAPercentTimeInCAS $null -RCAPercentTimeInMailboxRPC $null -EWSMaxConcurrency $null -EWSPercentTimeInAD $null -EWSPercentTimeInCAS $null -EWSPercentTimeInMailboxRPC $null -EWSMaxSubscriptions $null -EWSFastSearchTimeoutInSeconds $null -EWSFindCountLimit $null -CPAMaxConcurrency $null -CPAPercentTimeInCAS $null -CPAPercentTimeInMailboxRPC $null -CPUStartPercent $null
3. Type the following command and press Enter
   Get-Mailbox | Set-Mailbox -ThrottlingPolicy MigrationWizPolicy
4. This Microsoft TechNet article presents an alternative cmdlet that can also be used to change the throttling policy association: Set-ThrottlingPolicyAssociation.
5. Set up the MigrationWiz project, and checkmark the box to use admin credentials. Enter the username and password of the account that was set up under Step 1 above.

Scoped Impersonation with EWS

When using MigrationWiz and Exchange Web Services (EWS) to migrate to or from Exchange Online, you should use impersonation (not delegation) when accessing user mailboxes. Using impersonation not only solves some potential throttling issues but more importantly, allows you to scope the impersonation to a specific set of user mailboxes.

The objective is to limit the scope of mailboxes that are migrated using impersonation rights. You accomplish this by implementing an impersonation scope filter. This is a common requirement in migrations where only a subset of an organization's mailboxes are scheduled for migration, for example, in migrations related to mergers and acquisitions.

Setting impersonation scope is a three-step process:

1. Create a Mail Enabled Security Group
2. Create a Management Scope
3. Create the Management Role Assignment

While you can accomplish this task using either the Microsoft 365 Management Console or PowerShell, the instructions that follow use the PowerShell approach.

Create a Mail Enabled Security Group

To create an impersonation scope filter, you first create a special distribution group that defines the filter scope.

1. Connect to Exchange Online using PowerShell.
2. Create a new Microsoft 365 mail enabled security Group and name it recognizably.
3. Add to the new security Group all of the user mailbox accounts that you intend to migrate. If this group is being used only for scoping impersonation, we recommend hiding the group from the Global Address list.

Retrieve the DistinguishedName property of the Group by using the Get-DistributionGroup command:

Get-DistributionGroup -Identity "YourGroupName" |fl name, dist*


This PowerShell command returns the group name (name) and DistinguishedName (in this instance using the wild card format, dist*), which enables creating the management scope. Where you see "YourGroupName", insert the name you have assigned to your distribution group.

Create a Management Scope

Using the DistinguishedName property retrieved in the previous step, along with the RecipientRestrictionFilter and MemberOfGroup filtering parameters, create a management scope by running the following PowerShell command:

New-ManagementScope "YourScopeName" -RecipientRestrictionFilter {MemberOfGroup -eq 'YourGroupDistinguisedName'}


Where you see "YourScopeName", provide the name you've assigned to your management scope; and, where you see "YourGroupDistinguisedName", provide the group's DistinguisedName value, for example:

CN=AllowImpersonationDistributionGroup,OU=tenantname.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURP193A002,DC=PROD,DC=OUTLOOK,DC=COM


Create the Management Role Assignment

The final step is to create a management role assignment and then associate it with the migration account that has administrative privileges.

Create the management role assignment by issuing the following PowerShell command:

New-ManagementRoleAssignment -Name "YourMigrationProject" -Role "ApplicationImpersonation" -User "YourAdminAccountName" -CustomRecipientWriteScope "YourManagementScope"


Where the following values are provided or returned:

• Name is the name of your migration project YourMigrationProject
• Role is the value ApplicationImpersonation.
• User is the migration account that has administrative privileges. YourAdminAccountName
• CustomRecipientWriteScope is the name you assigned to the management scope you created YourManagementScope

When using MigrationWiz and Exchange Web Services (EWS) to migrate to or from Exchange Online, you should use impersonation (not delegation) when accessing user mailboxes. Using impersonation not only solves some potential throttling issues but more importantly, allows you to scope the impersonation to a specific set of user mailboxes.

The objective is to limit the scope of mailboxes that are migrated using impersonation rights. You accomplish this by implementing an impersonation scope filter. This is a common requirement in migrations where only a subset of an organization's mailboxes are scheduled for migration, for example, in migrations related to mergers and acquisitions.

Delegation in Microsoft 365

Having administrative access to the Microsoft 365 control panel to manage users does not necessarily mean that the same account has permission to access all mailboxes for migration. In order to have administrative permissions to migrate mailbox data, it is necessary to grant the account permissions on each mailbox.

To manually grant administrative access for migration, execute the following remote PowerShell command:

$LiveCred = Get-Credential

Install-Module -Name ExchangeOnlineManagement
Import-Module -Name ExchangeOnlineManagement
Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred

Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -Automapping $false -User MigrationWiz

The above command needs to be applied each time a new mailbox is created, as permissions are set directly on the mailbox. The administrative account will not have access until the permissions are applied.​

The global admin account does have the necessary rights for delegation. However, again, we recommend using impersonation for migrations​ from and/or to Microsoft 365.

If connecting to GCC High with powershell, use

Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -ExchangeEnvironmentName O365USGovGCCHigh