In order to resolve an issue where schema mismatch is cited, it is critical to understand the scenario in which the is error is being raised as it may influence the data collected. The common scenarios are:
Recent Schema Update
DC Promotion
Normal Replication
As stated previously, in the case of a recent schema update it is common for some DC's to report the schema mismatch as a normal part of processing the update. This state should only be investigated if it persists for an extended period Schema Mismatch during promotion of a DC is almost always a persistent issue that cannot be overcome without investigation and remedial steps being taken.
Initial Data Collection
The aim of the initial data collection is to try to capture information sufficient to identify if a known issue is being experienced or if other issues are contributing to the failure.
Collecting replication data for all DC's in the forest is advised particularly in the case where a schema mismatch has been noted after a recent Schema Update or during normal replication monitoring. Collecting this data helps identify any pockets of replication failure on which to focus.
Repadmin showrepl * /csv > allrepl.csv
Once all the DC's experiencing replication failures, of ANY form, have been identified from the repadmin /showrepl data focus cam move to specific DC's.
In the case where DCpromo fails with a schema mismatch the following data should be collected:
DCpromo and DCpromoUI logs
NTDS Diagnostic Event Logging on both the source and destination DC as described below in "Data Collection Phase 2"
Ldifde Export of the Schema partition as described below in the "Schema Review"
reference:https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/replication-error-8418
Best wishes
Vicky