Exchange Mailbox Migrations FAQ

 

Set Up

How do I ensure the reference UTC/GMT time zone is defined on my Exchange server?

Import the attached registry file to ensure the reference UTC/GMT time zone is defined on your client access Exchange Server(s):

  1. Download the attached file and save to disk.
  2. Double-click on the file and import into the registry.
  3. Execute iisreset (restarts IIS, allowing Exchange Web Services to detect the new time zone)​​.

Related Downloads:​

UTC.reg​​

964 Bytes Download

964 Bytes Download

 

Will MigrationWiz trigger mailbox database journal rules?

Exchange journaling inspects all messages that pass through the Hub transport. If a message matches the criteria specified in journaling rules, a journal report is created and delivered to the journaling mailbox.

Journaling rules defined at the Destination will not be triggered when migrating mailbox data via Exchange Web Services (EWS), therefore it is not necessary to disable journaling during migration.

 

Scenarios

How do I migrate from Exchange (old version) to Exchange (new version)?

MigrationWiz supports migrations from a previous version of Exchange (for example, Exchange 2003) to  a more recent one (like Exchange 2010, 2013, or  2016), without the need for a staging server. With MigrationWiz, you can migrate directly from Exchange 2003 to Exchange 2016.

  1. For each Source user (e.g., JohnDoe), create a new Destination dummy user account (e.g., TempJohnDoe) and user-disable it.
  2. Mailbox-enable the Destination dummy user account (assign it an unused email address such as TempJohnDoe@company.com).
  3. Perform your migration (migrating from mailbox JohnDoe@company.com to mailbox TempJohnDoe@company.com).
  4. Mailbox-disable the Source user account (this will detach the user from the source mailbox).
  5. Grant the Source user (ex: JohnDoe) permission over mailbox TempJohnDoe@company.com.
  6. Change the primary SMTP address to JohnDoe@company.com.

Note that the Destination dummy user account is only required because the Destination mailbox must be associated with a user. User-disabling the Destination dummy user account ensures no one can log in to the account.​

Litigation Hold Migrations

We do support Litigation Hold migrations, but with some important known limitations.

​Be aware of these limitations since, for obvious reasons, Litigation Hold tends to have a 100% fidelity requirement. ​

All emails in the primary mailbox will indeed be migrated
Note:
 MigrationWiz is unable to migrate Litigation Hold data from the Archive Mailbox. If Litigation Hold data is in the Archive Mailbox, it must be moved to either the primary mailbox or the Recoverable Items.

Folders created in Litigation Hold are considered to be "email folders" but this is not necessarily the case. Therefore, all the special Litigation Hold items (whose type is not email) fail to migrate due to a known limitation in EWS (which is what MigrationWiz uses for migrations, when migrating from Exchange 2007+ as the source).

Several of these are considered to be email folders by EWS, even though they are not. Due to a bug in EWS, if you try to create a non-email item within those folders, it reports an error stating: "the item type does not match the folder type".

For example, if a contact is deleted, it will be stored in the /Purges folder. When we try to migrate this contact to the destination mailbox's /Purges folder, it reports an error.

Here are some known folders in the recoverable items mailbox:

  • Versions: If Litigation Hold (or for that matter, In-Place or single item recovery) is enabled, this subfolder contains the original and modified copies of the deleted items. Note: This folder is not visible to end users.
  • Purges: If either Litigation Hold (or single item recovery) is enabled, this subfolder contains all items that are hard-deleted. Note: This folder is not visible to end users.
  • Discovery Holds: If In-Place Hold is enabled, this subfolder contains all items that meet the hold query parameters and are hard-deleted.
  • Audits: If mailbox audit logging is enabled for a mailbox, this subfolder contains the audit log entries. Note:This folder is not migrated with MigrationWiz.
  • Calendar Logging: This subfolder contains calendar changes that occur within a mailbox. Note:This folder is not available to users.
  • Deletions: This subfolder contains all items deleted from the Deleted Items folder. (In Outlook, a user can soft-delete an item by pressing Shift+Delete.) This subfolder is exposed to users through the Recover Deleted Items feature in Outlook and Outlook on the web.

