Prepare the Source - Hosted and On-Prem Exchange 2007+

Creating and Configuring Permissions

The below sections will explain how to create an admin account and configure access permissions for an administrative account to access the end user's mailboxes within the source environment. Please review the section that best represents your environment.

Exchange 2007+

Set up an administrator account for migration on the Source Exchange mailbox server.

  1. Open the Exchange Management Console.
  2. Expand Recipient Configuration
  3. Right click on Mailbox
  4. Click New Mailbox.
  5. Click Next.
  6. Click Next
  7. Enter "MigrationWiz" as the first name.
  8. Enter "MigrationWiz" as the user login name and optionally select a user principal name (UPN) domain.
  9. Enter a password and confirm the password.
  10. Click Next.
  11. Click Browse to select a Mailbox database.
  12. Click Next.
  13. Click New.
  14. Click Finish.

To grant the account access, perform the following from the Exchange machine:

  1. Open the Exchange Management Shell.
  2. Enter the following command:

Get-Mailbox -server <server> -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -User MigrationWiz

Notes:

The 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.

In the script above, the username "MigrationWiz" should be replaced with the name of the administrative account that was set up by following the instructions in this article.

This username is the Administrative Username that needs to be entered under the project's Source or Destination settings, within MigrationWiz, when checking the box labeled Use Administrative Login.

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.

Exchange 2010+ (using Impersonation)

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports another elevated access mode called impersonation.

Benefits:

Using impersonation, it is possible to stop sharing the throt​tling quota and connection limits associated with a single administrative account. Instead, the throttling quota of each user is used to log in to each user mailbox.

Using impersonation means:

  • Eliminating most "Connection did not succeed" errors
  • Allowing migration of more mailboxes concurrently
  • Reducing the impact of throttling and connection limit

To enable the admin account to impersonate users, run this PowerShell command:

New-ManagementRoleAssi​gnment -Role ApplicationImpersonation -User <admin_user_name>

More information about this PowerShell command can be found here.

Exchange 2007+

If you are migrating from an Hosted Exchange provider, ask the provider to create an account for migration purposes (e.g., named MigrationWiz) and grant full access rights to each mailbox, by running this PowerShell script against the account called MigrationWiz:

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

Notes:

    • Some Hosted Exchange providers allow this access to be granted via their web portal. In this case, you could log in to each mailbox via their portal and then grant the migration account (e.g., MigrationWiz) to have read/write access to each mailbox. This is laborious and time-consuming, and so it is preferable that the Hosted Exchange provider run the PowerShell script above, particularly if you have a large number of users.
    • Some Hosted Exchange Providers will not grant this access. If that is the case, then you can request credentials from your end users during the migration. Exact steps for this are provided under Option 2 in article What credentials are needed to migrate from Hosted Exchange?.

 

Exchange 2010+ (using Impersonation)

If this is a very large project, the best results will be achieved by setting the project to use impersonation at the Source.

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports another elevated access mode called impersonation.

Benefits:

Using impersonation, it is possible to stop sharing the throt​tling quota and connection limits associated with a single administrative account. Instead, the throttling quota of each user is used to log in to each user mailbox.

Using impersonation means:

  • Eliminating most "Connection did not succeed" errors
  • Allowing migration of more mailboxes concurrently
  • Reducing the impact of throttling and connection limit

To enable the admin account to impersonate users, run this PowerShell command:

New-ManagementRoleAssi​gnment -Role ApplicationImpersonation -User <admin_user_name>

More information about this PowerShell command can be found here.

Confirming Access

The below sections will explain how you can locate your OWA URL and test EWS access for your environment. This information will ensure that your migration project is configured properly and will help to prevent failures when performing the migration.
  1. When setting up Exchange as an endpoint, enter either the OWA URL or the EWS URL.
  2. There are some instances in which the login page for OWA is different than the actual OWA URL for the mailbox, as you may get redirected to a different server after logging in. To determine the true OWA URL, perform the following:
  3. Close all browser instances. This ensures that all session state browser cache is flushed.
  4. Open a new browser instance.
  5. Navigate to your OWA login page.
  6. Log in to OWA.
  7. Once you see the inbox, copy the URL from the navigation bar of the browser. This is the exact OWA URL that should be entered into MigrationWiz​.
  • Example URLs for OWA:
  • https://www.mining88.com
  • https://www.mining88.com/owa
  • https://www.mining88.com:443
  • https://50.249.230.12/owa

Another method for determining the OWA URL is to use the "whatismyipaddress" website to determine the company public IP address, and then add /owa to the end of it.

Now that your OWA URL has been determined, we need to ensure that the username and password combination work. The username and password that you use to log in to OWA is the exact same username and password that you should be entering into MigrationWiz. To determine if your username and password is working, perform the following:

  1. Close all browser instances. This ensures that all session state browser cache is flushed.
  2. Open a new browser instance.
  3. Navigate to the same OWA login page as determined by Step 5 above.
  4. Log in to OWA. Pay special attention to the login name, i.e.​,:
  5. Email address means "user@example.com" format.
  6. Domain\user name means "example\user" format.
  7. User name means "user" format.
  8. Once you see the inbox, you have successfully logged into OWA.  Enter the exact same username and password used into MigrationWiz.

Verify mailbox accessibility using EWS. It may be necessary to first grant permissions.

      1. Browse to https://testconnectivity.microsoft.com. This is a Microsoft-owned tool.
      2. If using Office 365, click on the Office 365 tab.
      3. Select Service Account Access (Developers) and click on Next.
      4. Specify the target mailbox email address.
      5. Specify the service account user name (if using admin credentials on the connector, enter the exact same user name).
      6. Specify the service account password (if using admin credentials on the connector, enter the exact same password).
      7. Check Specify Exchange Web Services URL and specify the URL (example: https://server/EWS/Exchange.asmx).
      8. If using Exchange Server, do not check Use Exchange Impersonation. If you are using Office 365, and using impersonation, do check the box.
      9. Check Ignore Trust for SSL.
      10. Click on Perform Test.
      11. Once results are displayed, check the overall result, and also click on Expand All.

Recommendations

The below section will explain how to remove the throttling policy within your Exchange environment. Removing the throttling policy will help with the performance of your migration.

Note:
  • Some Hosted Exchange providers will not allow you to alter the throttling policies with your instance.
  • Removing the throttling policy will allow for a higher through-put of migrated datat, however, this can impact server resources. Please pay close attention to the server resources when performing your migration and determine if your throttling policy needs to be change to maintain a healthy server resource level.

Disable throttling EWS Throttling policy

  1. To disable all throttling parameters for all mailboxes:
  2. Open the Exchange Management Shell.
  3. Type the following command and press Enter: New-ThrottlingPolicy MigrationWizPolicy
  4. 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
  5. Enter the following command and press Enter: Set-Mailbox "MigrationWiz" -ThrottlingPolicy MigrationWizPolicy
  6. The steps above will remove throttling policies against all user accounts at your Source. You still need to enable impersonation within your MigrationWiz project, so that the admin account can impersonate the user accounts during migrations, and so that the migratons use the bandwidth available to the individual user accounts, rather than just the bandwidth available to the admin account. Follow the directions in the Help Center article How do I migrate to Exchange or Office 365 using impersonation? to enable this.
Was this article helpful?
0 out of 0 found this helpful