This is a second blog post about troubleshooting public folder replication issues. In first post we covered Troubleshooting the Replication of New Changes. This blog post covers Troubleshooting t...
Updated Jun 05, 2020
Version 3.0
Blog Post
11 MIN READ
Public Folder Replication Troubleshooting - Part 2: Troubleshooting the Replication of Existing Data
That's right. We wouldn't expect the store that's missing data to respond with a status message (0x10) to the status request (0x20) from the store that has the data. And in that situation we really don't care if it does. The important thing is that the status request (0x20), which itself contains status information, makes it to the store that's missing data. When that store receives it, it will create entries in its backfill array for that missing data. It would only respond if it somehow had data that the other store didn't.
A store will create entries in the backfill array any time it receives status information that includes CNs that it doesn't have. Therefore, the backfill process can be triggered by any type of replication message - not just a status response - because all replication messages contain status for their respective folders. In this scenario we're triggering it with a status request (0x20), and that's really just because we don't have the option of forcing a status response (0x10) in ESM.
A store will create entries in the backfill array any time it receives status information that includes CNs that it doesn't have. Therefore, the backfill process can be triggered by any type of replication message - not just a status response - because all replication messages contain status for their respective folders. In this scenario we're triggering it with a status request (0x20), and that's really just because we don't have the option of forcing a status response (0x10) in ESM.