The folders indicated above will, by default, be migrated into a folder at the Destination, named "Deletions". Any mail items within these folders will be migrated. The non-email items will return an error in the MigrationWiz portal, but will not prevent the migration from completing. Typically there are only a few extra errors caused when performing Litigation Hold migrations (since most items in these folders are, in fact, email items) so the error count threshold will not need to be adjusted.

Note: The migration process includes a folder discovery, plus it attempts to retrieve items from within each folder. If the attempts fail, this folder will be excluded during the migration, so that the migration can continue.

If you prefer to have the folders in the recoverable items mailbox migrated into their own corresponding folders at the Destination, and not migrated into a folder named "Deletions", you must add the Advanced Option (under the support section): OverrideRecoverableItemsFolderMapping="^SourceFolder->DestinationFolder" to your project before performing your migration. 

Examples below:

OverrideRecoverableItemsFolderMapping="^Audits->Audits"

The above will migrate the Audits folder into a folder named Audits at the Destination. As explained above, without this folder mapping, the Audits folder would be migrated into the Deletions folder.

OverrideRecoverableItemsFolderMapping="^Purges->Versions"

The above will migrate the Purges folder into a folder named Versions at the Destination. As explained above, without this folder mapping, the Purges folder would be migrated into the Deletions folder.

Here are the recommended step-by-step directions for performing a migration that includes mailboxes set for Litigation Hold:

  • Create a regular mailbox migration project, set the advanced options and submit mailboxes for migration. Follow directions under the migration guide for the appropriate scenario. All migration guides can be found in the MigrationWiz category of the BitTitan Help Center.
  • Once the mailbox migrations have completed, create a new mailbox migration project specifically for Litigation Hold.
  • Set the project advanced options for this Litigation Hold project, so that the Source: Migrate from:parameter is set to Recoverable Items, as per the screenshot below.

    Note: This will automatically set the Destination: Migrate to: parameter to be set to Recoverable Items.
  • Return to the regular mailbox migration project dashboard, select completed migrated items, and move these items to the Litigation Hold project. 
  • Now, from the Litigation Hold project, submit items for migration. These will then migrate all items under the recoverable items folder at the source into the recoverable items folder at the destination.
  • Once complete, move items back to the regular mailbox migration project.

Notes:

  • All emails will be migrated.
  • Users will not be able to see anything that they should not be able to see.
  • Mailbox migrations allow up to 10 passes per mailbox. Therefore, migrating mailboxes under the Litigation Hold project will not consume any additional licenses, provided that the items were moved between projects.
  • Do not add new mailboxes under the Litigation Hold project. Instead, move items into this project. This way all project statistics and license history will be retained.​
  • When migrating to recoverable options, it is recommended to increase the retention period for deleted items folder. The default retention period is 14 days. This should be increased to the maximum, which is 30 days. Steps for this are included in this TechNet article: https://technet.microsoft.com/en-us/library/dn163584(v=exchg.150).asp

 

​​​​​​​​Do you support migrations from Exchange archive mailboxes?​

Yes. This is considered a personal archive migration project.

Note: Archive migrations are supported only from Exchange 2010 SP1 and later.​

 

Throttling & Limit Increase

Folder Name Conversion

During migration, MigrationWiz will convert any instances of a forward slash  "/"  in an Outlook folder name to an underscore  "_".  This requirement was designed to overcome the limitations of the underlying migration protocols being used, e.g., Exchange Web Services (EWS) for migrations from Exchange 2007+  servers.  Note: The most common occurrence of this conversion is folder names containing dates with "/".

 

How does the folder size impact migration speeds on export?​

Please refer to the appropriate version of your software below:

Exchange 2003:

Exchange 2003 data export speeds may be degraded when enumerating folders that exceed the Microsoft recommended guidelines. As described by the TechNet article Understanding the Performance Impact of High Item Counts and Restricted Views, Microsoft states "with Exchange Server 2003, the recommended maximum item count per folder was 5,000 items."

Note that enumeration is only slow for the folders that exceed the maximum item count guidelines, and does not affect folders that are smaller than these recommended sizes.​

The only workarounds for the large folder issue are:

  1. Filter unnecessary large folders.
  2. Split the large folders into smaller ones (less than 5,000 items). For example, they might be structured this way:

