IMAP Migration from Google Workspace to Microsoft 365
Hello Team, Greetings!! We have recently been experiencing significant delays during IMAP migrations from Google Workspace to Microsoft 365 and would like to understand if there are any known issues or recent changes affecting IMAP migration performance. We are aware that Microsoft provides the native Google Workspace migration method, which would generally be preferable. However, in our migration scenarios, we have split routing/coexistence configured, with the domain configured as Internal Relay in Exchange Online. Because of this setup, we are currently unable to select/configure the required target delivery domain as expected during the native Google Workspace migration process. Could you please confirm: Whether there are any known issues, throttling, or performance degradation with IMAP migrations from Google Workspace to Microsoft 365 recently? Whether the Internal Relay/split-routing configuration can affect the native Google Workspace migration process or the availability of the target delivery domain option? Is there any recommended configuration or workaround that would allow us to use the native Google Workspace migration while maintaining split routing? Any guidance or recommended approach would be highly appreciated.The 100 migration batches limit and how to not run into it
As you might or might not know, in Exchange Online we have an upper limit of 100 migration batches. You can see this limit for MaxNumberOfBatches in the Exchange Online PowerShell Get-MigrationConfig: (To understand the MaxConcurrentMigrations limit of 300, you can check this blog post written by one of our migration experts, Brad Hughes.) 100 batches created at the same time should be enough for all O365 multi-tenant customers. But, as we have seen in support, sometimes there are support tickets opened because customers would see the error that says: “The maximum number of migration batches is already running. Please remove a batch before you add another one”. The main reason why this number of batches limit is in place is that having more than 100 batches causes performance problems and could cause outages for other customers in the multi-tenant system. Additional reading on resourcing for mailbox moves can be found here. Let’s say that you want to migrate 50,000 mailboxes to Exchange Online: you could create 50 batches with 1000 users each, and you would still have 50 batches available. If you need to complete all the migrations of users from Batch_1 at the same time, you can easily set -CompleteAfter at the migration batch level. Once this batch is completed, you could delete it to create room for another one. In real world, though, we have seen that our customers rarely want to complete large amount of mailbox migrations at the same time. This is usually the reason why large migration batches are not created but rather smaller batches are preferred. That way, all the migrated users from one migration batch at a time can be completed together. In this scenario, our recommendation is to have large batches for initial sync and if you need to complete the migration for users at a separate date, then you would complete the migration for groups of users in smaller batches, as needed. So how would you create small completion batches for already synced users from larger synced batches? Suppose you want to complete migration of users A, B and C, who reached Synced status and they are all contained in a large batch of 1000 users called Batch_1. To do this, first ensure that you have fewer than 100 batches created at the moment: (Get-MigrationBatch).count Then, proceed with PowerShell commands to get the users from the larger batch Batch_1 into the new smaller batch CompletionABC. Then complete this smaller batch and optionally, remove the completed migration batch: New-MigrationBatch -Name CompletionABC -UserIds EmailAddressOfUserA, EmailAddressOfUserB, EmailAddressOfUserC -DisableOnCopy -AutoStart Complete-MigrationBatch CompletionABC Remove-MigrationBatch CompletionABC Another method we sometimes see people using is setting -CompleteAfter on the move requests directly using Set-MoveRequest. We don't recommend this method because the Migration Service may overwrite the per-request CompleteAfter setting with the one from the batch without notice. This method of individually completing the move requests should only be done when you’ve started the migration through PowerShell, using New-MoveRequest cmdlet, without creating migration batches to contain those move requests. I hope this post gives you a better idea of how to manage migration batches with many users being migrated and not have to run into the limit of number of batches. See you in the cloud! Special thanks to Brad Hughes and Nino Bilic who contributed to this blog post and their precious help in my daily support job. Mirela BuruianaCross Tenant Mailbox Migration: NotAcceptedDomainException
This week I'm performing a new cross tenant mailbox migration. I have some experience with this kind of migrations, ( it's the third one I'm in charge of ), and with the new procedure, ( will paste the link with the instructions at the end of this article ), an Azure Key Vault is no longer required, so I was very confident and thought that I would no have any issue. But, as sometimes occurs, I was wrong The setup was quite easy, and the mail users configuration was like always, so no a big deal. But now comes the point... Once I launched the migration batch, half of the users started syncing correctly and the ther ones failed, ( neither a MoveRequest was able to start for them ). Once I checked the errors, I got the same for all the failed ones: " NotAcceptedDomainException: You can't use the domain because it's not an accepted domain for your organization ". Ok. No problem... ( I thought ). I work with Exchange since more than 10 years and this is a common error message. ( Again I was wrong ). I started to check the mail users, looking for some misspelled domain, missing alias, spaces, etc... Basically, the troubleshooting for this kind of errors. But from my perspective all looked good. So, I decided to reconfigure all the mailusers with a script, launch a delta sync, and resume the failed moverequest. But again, same error for all of them. Checked again, with PS, from source and target tenant, checked in AD, all the proxy addresses... Nothing, all was correct! Non sense... Ok. At that point I decid to compare some syncing mail users with some failed ones, looking for anything that could be a pattern. And "voilá"! The syncing users were all licensed in O365... The failed ones not! After assigning a license to the failed ones and resume the MoveRequest, all started to work smoothly. For sure, I would have saved many hours of work if the error message had been: " The user is not licensed ". But, yeah... It would have been too simple 🙂 Summarizing, make sure that the mail users have an O365 license before you start the migration batch. And remember, not always the error messages are what they seems to be 🙂 Cross Tenant Mailbox Migration procedure, ( Preview 😞 https://docs.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide
