[Fixed]: EndpointNotFoundTransientException Error in Public Folder Migration

When moving from on-premises Exchange Server to Office 365 or Exchange Online, hybrid method of migration provides the smoothest migration process. But it is the longest one as well. The hybrid setup allows to seed data to the cloud with no impact to the users’ mailboxes. This also allows to migrate public folders.

However, there are a number of issues and errors that one might encounter during the migration. In this article, we will be discussing the EndpointNotFoundTransientException error that one might encounter during migration and the possible solutions to resolve it.

About the Error

The error occurs when executing a public folder migration batch from local Exchange Server seeding to Exchange Online. After running the command, you will get the EndpointNotFoundTransientException error. It could include the following details:

• There was no endpoint listening at https://mail..com/EWS/mrsproxy.svc that could accept the message.
• The remote server returned an error: (404) Not Found.

Testing the Endpoints

You need to make sure that the migration connectivity and configuration of the public folder endpoint is correct. You can do this by running the below command in the Exchange Management Shell (EMS).

Test-MigrationServerAvailability -Endpoint <endpoint name>

This will confirm if the configuration is correct. If there is any issue, you need to revisit the configuration of the Hybrid setup.

Troubleshooting the Issue

Firstly, you need to check if there are any configuration issues with your Exchange Server. Although hybrid migration is the smoothest one, you need to ensure that the Exchange Server is in top condition. If the test was not successful and the migration has not worked, you can access the situation with your on-premises box.

Now you need to check the network. You must ensure that there is an open passage between Exchange Online and Exchange Server. You need to confirm that there is no limitation or ports are not blocked by Windows Firewall or network firewall. You can confirm with your network and server admins that all is open between the two systems.

The next step is to ensure that the Exchange Server is fully patched with the latest Cumulative Updates (CU), including security patches of the operating system. All the needed services must be running and the configuration, websites (OWA and EWS), and Outlook Anywhere are working with no issues. You can verify with your Exchange Admins to ensure that all is working well.

The other thing you need to confirm is that you are using the correct SourcePFPrimaryMailboxGuid when creating the migration batch. You need to confirm that the local Exchange Server GUID is specified.

To confirm this, you need to verify the SourcePFPrimaryMailboxGuid. You can use the following procedure to ensure that the local Exchange Server GUID was used.

First, connect to the Exchange Online PowerShell so that you can query the Exchange Online. Next, identify the SourcePFPrimaryMailboxGuid value of the parameter that you have specified in the migration batch. This can be done by running the below command.

(Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq "PublicFolder"}).SourcePFPrimaryMailboxGuid

The next thing is to verify the GUID you provided is from the Exchange Online by running the Get-Mailbox command as given below.

Get-Mailbox -PublicFolder <GUID from previous command>

The GUID shown in the previous step should match and the migration batch was not created.

Possible Solutions

To resolve the issue of the wrong GUID, you can recreate the migration job. For this, use the Exchange Management Shell and run the following command to get the public folder mailbox GUID from the local Exchange Server.

(Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid.GUID

The next step is to recreate the migration batch in Exchange Online by removing the current batch as given below.

Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq "PublicFolder"} | Remove-MigrationBatch

It will take 10 to 15 minutes for the removal to take effect. This can be confirmed by using the below command.

Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq "PublicFolder"}

The next step is to create the migration batch from scratch using the right GUID from the local server.

If this worked, you should be able to execute the batches. If not, you need to look into the Exchange Server, network, or other configurations.

Conclusion

Sometimes, when trying to fix an issue, it would take a considerate amount of time and resources. It may also end up in making things worse or even data loss. For smooth migration and saving time, you can use an EDB to PST converter tool, such as Stellar Converter for EDB. With this tool, you can easily open the EDB file, browse through the database, and export the public folder to PST and other formats. You can also directly export public folders, mailboxes, archive mailboxes, shared mailboxes, and disabled mailboxes directly to Office 365. The tool features automatic mailbox matching, parallel exports, no size limit, priority exports, and continuation in case of failure.