Exchange migrations vary by source and destination version. The migration guide specific to your scenario will guide you through the steps needed to perform your migration, but the following article contains more general information and explanations about some of the commonly asked questions concerning the setup and planning phases for this migration type.

Set Up Exchange Administrator Account

To create an administrator account (e.g., MigrationWiz), perform the follow steps when logged into the Exchange Server.

1. Open the Exchange Management Console. 
2. Expand the Recipient Configuration node.
3. Right-click on the Mailbox node.
4. Click New Mailbox.
5. Click Next.
6. Click Next.
7. Enter "MigrationWiz" as the first name.
8. Enter "MigrationWiz" as the user logon 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 Server machine:

1. Open the Exchange Management Shell.
2. Enter the following command:
   Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -User MigrationWiz

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.

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.

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.

Compare User Principal Name (UPN) to Email Address

​​The Visual Basic (VB) script discovers all mailboxes within the domain and compares the User Principal Name (UPN) to email address for the object. If they are different, it will log it to the file.

1. Launch the command prompt (cmd.exe).
2. Download the following script:  Check-Exchange2003UserPrincipalNameAndEmailAddress.zip​
3. Run the script on a computer that is joined to the domain you wish to update the user accounts for.

When the script is done executing, you will see a co​​nfirmation dialog. A file will be created within the same directory called "Check-Exchange2003UserPrincipalNameAndEmailAddress.txt" which contains all accounts with non-matching UPNs to their email addresses.

Configure the Server Authentication Method

Please refer to the instructions below for your version of Exchange Server.

Exchange Server 2003

To configure the Exchange authentication method:

1. Open the Exchange System Manager.
2. Expand the Server node.
3. Expand the server node.
4. Expand the Protocols node.
5. Expand the HTTP node.
6. Expand the Exchange Virtual Server node.
7. Right-click on the Exchange node and select Properties.
8. Click the Access tab.
9. Click the Authentication button.
10. Make sure Basic Authentication is selected as the only authentication mode, and a single backslash (\) is specified for the Default domain.
11. Click OK.
12. Click OK.
13. For the Public node, repeat Steps 7-12​.

Make sure that the settings are identical in IIS:

1. Open the Internet Information Services (IIS) Manager.
2. Expand your server.
3. Expand the Web Sites node.
4. Expand the Default Web Site node (or website node that contains your Exchange virtual directories).
5. Right-click on Exchange in the navigation tree on the left, and select Properties.
6. Click the Directory Security tab.
7. Click the Edit button within Authentication and Access Control section.
8. Make sure Basic Authentication is selected as the only authentication mode, and a single backslash (\) is specified for the Default domain.
9. Click OK.
10. Click OK.
11. For the Public node, repeat Steps 5-10.

Make sure to back out any .config file so that you can easily go back to the previous state.

Exchange Server 2007

To configure the OWA authentication method:

1. Open the Exchange Management Console.
2. Expand the Server Configuration node.
3. Click the Client Access node.
4. Click the Outlook Web Access tab.
5. Right-click on OWA and select Properties.
6. Click the Authentication tab.
7. Select the authentication method to use.
8. Click OK.

To configure the WebDAV authentication method (make sure the authentication method is the same as OWA):

1. Open the Exchange Management Console.
2. Expand the Server Configuration node.
3. Click the Mailbox node.
4. Click the WebDAV tab.
5. Right-click on Exadmin and select Properties.
6. Click the Authentication tab.
7. Select the authentication method to use. If possible, we recommend only having Basic Authentication enabled.
8. Click OK.
9. Repeat Steps 5-8 for Exchange, Exchweb, and Public​.

Make sure that the settings are identical in IIS:

1. Open the Internet Information Services (IIS) Manager.
2. Expand your server.
3. Expand the Sites node.
4. Expand the Default Web Site node (or website node that contains your Exchange virtual directories).
5. Click Exadmin in the navigation tree on the left.
6. Double-click Authentication within the IIS section on the right.
7. Ensure the authentication settings match what you have configured above.
8. Repeat Steps 5-7 for Exchange, Exchweb, and Public.

