Impersonation and Delegation

When migrating a large number of users in Exchange or Office 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 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 Office 365, we recommend using impersonation. The steps to enable impersonation on Office 365 are much more straightforward, plus you don't have the ability to disable throttling against the admin account on Office 365, so delegation would result in very poor migration speeds.

Using impersonation on Office 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.

 

Setting up Impersonation

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 follow 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 checkmarking the box labeled: Use Administrative Login.

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

    1. Make sure to be using 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 Office 365, under Source, select the check box Use impersonation to authenticate.
    5. If migrating to Office 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.

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

    1. If using impersonation against Office 365 (either at Source or Destination), then when mailboxes are submitted we automatically run a PowerShell script to enable applicationimpersonation role against this account. Therefore, it is unnecessary to run any scripts yourself.
    2. Following is the remote PowerShell command (on Office 365) that we execute when you submit a mailbox for migration:
    3. Enable-OrganizationCustomization
    4. New-ManagementRoleAssignment -Role ApplicationImpersonation -User
    5. 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, in order to improve the speed of migration. (This step is only required if using impersonation from/to Exchange 2010+; it is not required for Office 365.)

    1. On a computer that hosts the Microsoft Exchange Management Shell, open the Microsoft Exchange Management Shell and type the following command, then press Enter.
    2. New-ThrottlingPolicy MigrationWizPolicy
    3. Type the following command and press Enter.
    4. 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
    5. Type the following command and press Enter
    6. Get-Mailbox | Set-Mailbox -ThrottlingPolicy MigrationWizPolicy
    7. This Microsoft TechNet article presents an alternative cmdlet that can also be used to change the throttling policy association: Set-ThrottlingPolicyAssociation.
    8. 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.

Impersonation in 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 the 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 Office 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 Office 365 mail enabled security Group and name it in a recognizable fashion.
  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:

Note: To run the following command, you may need to enable the Organization customization on your Office 365 tenant.

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 follow 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 privilege. 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 the 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 Office 365

Having administrative access to the Microsoft Office 365 control panel to manage users does not necessarily mean that the same account has permissions 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:

$cred = Get-Credential

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $cred -Authentication Basic -AllowRedirection

Import-PSSession $session

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

Remove-PSSession $session

 

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 Office 365.

 ​​

 

Was this article helpful?
0 out of 0 found this helpful