/LargeFolder <- keep 2013 content

/SubFolder ​2012

/SubFolder 2011

​Etc.

Exchange 2007+ & Office 365

Exchange 2007 data export speeds may be degraded when enumerating folders that exceed the Microsoft recommended guidelines.

As described by the TechNet article Understanding the Performance Impact of High Item Counts and Restricted Views, Microsoft states "in Exchange 2007, improvements in I/O, larger page size, and increased cache can help enable an increase in the recommended maximum item count. With properly architected hardware, an acceptable user experience can still be maintained with item counts as high as 20,000 items."

Note that enumeration is only slow for the folders that exceed the maximum item count guidelines, and does not affect folders that are smaller than these recommended sizes.

The only workarounds for the large folder issue are:

  1. Filter unnecessary large folders.
  2. Split the large folders into smaller ones (less than 20,000 items). For example, they might be structured this way:

/LargeFolder <- keep 2013 content

/SubFolder 2012

/SubFolder 2011

Etc.​​​

 

 

How do I increase the message size limits for Exchange?​

Note: This article is relevant for Exchange 2007+ only

This is a two-step process. If the message size limits of Exchange are increased, the IIS limits will also have to be increased to allow increased payloads.

Therefore, this Knowledge Base article is broken into two parts:

  • Increase the message size limits of Exchange.
  • Increase IIS limits to allow accepting payloads.​​

Increase the Message Size Limits of Exchange

To display current message size limits:​

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

Get-TransportConfig | Format-List -Property MaxReceiveSize, MaxSendSize
Get-SendConnector | Format-List -Property Identity, MaxMessageSize
Get-ReceiveConnector | Format-List -Property Identity, MaxMessageSize
Get-MailBox | Format-List -Property PrimarySmtpAddress, MaxSendSize, MaxReceiveSize

To increase message size limits on the Exchange Server:​

  1. Open the Exchange Management Shell.
  2. ​Enter the following commands:​

​Set-TransportConfig -MaxReceiveSize 150MB -MaxSendSize 150MB
Get-SendConnector | Set-SendConnector -MaxMessageSize 150MB
Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 150MB
Get-Mailbox | Set-Mailbox -MaxSendSize 150MB -MaxReceiveSize 150MB

 

Increase IIS Limits to Allow Accepting Payloads

Note: There are three limits that should be increased in IIS:

  • maxRequestLength
  • maxAllowedContentLength
  • maxReceivedMessageSize

Follow these steps to increase the Exchange message size limits on your client access server:

  1. OpenWindows Explorer.
  2. Navigate to %ExchangeInstallPath%FrontEnd\HttpProxy\ews\
  3. Open the file Configin a text editor, such as Notepad.
  4. Find the XML tag starting with for each change.
  5. Change the existing value to maxRequestLength="200000"​ -- this occurs in one place in the Web.Config file.
  6. Change the existing values to maxAllowedContentLength="200000000"​ -- this occurs one place in the Web.Config file.
  7. Change the existing values to maxReceivedMessageSize="200000000"-- this entry occurs up to 12 times. This needs to be changed for each Authentication method.
    For example:
    <httpsTransport maxReceivedMessageSize="200000000" authenticationScheme="Anonymous" maxBufferSize="81920" transferMode="Streamed" />
    <httpsTransport maxReceivedMessageSize="200000000" authenticationScheme="Basic" maxBufferSize="81920" transferMode="Streamed" />
  8. If you are running IIS7 and Windows 2008, it may be necessary to increase WCF settings.
  9. Save the file.
  10. IIS Reset is not needed, web.config changes are picked up by the next conne​ction.

​​Follow these steps to increase the Exchange message size limits on your mailbox server:

  1. OpenWindows Explorer.
  2. Navigate to %ExchangeInstallPath%ClientAccess\exchweb\ews\
  3. Open the file Configin a text editor, such as Notepad.
  4. Find the XML tag starting with for each change.
  5. Change the existing value to maxRequestLength="200000"​ -- this occurs in one place in the Web.Config file.
  6. Change the existing values to maxAllowedContentLength="200000000"​ -- this occurs one place in the Web.Config file.
  7. Change the existing values to maxReceivedMessageSize="200000000"-- this entry occurs up to 12 times. This needs to be changed for each Authentication method.
  8. If you are running IIS7 and Windows 2008, it may be necessary to increase WCF settings.
  9. Save the file.
  10. IIS Reset is not needed, web.config changes are picked up by the next conne​ction.

 