Make sure to back out any .config file so that you can easily go back to the previous state.​

ISA

We are going to identify some of the common misconfigurations and issues when using Microsoft Internet Security and Acceleration (ISA) to protect an Exchange Server.  We find that many ISA servers that protect Exchange are not configured properly.

The first thing to understand is the authentication requirements for the various virtual directories that Exchange publishes.  Here are some good rules of thumb to follow:

1. If you access the virtual directory using your web browser, you can protect it any way you want to, i.e., ISA Forms Authentication, direct pass-through, Basic, etc.
2. If you do not access the virtual directory using your web browser, but rather it is accessed using a rich client such as Outlook or some third-party application (through web services), it cannot be protected with forms authentication. If you hit the URL and you see a forms-based authentication prompt, you’ve misconfigured it.

The second thing is how ISA works, and how it publishes Exchange. Most people run the Exchange publishing wizard that is provided by ISA once. However, the wizard needs to be run twice; once to publish all of the user-accessible pages that you access with your web browser and a second time to publish the web services. The following screenshot shows the publishing of the user-accessible pages on the first pass. Most people do this part correctly.

The ISA publishing wizard will now need to be run a second time to publish the web services as shown below:

​

This step is missed by more than half of the ISA servers that we have reviewed. Without this step, you cannot access your Exchange Server using Outlook Anywhere or any third-party applications that use web services such as EWS.

One major flaw of ISA is that both of these published rules require different web listeners (if you want to protect it using ISA Forms Authentication, which is the default setting). This is because we need two different authentication settings: 1) ISA Forms Authentication and 2) Non-ISA Forms Authentication. This in turn complicates your deployment, as the two different web listeners need different settings and cannot overlap. One or more of the following between the two web listeners must be changed:

1. IP Address
2. FQDN
3. Server Port

Two rules cannot be published with the same IP address, FQDN, and port, but different authentication settings. These can be manually changed, or you can take a simpler approach.

1. Do not enable ISA Forms Authentication.  Make the authentication a direct pass-through and allow the client to authenticate directly with the server.
2. Publish all of the Exchange virtual directories (client access and services) using the same rule.

​

This screenshot shows that we have disabled authentication on the web listener. You most likely have this set to be protected using ISA Forms Authentication (Front-End Back-End Authentication otherwise known as FBA).

Make sure to also include all of the services paths within the published Exchange rule. The published paths should look as follows:

​

The paths that will most likely be missing are:

