My very fist Microsoft Exchange version was V4.0 and my first Exchange Migration was from V4.0 to Microsoft Exchange 2000. It was very painful and complicated migration. There was no migration documentation or something like this and no MVP blogposts on the internet. You could just relay on your experience and knowledge of other colleagues. We needed to change credentials from every mailbox, export all emails to PST, import all PST files to the new Exchange-Server and configure Outlook manually on every computer for every employee. Since then, I am continuously migrating mailboxes to the next version of Microsoft Exchange. Since 1996 mailbox migration has been improved, but still very complex. In this article I will try to deep dive into several migration scenarios and explain Microsoft Exchange On-Prem migration to Microsoft Online.
Migration principals
Before I will start with deep dive in to Exchange-Mail migration, I would like to explain some terms and give you a “Start-Up” information, so that you can understand this article in full color range.
What is mail migration?
Mail-Migration is not only migration of email objects from Source to Destination, but also a change of communication and collaboration infrastructure for your company and have a big impact on productivity and business continuity. Any kind of migration may have an impact on:
- Mailbox access
- Mailbox permissions
- Mailflow and mailrelay
- Calender availability
- Distributiongroup- and Securitygroupmembership
- Resource and Sharedmailbox / Functionionalmailbox access
- Addressbook access and membership
- Permission delegation and collaboration
- Email security, like antispam / antiphishing, antivirus and email encryption (conditional access)
So, if you are planning an email migration, think about above mentioned points and how to deal with it.
Which mail migration exists and which are covered in this article?
In this article I will explain only Exchange to Exchange migration. So, I will not explain any 3rd party to Exchange-Migration, because there are tons of tools on the market like QUEST which you can use for it.
Exchange to Exchange scenarios.
Following migration scenarios are covered in this article.
In scenario A we have one Exchange-Organization and one data center. All Exchange Servers are in the same data center. You need to move mailboxes from Exchange-Server B to Exchange-Server A.
In scenario B we have one Exchange-Organization in two data centers. You need to move mailboxes from Exchange-Servers located in data center 1 to Exchange-Servers located in data center 2.
In scenario C we have one Exchange-Organization in two data centers. We are using load-balancers for better quality of service.
It doesn’t matter how many load-balancers do you have in each data center, architecture is almost the same.
You need to move mailboxes from Exchange-Servers located in data center 1 to Exchange-Servers located in data center 2.
In scenario D we have two Exchange-Organizations and two data centers. We have two different forests and need to move mailboxes from one forest to another. This type of migration is called “Forest to Forest” migration and requires additional preparation of target and source forests. Check documentation of this feature here. We will focus only on mailbox moves and not on “Forrest to Forrest” deployment.
In scenario E we have one data center and one Exchange-Organization. We have an Exchange-Hybrid configuration (doesn’t matter if Centralized mailflow, Hybrid-mailflow, or HMA). We are using separate “Exchange-Hybrid” servers only for Client-Access / Hybrid-Configuration-Wizard and have separate “Maibox Servers” which are hosting mailbox-databases in a DAG or without.
All user objects are synchronized via Azure-AD-Sync to AzureAD.
Important: We have only 1 data center, all “Exchange to Exchange” connections are running in the same LAN. You need to move mailboxes from Exchange Mailbox-Servers to Exchange Online.
This is the most complicated scenario which is used in enterprise environment with more than one data center “multiple sites”. We have two data centers and one Exchange-Organization. DC1 is our “Headquarter” and DC2 is our “Branch office”. Between both DCs is a “WAN” connection like MPLs, or VPN tunnel. DC2 has no internet connection, the whole traffic is routed through DC1 via “WAN” link. We have an Exchange-Hybrid configuration (doesn’t matter if Centralized mailflow, Hybrid-mailflow, or HMA). In DC1 we have “Exchange-Hybrid” servers located only for Client-Access / Hybrid-Configuration-Wizard and in DC2 our “Maibox Servers” which are hosting mailbox-databases in a DAG or without.
All user objects are synchronized via Azure-AD-Sync to AzureAD. AzureAD sync is located in DC1. You need to move mailboxes from Exchange Mailbox-Servers over “WAN” connection to Exchange Online.
If you have a scenario which is totally different, as mentioned above, just let me know, I would really appreciate to get more ideas and increase the quality of this article.
MRS proxy
It is a part of Exchange-WebServices and is responsible for Mail-Box migrations. This service is based on EWS (Exchange Webservices) and is handled in the same way as all other EWS features like “HMA”. You can find MRS proxy documentation here.
Important: Exchange-Server is proxying MRS traffic internal via port 444 and only initial Moverequestis using 443. Client/Access Server and Mailbox / Source Server need to have the same External URL configured in EWS.
Network configuration
MRS traffic can be used internal and external.
- External traffic means: if destination server is in a different forest or belongs to Exchange-Online (scenario D,E and F). In this case following ports are required to be opened on your external FW in DC1.
Pot
I
Port | IP | Explanation |
443 | Destination-Server-IP | Inbound HTTPS |
443 | Client / Access Server | Outbound HTTPS |
443 | Mailbox / Source Server | Outbound HTTPS |
- Internal traffic: means if Client / Access Server and Mailbox / Source Server are in the same forest and can route all traffic using private IP ranges.
Microsoft recommends to open all ports for internal traffic between Exchange-Servers in your Exchange-Organization.
Following Windows-ports are listed in Microsoft Documentation
Inbound | Protocol |
Port 135 between all Exchange Servers | RPC |
Port 445 between all Exchange Servers | SMB |
Port 443 between all Exchange Servers | HTTPS |
Port 5985 between all Exchange Servers | WinRM |
Port 3389 (RDP optional) | RDP |
Port 443 from user lan | HTTPS |
Port 808 for remote move requests | |
Outbound | Protocol |
Port 53 to DC | DNS |
Port 389 to DC | LDAP |
Port 636 to DC | LDAP SSL |
Port 25 to Smart-Host | SMTP |
Port 443 between all Exchange Servers | HTTPS |
Port 444 between all Exchange Servers | HTTPS |
random port number between 1024 - 65535 | High ports |
random port number between 49152 – 65535 | High ports |
Port 808 for remote move requests | |
Authentication
During the migration, authentication flow is based on Source (forest) and destination (forest) credentials. Move requests are always created on Destination-Server and need to be monitored right there.
- Source credentials need to be able to connect to Exchange-Destination-Server and manage mailboxes (Recipient Manager)
- Destination credentials need to be able to connect to Exchange-Source-Server and manage mailboxes (Recipient Manager)
Logging
All log files are located in Microsoft Exchange-Server installation directory.
You can find EWS troubleshooting guide here.
HTTPProxy logs for EWS:
%ExchangeInstallPath%Logging\HttpProxy\Ews
Example: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Ews
The name of the HTTPProxy logs contains the date and hour starting to log, for example HttpProxy_2019093014-10.LOG (10th log from Sept 30, 2019, starting hour 14:00 UTC)
Migration batches
This feature is a part of Exchange-Online. It allows you to create single or bulk migrations without any PowerShell / Scripting knowhow. You can create, monitor and manage your mailbox migration simple from the “New” Exchange-Online-Admincenter.
Creation
You can find the function “Add Migration batch” directly in Migration hive.
You can migrate to Exchange-Online and from Exchange-Online to your On-Prem migration endpoint.
You can select following migration types.
Only “Remote move migration” is related to this article.
After you have selected the right migration-endpoint you can select User/s who should be migrated or provide a CSV file with a list of “EmailAddresses” of users.
You can find exact documentation how to use CSV files here.
Important: You don’t need any remote credentials for this task. Exchange-Admin center is using current configured credentials of your migration-endpoint. So, make sure that your MRS-Endpoint credentials are still valid.
For validation of current MRS-endpoint credentials use following command
Get-MigrationEndpoint | fl
Find documentation for this CMDlet here.
Monitoring
After you have created a migration batch you can use Migration-Report located in Monitoring hive. It will provide you a list of running batches and migration status in a PowerBi report.
Exact documentation you can find here.
Management
You can manage migration-batches and single user moves directly in the new Exchange-Admin-Center.
Exact documentation you can find here.
PowerShell
Additionally, to the New Exchange-Admin-Center you can handle all previous steps by using Exchange-Online-Powershell.
Important: You need to install ExchangeOnlineManagement powershell module to manage migration batches.
How to get migration batch information?
You can get migration batch information by running following command:
Get-MigrationBatch
For a specific migration-batch you can use “-identity” property
Get-MigrationBatch -Identity 'MigrationService:2ndWave'
How to get single mailbox migration status?
You can get single mailbox migration status by running following commands:
Get-MigrationBatch -Identity 'MigrationService:2ndWave' | Get-MigrationUser
This scriptline delivers a basic status for all single mailbox migrations in the batch.
Get-MigrationUser -BatchId 'MigrationService:2ndWave' | Get-MigrationUserStatistics
This scriptline delivers a full overview of all single mailbox migrations in the batch.
Here you can find all CMDlets related to move-and-migration.
Move-Requests
Exchange Moverequest is a feature in Microsoft Exchange Server that allows administrators to move mailboxes between Exchange servers or databases. It is commonly used during server maintenance, upgrades, or when consolidating resources.
The Moverequestcan be performed within the same Exchange organization or even across different Active Directory forests.
Moverequestis the main mechanism for transferring mailboxes from Source to Destination server.
Important: If you are migrating from Exchange-Onprem to Exchange-Online and you cannot use “migration-batches” feature, because of different reasons, you can create move-requests and order them in batches manually.
If you need additional information, read Microsoft Documentation.
Creation
You can create move-requests On-Prem in the same ways as in the Cloud.
Navigate ECP of your Exchange-Server or Exchange-Online ECP (https://outlook.office365.com/ecp/)
Navigate “recipients” hive and go to “migration”
Important: Navigate ECP on your Destination-Server and not on your Mailbox / Source-Server. In some cases, Move-Requests are visible only on Destination-Server.
I wrote a Create-MoveRequests function for bulk moverequest creation to speed up the process.
This is a sample call of this function.
Create-MoveRequests -batchname '2ndBatch'-userlistlocation 'C:\temp\userlist.txt' -completeafterdays '5'
Monitoring
If you want to see status of you moverequest just simply select one of your moverequests directly in ECP.
Important: If you create moverequests in Exchange-Online you can see them only by using PowerShell
You can export status of all move-requests with following commands
Get all moverequests:
Get-MoveRequest
Get all moverequests of a specific batch:
Get-MoveRequest-BatchName '2ndbatch'
Get extended moverequests information of a specific batch:
Get-MoveRequest-BatchName '2ndbatch'| Get-MoveRequestStatistics
Export extended moverequests information of a specific batch to a CSV file:
Get-MoveRequest-BatchName '2ndbatch'| Get-MoveRequestStatistics | ConvertTo-Csv-Delimiter ';'| Out-File-FilePath 'C:\temp\moverequest-status.csv'
I wrote Export-MoveRequestStatistics function for exporting of move-request statistics and failure reporting of current migration / batches.
This is a sample call of this function.
Export-MoveRequestStatistics
Or use “Batchname” property.
Export-MoveRequestStatistics -batchname '2ndbatch'
Management
For moverequest management you can use ECP es mentioned before and PowerShell. ECP give you limited possibilities to manage moverequests, so if you need some advanced actions you need to use PowerShell.
PowerShell gives you following management possibilities:
- Get-MoveRequest: gives you moverequest information.
- Set-MoveRequest: configure additional settings to existing moverequest
- Remove-Moverequest: remove existing moverequest
- Resume-MoveRequest: will resume a failed or suspended moverequest
- Suspend-MoveRequest: will suspend a moverequest “InProgress” status
- Get-MoveRequestStatistics: gives you advanced information to a moverequest
Bulk removal of moverequests
For a mass moverequest removal I wrote Cancel-Moverequests function, which can remove all moverequests of a batch, or a specific user list.
This is a sample call of this function.
Cancel-Moverequests -batchname '2ndwave'
Or you can use a list a Emailaddresses for removal (.CSV or TXT)
Cancel-Moverequests -userlistlocation 'C:\temp\userlist.txt'
Failed moverequests bulk removal
For a mass mailbox removal of failed moverequests I wrote Cancel-FailedMoverequests function, which can remove all failed moverequests and generate a log file of all canceled moverequests.
This is a sample call of this function.
Cancel-FailedMoverequests
Or you can use a list a Emailaddresses for removal (.CSV or TXT)
Cancel-FailedMoverequests -userlistlocation 'C:\temp\userlist.txt'
Bulk configuration of batchname for a bunch of moverequests
For setting up a Batchname for a bulk of moverequests I wrote Set-Batchname function, which is able to set a batchname for a specific, already existing, batch.
This is a sample call of this function.
Set-BatchName-batchname '2ndwave'-newbatchname '3ndwave'
Moverequest Status
Moverequests have a lot of different status information and switches. You can use Get-Moverequest CMDlet to get basic information and if you need extended information, you need to use Get-MoveRequestStatistics.
Basic status information
If you run Get-MoveRequest command in ExchangeOnlineManagement shell you can get following Status information:
- AutoSuspended
- Completed
- CompletedWithSkippedItems
- CompletedWithWarning
- CompletionInProgress
- Failed
- InProgress
- Queued
- Retrying
- Suspended
- Synced
Advanced status information
If you need extended information for a moverequest you need to use Get-MoveRequestStatistics. This CMDlet delivers a full range of information related to moverequest and mailbox migration.
Following information can be retrieved by running this CMDlet:
StatusDetails
AutoSuspended
Canceled
Cleanup
Completed
CompletedWithWarnings
Completion
CopyingMessages
CreatingFolderHierarchy
CreatingInitialSyncCheckpoint
CreatingMailbox
DataReplicationWait
Failed
FailedBadItemLimit
FailedMAPI
FailedNetwork
FailedOther
FailedStallDueToCI
FailedStallDueToHA
Finalization
IncrementalSync
InitializingMove
InitialSeeding
InProgress
LoadingMessages
MDBOffline
NetworkFailure
OverallMove
ProxyBackoff
Queued
Relinquished
Stalled
StalledDueToCI
StalledDueToHA
Suspended
TransientFailure
ADUpdate
StalledDueToMailboxLock
StalledDueToReadThrottle
StalledDueToWriteThrottle
StalledDueToReadCpu
StalledDueToWriteCpu
StalledDueToReadUnknown
StalledDueToWriteUnknown
SyncStage
Cleanup
CopyingMessages
CreatingFolderHierarchy
CreatingInitialSyncCheckpoint
CreatingMailbox
FinalIncrementalSync
IncrementalSync
LoadingMessages
MailboxCreated
SyncFinished
For additional information read this Microsoft article.
Synchronization
Email synchronization and active mailbox move/migration is running only if the status of moverequest is InProgress. So, if your moverequests are Failed, or Suspended, there is almost no traffic between source and destination server.
In the scenario E and F, synchronization traffic is using port 444 and not 443.
You can resume Failed or Suspended moverequests by running Resume-MoveRequest.
If you resume moverequests, synchronization is starting at that point where it stopped, as long moverequest is persisting.
Completion date
Every moverequest has a deadline when it should be finished.
- If the mailbox is synchronized before the deadline it will stay on status Synced short time before reaching the deadline. Before deadline is reached it will start with a delta-sync of current mailbox and then complete the moverequest.
- If AutoSuspend preference is set to $true or you have no CompleteAfter parameter configured, moverequest will sync until 95% and then stop any activities, as long CompleteAfter parameters are not changed.
- If you have configured CompleteAfter parameter, moverequests will stop at 95% and try to run deltasync every 24 hours until the CompleteAfter data has been reached and then moverequest will be completed automatically.
- If you run Resume-MoveRequest without setting up the CompleteAfter parameter, it will just start deltasync for all mail items and stop at 95%
Default value of CompleteAfter is around 100 years if you don’t change this parameter.
Bulk CompleteAfterDate configuration
For setting up a CompleteAfter date for a bunch of moverequests I wrote Set-CompleteAfterDate function, which is able to set CompleteAfter date for a specific batch or a list of users for specific amount of days.
This is a sample call of this function.
Set-CompleteAfterDate -batchname '2ndWave'-amountofdays 5
Or you can use a list of EmailAddresses of moverequests which should be completed after specific amount of days.
Set-CompleteAfterDate -userlistlocation 'C:\temp\userlist.txt' -amountofdays 5
Troubleshooting
A standard migration of mailboxes from Exchange A to Exchange B doesn’t require any troubleshooting effort, except “BadItemsLimit” or some other ‘historical’ errors.
Microsoft is providing a convenient collection of troubleshooting guide for MailMigration here.
I will explain migration troubleshooting on example of most complex architecture in Scenario F.
A lot of ERRORS
In a big enterprise environment, you have a lot of different components across the infrastructure which may cause an error. So before starting with reverse-engineering of all components, you should create a troubleshooting plan.
The Troubleshooting plan.
This is a summary of strategical steps for troubleshooting of Exchange – to – Exchange mail migration.
Step One
Validate your environment according Migration Principals in this article. Check all requirements and considerations.
Step two
Minimize the complexity of your deployment.
- Create host entries for all Exchange-Servers manually, to avoid DNS issues.
- Directly use Exchange IP Addresses and hostnames in your host files, to void any load balancer misconfiguration.
- Enable ICMP protocol between all Exchange-Servers and responsible Domain-Controller for each site.
Step three
Validate if internal migration is working.
- Migrate a mailbox from Mailbox / Source Server to Client / Access server.
- Migrate a mailbox from Client / Access Server to Destination server.
Step four
After you have completed all three previous steps, you can start with troubleshooting and analyze Failure Events of your moverequests.
If there were some changes in your infrastructure / environment and your migration started to fail, just, ROLL BACK ALL CHANGES.
Failure Events
During the migration you may face a lot of Failure events and errors. All of them we can summarize in two Group:
- Deployment Errors
- Performance Errors
Deployment Errors
This kind of errors are related only to your deployment of exchange infrastructure.
If you are trying to create a moverequest and it is failing immediately, and it was never working before you need to restart with “The Troubleshooting Plan”.
Performance Errors
Once you have completed first three steps of our Troubleshooting Plan and you were able to migrate mailboxes from Mailbox / Source Server to Destination Server, all requirements and prerequisites are achieved, and we can start with troubleshooting of failure events.
How to get failure events from moverequests
Failure information of a moverequest is included in Get-MoveRequest and Get-MoveRequestStatistics CMDlets.
You can try both according to your requirements.
You can run following commands:
get-moverequest-Status failed
To get all “failed” moverequests
get-moverequest-Status failed | Get-MoveRequestStatistics | select identity, FailureType, FailureSide, Message, FailureTimestamp
To get all failure information from your failed moverequests.
Use -includereport property
Get-MoveRequestStatistics -Identity mccloud@mccloud.cloud -IncludeReport
For detailed failure protocol. It will include all issues and retries of your moverequest.
Important: MRS proxy is trying to restart every moverequest only 60 times, after that, the status is changing to Failed.
If have found this article from Microsoft that, there is a way how to change the MaxRetry value. In our case this change, had no effect (Exchange 2016).
MRS proxy
As explained in principals, MRS is the same as EWS webservice on every exchange. You can follow this checklist to validate EWS functionality.
EWS checklist
Restart IIS WebService
IISRESET /noforce
Check EWS availability and health
https://mccexch01.mccloud.cloud/ews/healthcheck.htm
the reply should be 200 OK
Restart EWS application pool
Restart-WebAppPool -Name " MSExchangeServicesAppPool"
!!! DO NOT DO IT during business hours, it has impact on user connectivity!!!!
Check IIS Certificate
Use CURL command to check HTTPS connection to all your EWS webservices internal and external
MRS performance settings
MRS replication service is transferring email data from Mailbox / Source server not in realtime, or bit by bit. It is using data packets of “default” 7168KB and trying to transfer it at least every 20 minutes. If the transfer is not possible because of bad latency or packet lost status details is returning following error codes:
o CommunicationErrorPermanentException
o MailboxIsNotInExpectedMDBPermanentException
o SourceMailboxAlreadyBeingMovedPermanentException
We have solved this issue by changing of following values:
ExportBufferSizeOverrideKB does not persist by default, so you need to add this line and change the value to desired KB value. After this change, Mailbox / Source Servers are using smaller packets which has enormous performance benefit.
Additionally, we have changed DataImportTimeout to 5 mins.
After this change your exchange-servers may consume more CPU utilization, so make sure that you have enough CPU resources.
Important: you don’t need to reboot your servers or restart IIS service, to have an effect. It is starting to work after you have saved the file!
This is the only Microsoft article which describes this issue.
Additional MRS proxy performance settings you can find here.
Waiting for approval
Some moverequests may stuck on status Synced and waiting for approval.
Just approve them by using following command.
Set-MoveRequest-Identity 'cloudy@mccloud.cloud' -SkippedItemApprovalTime $(get-date).ToUniversalTime()
Resume-MoveRequest -Identity 'cloudy@mccloud.cloud'
Network bandwidth
Network performance is very important factor during mailbox migration. You need to calculate network throughput before you are starting with migration planning. Calculate with the least bandwidth and not with maximum speed. Validate if some other applications are using your uplink connection.
For calculation of migration speed I wrote Load-Mailboxstatistics which is simply collecting all mailbox information from On-Prem servers and generate a file with Dislayname, TotalItemSize, ItemCount and EmailAddress.
This file is pre-requisite for “Migrationbatch Scheduling”. You just need to run Schedule-Batches which will create a bunch of CSV files with Emailaddresses which you can directly use for moverequest creation.
The script is generating migrationbatches based on your “weekly” throughput and mailbox size. You can adjust amount of data which should be transferred each migrationbatch and data location for export at the beginning of the script.
For additional performance analyze use this Microsoft script.
Network latency
After you have calculated the total amount of data which needs to be migrated and split it in batches, validate your Network latency and packet loss. These two factors have crucial impact on migration performance.
High latency and packet loss causing enormous retransmission traffic, which you can not calculate.
Your mailbox TransferedData may be 2-4x times bigger than your mailbox data.
Test your network latency and packet loss between MRS endpoints by using ping command.
PING your.hostname.com
Or using powershell
Test-NetConnection -ComputerName you.hostname.com
Following error is mostly related to network performance / bandwidth limitation:
Unexpected endof file. Followingelements are notclosed: Data, IMailbox_ExportMessagesResult, IMailbox_ExportMessagesResponse, Body, Envelope.Line 1, position212602.. --> Theformatterthrew an exceptionwhile trying todeserializethe message: Therewas an errorwhile trying todeserializeparameterhttp://tempuri.org/:IMailbox_ExportMessagesResult. TheInnerExceptionmessage was 'There was an error deserializing the object of type Microsoft.Exchange.MailboxReplicationService.DataExportBatch. Unexpected end of file. Following elements are not closed: Data, IMailbox_ExportMessagesResult, IMailbox_ExportMessagesResponse, Body, Envelope. Line 1, position 212602.'. Please seeInnerExceptionfor more details.--> There wasan error deserializing theobject of typeMicrosoft.Exchange.MailboxReplicationService.DataExportBatch. Unexpected endof file. Followingelements are notclosed: Data, IMailbox_ExportMessagesResult, IMailbox_ExportMessagesResponse, Body, Envelope.Line 1, position212602
TCP KeepAlive time
Some moverequests may fail with following error:
Error: Couldn't switch the mailbox into Sync Source mode.
This could be because of one of the following reasons:
Another administrator is currently moving the mailbox.
The mailbox is locked.
The Microsoft Exchange Mailbox Replication service (MRS) doesn't have thecorrect permissions.
This error occurs because of bad-latency and wrong TCP KeepAliveTime configuration.
Based on this Microsoft Article we have deployed this settings as recommended by Microsoft colleagues.
And then we have got this picture
So, remember Step four of our troubleshooting plan.
This constellation of KeepAliveTime configuration started to work very good.
Client / Access Server:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Parameters
{DWORD: “KeepAliveTime”, Value (dec): “300000”}
Mailbox / Source Server:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Parameters
{DWORD: “KeepAliveTime”, Value (dec): “900000”}
Important: This configuration require a Server-Reboot, so please play with these settings after your business hours. Test which values are better in your environment, because they may be DIFFERENT!!
If you still facing some of “Mailbox is locked” errors just simply remove these moverequests, wait 24 hours, and create them again.
Authentication
Take care that your destination credentials are valid and not expiring, or. Your admin role is not expiring.
You can change / update your credentials with following command.
$global:OPCred = Get-Credential
Get-MoveRequest -identity 'cloudy@mccloud.cloud' | Set-MoveRequest $badrequest.ExchangeGuid -RemoteCredential $global:OPCred
Get-MoveRequest -identity 'cloudy@mccloud.cloud'| Resume-MoveRequest
The operation couldn’t be performed because matches multiple entries
If you got this error, you are lucky.
Just raise a ticket to Microsoft Support and they will help you.
Transport services
Mailbox migration is not using only HTTPS protocol, it is still using all Exchange-Services.
Make sure that all Exchange-Services are still running on all Exchange-Servers.
Here is table of all Exchange-Services as reminder.
"MSExchangeADTopology"
"MSExchangeAntispamUpdate"
"MSExchangeCompliance"
"MSExchangeDagMgmt"
"MSExchangeDelivery"
"MSExchangeDiagnostics"
"MSExchangeEdgeSync"
"MSExchangeFastSearch"
"MSExchangeFrontEndTransport"
"MSExchangeHM"
"MSExchangeHMRecovery"
"MSExchangeIS"
"MSExchangeMailboxAssistants"
"MSExchangeMailboxReplication"
"MSExchangeNotificationsBroker"
"MSExchangeRepl"
"MSExchangeRPC"
"MSExchangeServiceHost"
"MSExchangeSubmission"
"MSExchangeThrottling"
"MSExchangeTransport"
"MSExchangeTransportLogSearch"
"MSExchangeUM"
"MSExchangeUMCR"
"SearchExchangeTracing"
"Winmgmt"
"IISADMIN"
"W3SVC"
"RpcSs"
Avoid any kind of backpreasure.
Watchout of following events!
Event log entry for an increase in any resource utilization level
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15004
Event log entry for a decrease in any resource utilization level
Event Type: Information
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15005
Event log entry for critically low available disk space
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15006
Event log entry for critically low available memory
Event Type: Error
Event Source: MSExchangeTransport
Event Category: Resource Manager
Event ID: 15007
Diskspace / Disklatency
The Microsoft Exchange Transport service is rejecting messages because available disk space is below the configured threshold. Administrative action may be required to free disk space for the service to continue operations.
If you are operating MailboxDataBases with NTFS filesystem, you may have also of disklatency warnings.
To avoid this performance issue, you can migrate your MailDBs to a REFS filesystem to get more performance during the migration.
CPU
If you are running virtualized Exchange-Servers and “forsure” you are not using CPU reservation, you may get StalledDueSource_processor warning.
Here is an Microsoft Article how you may fix this.
One Command to fix them all!
To fix all mentioned issues I wrote function Resume-Failedmoverequests.
If your moverequest are failing with some different errors, so please support us to solve them all
Submit your moverequest issues to FIX THEM ALL!
If you have additional questions, just reach out to me.
Visit my GITHUB repository! You can find this script and all steps right there.
Comments