How do I increase the maximum received message size?​

If you are running IIS7 and Windows 2008, you may need to increase WCF settings:

  1. Open Windows Explorer.
  2. Navigate to C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews
  3. Open the file Config in a text editor like Notepad.
  4. Find all XML tags starting with maxReceivedMessageSize=
  5. Change existing values to maxReceivedMessageSize="104857600"
  6. Save the file.
  7. Open a Command Prompt (cmd.exe).
  8. Type: cd %windir%\system32\inetsrv
  9. Type: exe set config "Default Web Site/ews" -section:requestFiltering -requestLimits.maxAllowedContentLength:104857600
  10. Run: iisreset

​​Note: a value of 104857600 represents 100 MB in bytes​.

 

How do I increase the maximum accepted request length?​

Exchange Server 2007 has a default maximum accepted request length of 13MB. You may increase the maximum accepted request length by performing the following:

  1. Open Windows Explorer.
  2. Navigate to C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews
  3. Open the file Configin a text editor such as Notepad.
  4. Find the XML tag starting with maxRequestLength=
  5. Change the existing value to maxRequestLength="102400"
  6. Save the file.

    Note:a value of 102400 represents 100 MBs in kilobytes.

Sample Web.Config before changes:

<configuration>
<system.web>
...
...
<httpRuntime maxRequestLength="13280" />
</system.web>
</configuration>

Sample Web.Config after changes:

<configuration>
<system.web>
...
...
<httpRuntime maxRequestLength="102400" />
</system.web>
</configuration>

How do I increase the maximum accepted content length?​

You may increase the maximum accepted content length by following these directions:

  1. Open Windows Explorer.
  2. Navigate to C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews
  3. Open the file Configin a text editor such as Notepad.
  4. Go to the end of the file.
  5. Insert or edit the following XML code before the </configuration> tag:

    <system.webServer>
    <security>
    <requestFiltering>
    <requestLimits maxAllowedContentLength="104857600" />
    </requestFiltering>
    </security>
    </system.webServer>

Note: If XML code is already present in the Web.Config file, edit it to match what is shown above.

Sample Web.Config before changes:

<configuration>
<system.web>
...
...
</system.web>
</configuration>

Sample Web.Config after changes:

<configuration>
<system.web>
...
...
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="104857600" />
</requestFiltering>
</security>
</system.webServer>
</configuration>

 

How do I increase the MAPI named property limits?​

Some Exchange servers that have been in commissi​on for years may hit MAPI named property limits. These limits are reached when we attempt to retrieve more properties than the server is configured for. You will know if your server reaches these limits as an event similar to the following is logged:

Event Type: Error

Event Source: MSExchangeIS

Event Category: General

Event ID: 9667

Date: 6/11/2010

Time: 4:56:13 PM

User: N/A

Computer: SERVERNAME

Description:

Failed to create a new named property for database "First Storage Group\Mailbox Store (SERVERNAME)" because the number of named properties reached the quota limit (8192).

User attempting to create the named property: "SYSTEM"

Named property GUID: 00062002-0000-0000-c000-000000000046

Named property name/id: "33377"

To increase the number of MAPI named properties:

  1. Start the Registry Editor on the mailbox server.
  2. Locate the following registry key:
    • HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\<Private-GUID>
  3. Set the following DWORD values or create new values if they do not exist.
    • NonMAPI Named Props Quota == 00007fff
    • Named Props Quota == 00007fff

You may either wait approximately 30 minutes for these values to take effect automatically, or reboot the server to take effect immediately.

  

​​​How do I increase the allowed number of concurrent connections per user?​

To display current allowed number of concurrent connections per user:

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

    Get-ThrottlingPolicy | Format-List -Property Identity, EWSMaxConcurrency

To increase allowed number of concurrent connections per user on your Exchange Server 2010 machine:

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

    Set-ThrottlingPolicy -Identity DefaultThrottlingPolicy* -EWSMaxConcurrency $null

 

