How to Resolve the Endpoint Not Found Transient Exception Error in Public Folder Migration

When moving from on-premises Exchange Server to Office 365 or Exchange Online, the hybrid migration method provides the smoothest process. But it is the longest one as well. The hybrid setup allows seeding data to the cloud without impacting users’ mailboxes. This also allows for migrating public folders.

However, one might encounter several issues and errors during the migration. In this article, we discuss the EndpointNotFoundTransientException error encountered during migration and potential solutions.

About the Error

The error occurs when executing a public folder migration batch from a 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 a 404 Not Found.

Testing the Endpoints

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

Test-MigrationServerAvailability -Endpoint <endpoint name>

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

Troubleshooting the Issue

First, check for configuration issues on 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 unsuccessful and the migration failed, you can review the situation on 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 are no limitations and that Windows Firewall or the network firewall does not block ports. You can verify 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 (CUs), including operating system security patches. All required services must be running, and the configuration, websites (OWA and EWS), and Outlook Anywhere are working without issues. You can verify with your Exchange admins that everything is working correctly.

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

To confirm this, verify the SourcePFPrimaryMailboxGuid. Follow this procedure to ensure the local Exchange Server GUID is used.

First, connect to Exchange Online PowerShell to query Exchange Online. Next, identify the SourcePFPrimaryMailboxGuid value for the parameter you specified in the migration batch. You can accomplish this by running the following command.

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

The next step is to verify that the GUID you provided is from Exchange Online by running the Get-Mailbox command shown 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 incorrect GUID issue, you can recreate the migration job. To do this, use the Exchange Management Shell and run the following command to retrieve 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 using the command below.

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, fixing an issue can take considerable time and resources. It may also make things worse or even cause data loss. To ensure a smooth migration and save time, you can use an EDB-to-PST converter, 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, unlimited export size, priority exports, and resumption on failure.