Read time 4 minutes

Summary:Exchange Server error, “Recipient is not a mailbox,” can occur due to soft-deleted mailboxes, migrating a newly created mailbox (premature migration), or due to a missing GUID. Resolving such an error is a complicated task, particularly when you’re not technically skilled or have an extremely large database. Learn the steps to get rid of the error and see how Kernel for Exchange Server helps you recover any lost mailbox data.

We are an organization working with the Office 365 Hybrid ecosystem, where we have Exchange Server 2013 as the on-premises server. We recently synchronized on-premises users with the cloud, and the process was successfully compiled. However, when we performed the migration of the mailboxes, some of them were migrated, but the process for others failed, showing an error message:

Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ‘<GUID>’. –> Cannot find a recipient that has mailbox GUID ‘<‎GUID>’

Each Exchange Server migration has its prerequisites that should be arranged before starting the migration. If the prerequisites are not fulfilled, the migration batch will show errors or will get terminated midway. Check out the solutions that we used to resolve the recipient does not have a mailbox error and what precautions we followed to avoid the issue in the future. MigrationPermanentException

What is a GUID Value?

The GUID value is the Globally Unique Identifier (GUID) associated with each mailbox that links the mailbox to Active Directory. This property is a member of the Exchange Mailbox class and gives a read-only value to the mailbox. You can consider it as the unique value that defines the association between Active Directory and mailboxes. It legitimizes the existence of the user account.

Where is GUID used?

Apart from user accounts, the GUID is used at multiple places wherever a unique identifier is required.

  • The database keys used to connect with other databases.
  • Desktop files like MS Word, Excel, PowerPoint, Access, etc.
  • Server routers.
  • Operating System images.
  • Windows application programs.

Why am I seeing “The Recipient is not a mailbox” error?

The main cause behind the error is that the GUID value is not associated with the on-premises Exchange. When the mailbox is migrated, the value is not synced with the Exchange Online mailbox. When you see the respective mailbox properties in the Active Directory, you can see that the GUID called msExchMailboxGuid is not set.Cause of the Error

How to resolve the Office 365 migration failed error?

The administrator needs to set Exchange GUID property on the mailbox before migrating the mailbox to resolve the error. Here is the process that you should follow to complete the process-

  1. On the on-premises Exchange Server, open the Exchange Management Shell and run the following cmdlet to check if the Exchange GUID property is set on the mailbox.
    Get-RemoteMailbox ‘<MailboxName’> | Format-List ExchangeGUID

    If the cmdlet output shows the value of ExchangeGUID as zero, then it indicates that the GUID property is not set.

  2. Now, open the Windows PowerShell, not the Exchange Management Shell, and connect it with the Exchange Online.
  3. After connecting with Exchange Online, you need to run the above cmdlet again.
    Get-RemoteMailbox ‘<MailboxName’> | Format-List ExchangeGUID
  4. When the cmdlet shows the value of the GUID as zero, then run the following cmdlet to set the value.
    Set-RemoteMailbox ‘<MailboxName’> | -ExchangeGUID ‘<GUID’>
  5. Perform the directory Synchronization.

Now, you can go ahead with the Exchange Server migration. But there are some precautions that you should take while starting the migration, which can save you from facing errors.

  • The mailbox should be assigned permissions like the Mailbox Server Permissions, Recipient Management Permissions, Organization Management Permissions, etc.
  • There should be a hybrid deployment between the Exchange Server on-premises and Exchange Online.
  • At the on-premises Exchange Server 2013, the administrator should enable the Mailbox Replication Proxy Service (MRSProxy).
  • The mailbox at Microsoft 365 should be assigned the license only after the completion of the migration.

Conclusion

Smooth migration of Exchange mailboxes can be completed only when permissions and other values are set properly. But, if an ongoing batch migration fails, the mailbox will not migrate. Only a seasoned Exchange Administrator can handle such situations and migrate the mailboxes safely. Use Kernel Migration for Exchange to migrate mailboxes from Exchange Online to Exchange on-premises, or between Exchange server versions. The tool will also help with Exchange cross forest migration and provide a full migration report at the end.

Frequently Asked Questions

Q. What are the reasons for failed Office 365 migrations?

Ans. Some of the reasons that can cause failure of Office 365 migration include:
1. Slow or unstable internet connection
2. Migration of extremely large mailboxes and EDB files
3. Not having a post-migration strategy ready beforehand
4. Lack of Office 365 migration security policies

Q. How to avoid “recipient has no mailbox” or other Office 365 migration failures?

Ans. Follow the given tips to avoid errors during Office 365 migration:
1. Identify: Check out error logs or the migration batch report to find the type of error and error code.
2. Disable MFA: Legacy servers often show errors during migration when multi-factor authentication is enabled.
3. Assign permissions: Assign full or as required access to the admins in the source and destination.
4. Remove conflicting objects: Eliminate any unused or inactive user accounts from cloud for a clean sync.

Kernel Migration for Exchange
Related Posts