How do I disable the throttling policy on Exchange?

 

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

Notes:

  • 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 the Microsoft TechNet article, 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.

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.

Notes:

  • 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 accountand disabling policy enforcement for this account.

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

  1. Type the following command and press Enter:

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

  1. 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 using impersonation). This way the admin account can migrate at a faster rate because it impersonates user accounts, which are not subjected to throttling.

Notes:

  • 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 carefully through Microsoft Technet article 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

Note: 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 How do I migrate to Exchange or Office 365 using impersonation? 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

  1. Type the following command and press Enter:

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

  1. Enter the following command and press Enter:

Get-Mailbox | Set-Mailbox -ThrottlingPolicy MigrationWizPolicy

Note: 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. 

 

Permissions & Credentials

How do I migrate from Exchange IMAP with administrative credentials?

Some Exchange IMAP systems support administrative login.

To use this feature:

  1. On each mailbox, specify the user name as follows:
    • domain\adminUserName\mailboxUserName
  2. On each mailbox, specify the administrator's password.

Examples:

Here are some examples of user names you would specify on each mailbox (depending on your configuration):

  1. com\admin\user1
  2. domain\admin\user1
  3. domain\admin@company.com\user@company.com

 

How can I verify mailbox accessibility using EWS​?​

You can verify independently whether a mailbox is accessible using EWS by performing these steps:

  1. Browse to https://testconnectivity.microsoft.com. This is a Microsoft-owned tool.
  2. If using Office 365, click on the Office 365
  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 notcheck 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.

It may be necessary to first grant permissions.

 

How do I export from Exchange 2007 using WebDAV rather than EWS​?

By default, when Exchange 2007 is the Source server, we will export the data using EWS.​

NOTE: Once a mailbox has begun a migration, you will not be able to switch from one to the other. The system will prevent you from doing this by failing on submission. The reason is that we cannot detect duplicates between the two methods. Switching will require the removal of previously-migrated data first. The following options need to be set prior to migration:

​​To force all mailboxes within a connector to use WebDAV:

  1. Sign in to your MigrationWiz account.
  2. Click on Dashboard.
  3. In the Mailbox Migration section, click on Perform mailbox migration.
  4. Select your Mailbox Connector.
  5. From the Task menu, click on Edit connector.
  6. Click on the link Show Advanced Options.
  7. For the field Support Only Options enter MustUseWebDav=1.​

If you switched the export method after a migration has begun, your migration will fail with an error stating so. If this is intentional, contact our Support team.

Note: Ensure that the Destination mailbox is cleaned up (or recreated) prior to switching, or the migration will result in duplicates.

 

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

Note: 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. Obviously, 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:

  • Click on Edit Project.
  • Click on Advanced Options.
  • Under the Performance section, change the Maximum concurrent migrationsvalue 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 notclick 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 on the Upload bar.
  5. Click on the Choose Filebutton, and select and upload your CSV file that contains the list of mailbox names.
  6. Click on the 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. You submit the item 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 the end user provides their credentials to the system.

 

How do I verify that EWS is set up properly?

To verify EWS availability, follow these steps:

  1. Connect to your EWS URL
    example: https://mail.example.com/ews/exchange.asmxwhere mail.example.com is your domain name.  It is best to perform this from a computer that is not joined to the domain and has access to the internet.
  2. Enter credentials when prompted.
  3. After entering credentials, you should see an XML document (also known as a WSDL).

Note:

If you see an Outlook Web App (OWA) forms authentication page, you have configured an incorrect authentication method.  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. You may need to do an IIS reset if the settings do not refresh.

 

How do I set up an administrator account on Exchange?

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
  3. Right-click on the Mailbox
  4. Click on New Mailbox.
  5. Click on Next.
  6. Click on 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 on Next.
  11. Click on Browseto select a Mailbox database.
  12. Click on Next.
  13. Click on New.
  14. Click on 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

Notes:

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

 

How do I publish Exchange properly through 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 you need to understand are 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 you need to understand is how ISA works, and how it publishes Exchange.  Most people run the Exchange publishing wizard that is provided by ISA.  What people do not realize is that 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 screen shot shows the publishing of the user accessible pages that you access using your web browser.  Most people do this part correctly.

You will then need to run the ISA publishing wizard 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 needs different settings and cannot overlap.  You need to change one or more of the following between the two web listeners:

  1. IP Address
  2. FQDN
  3. Server Port

You cannot publish the two rules with the same IP address, FQDN, and port and yet have different authentication settings.  If this sounds too complicated for you, we suggest 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.

Disable 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 you also include all of the services paths within the published Exchange rule.  ​

The paths you 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 simply pass the requests directly through to Exchange and allow it to handle the requests for you, rather than using FBA.

 

How do I enable full access permissions on an Exchange Account for Intermedia Hosted Exchange?​ 

  1. Navigate to Control Panel at https://controlpanel.msoutlookonline.net and log in using your administrator account.
  2. Navigate to Services, and click on Exchange Mailbox.
  3. Click on the display name for the mailbox that you want to grant full access permissions.
  4. Click on Exchange. In the Mailbox access area, click on the Full access & Send as link.
  5. In the new window, enter the administrator name you want to use for migration, and click on the Check Name button to check the name. You can also select the name from address book. 
  6. Click on Add to add the administrator account
  7. Select Full Access and then, in the Access Allowed for window, click on Save Changes. 

Note: The step-by-step process above is a general guideline, and is subject to change.  If you encounter issues with granting full access permissions, contact Intermedia for assistances.

 

How do I enable cross-tenant EWS access?

Migration of mailboxes using administrative credentials to ​Exchange Server 2010 deployed in multi-tenant mode may fail with the error "The SMTP address has no mailbox associated with it" because the admin account is unable to look up the mailbox.

In order to migrate with a single set of administrative credentials within an Exchange 2010 multi-tenant environment, create a new management role granting access.

To grant access to an administrative migration account called "MigrationWiz":

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

    New-ManagementScope -PartnerDelegatedTenantRestrictionFilter {Name -eq '*'} -Name MigrationWizScope
    New-ManagementRole -Parent PartnerDelegatedTenantManagement -Name MigrationWizRole
    New-ManagementRoleAssignment -Role MigrationWizRole -User MigrationWiz -CustomConfigWriteScope MigrationWizScope

 

How do I 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 Servers
  3. Expand the server 
  4. Expand theProtocols 
  5. Expand theHTTP 
  6. Expand the Exchange Virtual Server 
  7. Right-click on the Exchange node and select Properties.
  8. Click on the Access
  9. Click on the Authentication
  10. Make sure Basic Authentication is selected as the only authentication mode, and a single backslash (\) is specified for the Default domain.
  11. Click on OK.
  12. Clickon OK.
  13. For the Publicnode, 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 
  4. Expand the Default Web Sitenode (or website node that contains your Exchange virtual directories).
  5. Right-click on Exchangein the navigation tree on the left, and select Properties.
  6. Click the Directory Security 
  7. Click the Edit button within Authentication and access control 
  8. Make sure Basic Authentication is selected as the only authentication mode, and a single backslash (\) is specified for the Default domain.
  9. Click on OK.
  10. Click on 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 theExchange Management Console.
  2. Expand the Server Configuration 
  3. Click the Client Access 
  4. Click the Outlook Web Access 
  5. Right-click on OWAand select Properties.
  6. Click the Authentication
  7. Select the authentication method to use.
  8. Click on 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 
  3. Click on the Mailbox 
  4. Click on the WebDAV
  5. Right-click on Exadminand select Properties.
  6. Click on the Authentication
  7. Select the authentication method to use. If possible, we recommend only having Basic Authentication enabled.
  8. Click on OK.
  9. Repeat Steps 5-8 for ExchangeExchweband 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 
  4. Expand the Default Web Site node (or website node that contains your Exchange virtual directories).
  5. Click on Exadminin the navigation tree on the left.
  6. Double-click onAuthentication within the IIS section on the right.
  7. Ensure the authenticaiton settings match what you have configured above.
  8. Repeat Steps 5-7 for ExchangeExchweband 

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

​​VB script that 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.

Usage:

  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.

Related Downloads:

Check-Exchange2003UserPrincipalNameAndEmailAddress.zip

988 Bytes Download

988 Bytes Download

 

OWA