1. /OAB/*
2. /EWS/*
3. /RPC/*
4. /AutoDiscover/*

There are many ways to publish these settings, but if you are not a firewall/Exchange/authentication expert, we suggest you pass the requests directly through to Exchange and allow it to handle them, rather than using FBA.

EWS

To verify EWS availability, it is best to perform these steps from a computer that is not joined to the domain and has access to the internet. 

1. Connect to your EWS URL
   example: https://mail.example.com/ews/exchange.asmx where mail.example.com is your domain name. 
2. Enter credentials when prompted.
3. After entering credentials, you should see an XML document (also known as a WSDL).

If you see an Outlook Web App (OWA) forms authentication page, the authentication method is incorrect. Make sure that the EWS virtual directory is protected, using either Basic Authentication and/or Windows Authentication. An OWA-protected EWS virtual directory is generally caused by an ISA firewall policy that was configured incorrectly. If you are using ISA, create a new firewall policy for EWS that leverages an authentication method other than Forms Authentication.

If Forms Authentication is turned on alongside Windows Authentication, you may get the following errors:

• The remote server returned an error: (404) Not Found
• 401 - Unauthorized: Access is denied due to invalid credentials

Disable Forms Authentication and retry. An IIS reset may also be needed if the settings do not refresh.

Impersonation & Delegation

Delegation

Please refer to the section that applies to the appropriate Destination. This article refers to the use of delegation to log in to individual user mailboxes using an "admin" account that has full access rights to each mailbox.

We strongly recommend using impersonation, rather than just delegation, when migrating to Office 365. However, when migrating to Exchange, rather than Office 365, either delegation or impersonation can be used. 

Office 365

Having administrative access to the Microsoft Office 365 control panel to manage users does not necessarily mean that the same account has permission to access all mailboxes for migration. 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 Office 365.

​Exchange 2007+

This is a two-step process:

1. Create an account with full access rights to each Exchange: How do I setup an Administrator account on Exchange
   

   Important

   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. This does not apply to Exchange Online (Office 365).

2. Disable throttling against this "administrator" account in order to speed up the migrations. The steps for this option are outlined below.

Impersonation Scopes

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, such as 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, 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 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.
4. 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 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 privilege. YourAdminAccountName

-CustomRecipientWriteScope is the name you assigned to the management scope you created YourManagementScope

Disable Throttling Policy

The Exchange Server has very low throttling policy limits. We recommend disabling the throttling limits during the migration.

• This is only relevant if throttling policies are enabled in the Exchange environment.
• Exchange Server 2007 does not have configuration options for throttling policies, as future versions do. For Exchange 2007's version of ​Client Throttling, see Understanding Client Throttling.
• Exchange 2003 does not have any throttling policies, or any client throttling.
• When migrating to Office 365, you cannot disable throttling on Office 365.
• If you are creating or applying a throttling policy on Exchange, you will need to use delegation for this endpoint.

Below we have lined out two options for how to complete this.

Option 1

Disable throttling against only the migrating account (if not using impersonation). This way, the admin account can migrate at a faster rate because it is not subjected to any throttling.

Use this option if not using impersonation during the migration, but instead using delegation.

If migrating using admin credentials, it is only necessary to disable throttling against the admin account, rather than all users.

If migrating mailboxes using administrative credentials at the Source, but not using impersonation, we recommend disabling throttling limits on this administrative account in order to improve the speed of migration.

We recommend the creation of a migration administrative account and disabling policy enforcement for this account.

Disable Admin throttling in Exchange Server 2010

To disable all throttling parameters for an admin account called "MigrationWiz":

1. On a computer that hosts the Microsoft Exchange Management Shell, open the Microsoft Exchange Management Shell.
2. Type the following command and press Enter.
   New-ThrottlingPolicy MigrationWizPolicy
3. 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
4. Type the following command and press Enter.
   Set-Mailbox "MigrationWiz" -ThrottlingPolicy MigrationWizPolicy

Exchange Server 2013 or 2016

To disable all throttling parameters for an admin account called "MigrationWiz":

1. Open the Exchange Management Shell.
2. Type the following command and press Enter.

   New-ThrottlingPolicy MigrationWizPolicy

3. Type the following command and press Enter.

   Set-ThrottlingPolicy MigrationWizPolicy -RCAMaxConcurrency Unlimited -EWSMaxConcurrency Unlimited -EWSMaxSubscriptions Unlimited -CPAMaxConcurrency Unlimited -EwsCutoffBalance Unlimited -EwsMaxBurst Unlimited -EwsRechargeRate Unlimited

4. Type the following command and press Enter.

   Set-Mailbox "MigrationWiz" -ThrottlingPolicy MigrationWizPolicy

Option 2

Disable throttling against all user accounts (if migrating using an admin account and impersonation). This way the admin account can migrate at a faster rate because it impersonates user accounts, which are not subjected to throttling.

If migrating mailboxes using administrative credentials at the Source, and using impersonation, disabling throttling limits on all mailboxes will improve the speed of migration, but it is a security risk. The throttling limits are working together to protect an Exchange server from being overwhelmed by accepting and delivering messages.

Read Understanding message rate limits and throttling before you execute the scripts below.

Exchange Server 2010

To disable all throttling parameters for all mailboxes:

1. On a computer that hosts the Microsoft Exchange Management Shell, open the Microsoft Exchange Management Shell.
2. Type the following command and press Enter.
   New-ThrottlingPolicy MigrationWizPolicy
3. 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
4. Type the following command and press Enter.
   Get-Mailbox | Set-Mailbox -ThrottlingPolicy MigrationWizPolicy

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 migrations 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 Impersonation and Delegation to enable this.

Exchange Server 2013 or 2016

To disable all throttling parameters for all mailboxes:

1. Open the Exchange Management Shell.
2. Type the following command and press Enter.

   New-ThrottlingPolicy MigrationWizPolicy

3. Type the following command and press Enter.

   Set-ThrottlingPolicy MigrationWizPolicy -RCAMaxConcurrency Unlimited -EWSMaxConcurrency Unlimited -EWSMaxSubscriptions Unlimited -CPAMaxConcurrency Unlimited -EwsCutoffBalance Unlimited -EwsMaxBurst Unlimited -EwsRechargeRate Unlimited

4. Enter the following command and press Enter. 

   Get-Mailbox | Set-Mailbox -ThrottlingPolicy MigrationWizPolicy

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 migrations use the bandwidth available to the individual user accounts, rather than just the bandwidth available to the admin account. 

Setting up Router Ports for OWA Traffic in On-Premises Exchange Migrations

If you have multiple ports on your router:
Set different OWA URLS for each environment. Let’s say SBS Exchange 2003 server has OWA = owa.Sourcedomain.com and Exchange 2013 server has OWA = webmail.Destinationdomain.com

• The first router port would be configured with IP address 1, and accept inbound/outbound mail traffic for http://owa.Sourcedomain.com:443/owa
• The second router port would be configured with IP address 2, and accept inbound/outbound mail traffic on http://webmail.Destinationdomain.com:443/owa

If you have just one port on your router, as is the case with some small companies, then you’ll need to either set up port translation and port redirection to handle the traffic routing. For example, you could add port 4443 to accept traffic for webmail.Destinationdomain.com and leave port 443 to accept traffic for owa.Sourcedomain.com.

• Port translation would need to be configured on the router so that incoming traffic on port 4443 would then be translated to port 443.
• Port redirection would need to be configured on the router so that after translation this traffic would then be redirected (using port redirection) to the new (Destination) Exchange 2013 server.
• For traffic coming into port 443 there is no port translation. It is just redirected to the old Exchange 2003 (Source) server.

What credentials are needed to migrate from Hosted Exchange?

You have two options. 

Option 1

Get the hosted provider to create an account for migration purposes (e.g., named MigrationWiz) and grant full access rights to each mailbox. You will then use this account as the admin account when performing your migration.

Step 1

Create an account for migration with full access rights to all mailboxes.

• If the Hosted Exchange provider is on Exchange 2007, 2010, 2013, or 2016, ask the provider to create an account for migration (e.g., called MigrationWiz) and then run this PowerShell script against the account called MigrationWiz:

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

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 the preferred method would be for the Hosted Exchange provider to run the above PowerShell script, particularly if you have a large number of users.

Step 2

Lower the number of concurrent migrations.

From the MigrationWiz user dashboard:

1. Click on Edit Project.
2. Click on Advanced Options.
3. Under the Performance section, change the Maximum concurrent migrations value to a lower number. We recommend beginning with a value of 20. You can always increase this number, and extra items will be added to your migration batch 'on the fly'. Note: If you decrease the value when migrations have already been submitted, the number of concurrent migrations will not be reduced until the active migrations have completed.

Option 2

Create a project without admin credentials, and request credentials from users.

1. Create a MigrationWiz mailbox migration project. When entering the Source information, do not click on the checkbox to enter admin credentials.
2. Click on the green bar Bulk Add.
3. Click on the checkbox I don't know the login name and password for the Source mailboxes.
4. Click the Upload bar.
5. Click the Choose File button, and select and upload your CSV file that contains the list of mailbox names.
6. Click Save.

When you submit the mailbox for migration, we will send an email with a secure link in which allows the end user to provide their credentials directly to the system. The sequence of steps are as follows:

1. The item is submitted for migration.
2. An email is sent to the email address configured with a secure link to provide the credentials.
3. The end user clicks on the provided link, which opens a secure web page.
4. The end user provides their credentials directly to our system.
5. The credentials are verified.
6. The item is immediately submitted for migration.

The status of the migration will remain as "Waiting For End User" until they provide their credentials to the system.

Setting up forwards for coexistence during a phased migration

If you aren't cutting over an entire domain/organization at once by changing the MX records, you can perform a phased migration and set up coexistence by setting up forwards on the mailboxes you wish to migrate. This can be done either through the use of PowerShell scripts, or through your Exchange Management Console.

We do not recommend setting up Exchange email contacts and a DNS Internal Relay for this, since this will not allow for any Delta Migration passes to be made afterwards because the mailbox no longer exists.

By PowerShell

To set up forwards using PowerShell, forward email to internal recipient and DON'T save local copy.

PowerShell command syntax:

Set-Mailbox -Identity <Identity> -ForwardingAddress <Office 365 User Email Address> -DeliverToMailboxAndForward $False

• Example: Set-Mailbox -Identity John -ForwardingAddress Suzan@o365info.com -DeliverToMailboxAndForward $False

Because you set DeliverToMailboxAndForward to false, a copy of the email will NOT be kept in the on-premises mailbox. When setting up forwards, make sure that you do NOT save a local copy before the forward. If you do save a local copy, then when you perform Delta passes, MigrationWiz will migrate the items that it previously hasn’t migrated and watermarked, which will cause duplicates at your Destination.

The email address specified on the 'ForwardingAddress' parameter should exist as a Mail Contact.

Through Exchange Management Console

The first step is to create the forwarding objects in your local Active Directory. These forwarding objects will be hidden from the address book and will be used purely to forward mail for mailboxes that are migrated. Note that these objects are created but not used until you set the forwarding, so these steps can be done ahead of time.

1. Download this script to a computer that is joined to the domain. A download link is also available at the bottom of this article.
2. Modify the script in a text editor (like Notepad) and change the forwarding domain in the top of the script to the temporary domain in the new environment, for example, company.onmicrosoft.com.
3. Run the script. You will know the script is complete when you see a confirmation.

The next step is to set up forwarding for mailboxes prior to migration. Before submitting a mailbox for migration, set the forward by performing the following:

1. Launch the Exchange Management Console from the Start Menu.
2. Expand the Recipient Configuration note from the navigation tree.
3. Click the Mailbox node from the navigation tree.
4. Right-click on the mailbox to set the forward for and click Properties.
5. Click the Mailbox Flow Settings tab.
6. Select Delivery Options and click Properties.
   •  Do not select the option "Deliver message to both forwarding address and mailbox". This is important to ensure that Delta passes do not cause duplicates. If you do save a local copy, then when you perform Delta passes, MigrationWiz will migrate the items that it previously hasn't migrated and watermarked, which will cause duplicates on your Destination.
7. Click the checkbox Forward to, then click Browse.
8. Select the name of the user that contains the prefix (External Forward) in the display name. This is the forwarding object created previously.
9. Click OK.
10. Click OK​.

​​Exchange 2003

Mail Forwarding

If you are migrating users in batches from Exchange 2003, it is important to set up mail forwarding for users already migrated to the new Destination when the MX records still point to the Source environment.

The VB script in the hyperlink below discovers all mailboxes within the Source domain and creates contact forwards for each one within a contact forwards Organizational Unit (OU).  

Note: The forward itself on the mailbox is not set. This only creates forwarding objects for coexistence.

Usage:

1. Download the VB script:  New-Exchange2003ContactForwards.zip​.
2. Modify script file and change the forwarding domain name.
3. Launch a command prompt.
4. Run the script on a computer that is joined to the domain in which you wish to​ discover.
5. Run the script on a computer in each domain that contains mailboxes.

This script will create contact forwards within a top-level OU of the referenced domain.

When migrating from WebCentral hosted Exchange 2003

1. Close all browser instances.
2. Open the WebCentral Control Panel in a new browser.
3. Select Desk Control/Webmail for the Portal.
4. Enter the email address and password of the mailbox you wish to migrate.
5. Click Login.
6. From the menu, click Messages -> Show Inbox -> High Bandwidth. You should now see the Inbox for the mailbox.
7. From the menu, click the New Mail icon ​.
8. In the To field, enter the name of name of the mailbox.
9. From the menu, click the Check Name icon  .
10. The name should now be resolved (it will be underlined in black).
11. Hover your mouse over the name; a tooltip should appear with an email address. This is the primary SMTP address of the mailbox.
12. Right-click on the name and click on Properties.
13. The properties of the mailbox should now be visible. Take note of the Alias. This is the user name of the mailbox.

Test the credentials discovered

1. Close all browser instances.
2. Open the WebCentral OWA URL which is either:
1. https://me-au.server-secure.com/exchange
2. ​https://legacy.server-secure.com/Exchange
3. Enter the user name discovered in Step 13 above.
4. Enter the password​ for the mailbox.
5. You should now see the Inbox for the mailbox.​

​Set Exchange msExchMailboxGUID Attribute to Null

This can be set within Synchronization Rules Editor

Notes:

• This is not supported if you have performed a directory synchronization using DirSync.
• It is supported if performing a directory synchronization using AAD Sync, or AAD Connect.
• For more details on the correct order of steps to follow for directory synchronization.

Instructions:

Run the Synchronization Rules Editor as an administrator.

 

Click In from AD – User Exchange to edit the Inbound Rule Type.

 

Select Transformations. Find the msExchMailboxGuid attribute.

Change it to the following:

Expression - msExchMailboxGuid - NULL - Checkmark Apply Once - Click Update. 

 

 

Enable AADSync or AAD Connect and perform a full synchronization.

Now users may be assigned an Exchange Online license, and MigrationWiz may be used to migrate their mailboxes to Office 365.

Archive Migrations

A note on root migrations

Exchange migrations do not migrate from the root, as EWS only sees and migrates items contained in folders. To migrate items at the root, create a folder for these items, drag and drop the items into the folder, and then migrate as usual. 

Mailbox and archive migration options

1. Perform a standard mailbox to mailbox migration
   This is considered a mailbox migration project. Leave the Advanced Options at their default options, i.e., "migrate to mailbox" for Source and "migrate to mailbox" for Destination. When migrating, you specify the Source and the Destination mailboxes.
   Once migration is complete, you could set Office 365 archiving rules so that mail will be moved to the archive mailbox, but that will all occur post-migration.
2. Perform a mailbox to archive migration
   We support migrating directly to an archive mailbox. In this case, you would enter Advanced Options for your project and select archives as the Destination, as in screen shot below. You would then save these settings and run your migration following normal procedure.
   This would still be considered a mailbox migration. Therefore you would create a mailbox migration project and purchase mailbox migration licenses or User Migration Bundle licenses.
3. Perform an in-place archive to mailbox migration
   In this case, when you create a project, you choose an in-place archive migration project. Leave the Advanced Options at their default destination setting, "migrate to mailbox". This requires User Migration Bundle licenses.
4. Perform an archive to archive migration
   This is also considered an archive migration project. In this case, you would change the Advanced Option for Destination to be "Migrate to: Archive." This requires archive licenses, rather than mailbox migration licenses.