How do I verify if my Outlook Web Access (OWA) URL is correct?​

When setting up Exchange as an endpoint, enter either the OWA URL or the EWS URL.

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:

  1. Close all browser instances. This ensures that all session state browser cache is flushed.
  2. Open a new browser instance.
  3. Navigate to your OWA login page.
  4. Log in to OWA.
  5. 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​.

Note: 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.​,:
    • Email addressmeans "user@example.com" format.
    • Domain\user namemeans "example\user" format.
    • User namemeans "user" format.
  5. Once you see the inbox, you have successfully logged into OWA.  Enter the exact same username and password used into MigrationWiz.

 

How do I set up router ports for OWA traffic when performing an On-Premises Exchange to On-Premises Exchange migration?

If you have multiple ports on your router, this is a non-issue.
Set it up like this:
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

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, say, 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.

 

Delegation & Impersonation

Impersonation

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 Distribution Group
  2. Create a Management Scope
  3. Create the Management Role Assignment

Note: 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 Distribution 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 Group and name it in a recognizable fashion.
  3. Add to the new Group all of the user mailbox accounts that you intend to migrate.

Note: 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

 

How do I migrate to Office 365 or Exchange 2007+using 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.

Note: 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. Refer to KB005004 for more information on this decision, and the exact steps to set these up.

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

To automatically create an administrative account and grant administrative access for the migration, download our script to provision an administrative account for migration on Microsoft Office 365.

Notes:

  • 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 user by following the directions in KB004725,​for your version of 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. Note: This does not apply to Exchange Online (Office 365).
  2. Disable throttling against this "administrator" account in order to speed up the migrations. 

 

Migrated Items

Calendar event times are incorrect

Under some circumstances, mailbox migrations to an Exchange environment will show the incorrect time for calendar events. This happens when the time zone on the Destination is incorrect. The cause of involves synchronization of time values when calendar items migrate.

To ensure that this error does not affect your migrations, ensure you have set the correct time zone at the migration Destinations.

When migrating from WebCentral hosted Exchange 2003:

  1. Close all browser instances.
  2. Open the WebCentral Control Panelin 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 on Login.
  6. From the menu, click on Messages -> Show Inbox -> High Bandwidth. You should now see the Inbox for the mailbox.
  7. From the menu, click on the New Mail icon ​.
  8. In the To field, enter the name of name of the mailbox.
  9. From the menu, click on 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.​

 

How do I migrate Exchange or Office 365 resources to Exchange or Office 365? 

Note: The information in this article is specific to the Source as Exchange or Office 365, and the Destination as Exchange or Office 365.

We handle resource mailboxes the same way that we handle regular user mailboxes.

If you can log in to the resource mailbox using a web client (i.e., Outlook Web Access), we should be able to log in as well, and migrate the data. If there is no way to log in to the resource mailbox using a web client (like OWA), then we also cannot log in and migrate the data.

In some cases, the resource mailbox is just a shared calendar that is owned by a user. For those cases, when the user's mailbox is migrated, we should be able to migrate the resource mailbox calendar as one of the user's calendars. Once the migration is complete, you could set sharing/permissions on the calendar so that it can be accessed by other users.​​​

How do I migrate calendars in Exchange 2003?

When migrating from Exchange to Google, we currently only support migration of calendars and contacts if the Source is Exchange Server 2007 or later, and Exchange Web Services (EWS) can be accessed.

Resolution:

  • If the Source is Exchange 2003: disable calendars and contacts on in your project.
  • If the Source is Exchange 2007 or later: verify EWS access.​

 

Are Distribution Lists migrated?

  • Server-based Distribution Lists are not migrated with MigrationWiz since MigrationWiz does not include Distribution List discovery.
  • Personal Distribution Lists are not migrated by MigrationWiz.

Notes:

  • When referring to Distribution Lists, there is an important distinction between server-based Distribution Lists and personal Distribution Lists. Server-based Distribution Lists appear in the Global Address List, while Personal Distribution Lists are stored locally.
  • Personal Distribution Lists are now called Contact Groups in Office 365.

If you have server-based Distribution Lists, your options include the following:

  • Use Microsoft (e.g., AAD Sync or AAD Connect) to synchronize the Distribution Lists between your Source environment and your Destination environment. For more information on the processes to follow when using Microsoft synchronization tools in conjunction with MigrationWiz, refer to KB004336.
  • Create your own PowerShell scripts to export and import these. Examples from Microsoft can be found here.
  • Manually recreate the Distribution Lists at the Destination.

Notes:

  • If migrating from Hosted Exchange, ask the Hosted Exchange provider to export the Distribution Lists to a CSV file, and then import them into Office 365, based on the information in the CSV file.
  • Other Source systems will not have (Exchange) Distribution Lists. Partners should create Distribution Lists post-migration, and then add the necessary users into the Distribution Lists, based on the membership of equivalent groups/Distribution Lists from the Source. 
  • After performing a mail-only mailbox migration, you may notice that some folders are of a different folder type (i.e., mail folder instead of calendar folder) in the Destination, and that some items may be missing. This happens when mail folders contain non-mail subfolders, such as calendar or contact subfolders.
  • In the example screenshot below, Folder 1 is a mail folder, and Folder 2 (a subfolder of Folder 1) is a calendar folder in the Source environment. If you perform a mail-only mailbox migration, then Folder 1 and its subfolders are migrated. However, Folder 2 is converted to a mail folder in the Destination and calendar items saved within that folder are missing post-migration.
  • To circumvent this issue, we recommend that you direct users to separate folders of different types and move non-mail folders to the root. If separating folder types is not possible, we recommend that you perform a full migration of all mailbox item types (mail, calendar, contacts, etc.).
  • This issue can also occur when using the folder mapping support option to map the contents of a Source mailbox into a single folder on the Destination. Read the Can I migrate a Source mailbox into a single subfolder of a Destination mailbox?article for more information about how to circumvent this issue.

 

Is calendar response status migrated with MigrationWiz?​

If the Source and Destination are Exchange 2007+, MigrationWiz will attempt to migrate the attendee response status associated with calendar items. Due to a limitation found in some versions of EWS, attendee response status may not be migrated.

 

​What rules and permissions will be migrated during a Microsoft Exchange mail migration?

Rules and permissions can only be migrated from Exchange Server 2010+ (or Office 365). This is due to API limitations in earlier versions of Exchange.

Additionally, your migration Destination must be Exchange Server 2010+ (or Office 365).

Note: Rules will appear as an option when the Source is set to Exchange 2003+, but can only actually be migrated from Source servers that are Exchange Server 2010 and later, running SP1+. The reason for this slightly confusing User Interface setting is that we have bundled all Exchange Server versions into the one Source option: Exchange 2003+. This is to simplify choosing your Source environment within our UI.

Specifically, for Exchange server 2010+, running SP1+, here is how rules and permissions are handled:

Rules:

  • We migrate server-side rules. We do not migrate client-side rules.

Folder permissions:

  • We migrate folder permissions but not delegate/sharing permissions, which means that "Send As" and "Send On Behalf Of" permissions are not migrated.
  • Folder permissions are those permissions that are granted at each individual folder level within a mailbox. These can be set from within a mailbox, by right-clicking on the folder, selecting Properties, clicking on the Permissions tab, and defining the Permissions there.
  • Delegate permissions are set from Tools/Options/Delegates. These are not migrated, and so will need to be reset, post-migration.

 

​​Why am I not the owner of my calendar events after migration?

MigrationWiz looks at the Source email address to know who the owner of an event is. If your calendar events are being migrated, but you are not being shown as the owner of the event, confirm that the Source email address matches the email address of the creator of the event at the Source.

 

Why are BCC recipients not migrated from older versions of Exchange?​

We cannot migrate BCC recipients from older versions of Exchange because the Microsoft Exchange Web DAV API does not return this information.

Read the Microsoft article on MSDN: http://blogs.msdn.com/b/webdav_101/archive/2008/04/24/why-can-t-webdav-read-bcc.aspx

Note: Exchange Web DAV also stores the list of resources/optional attendees in the BCC field of appointments. Therefore the list of resources/ optional attendees cannot be migrated for appointments because the Exchange API does not return this information.  Refer to the following message:

 

Mail Forwarding

How do I set up mail forwarding from the Exchange 2003 Source?

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 Visual Basic (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.

 

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