Once the server has performed the necessary actions, the actual conflict can be resolved. This can happen three different ways:
As a conflict message is opened, the Microsoft Exchange Client detects the MSGSTATUS_IN_CONFLICT flag on the message and launches its standard conflict resolution note. This allows the user to open the attached conflicting messages and select the winner of the conflict or combine the data in the different versions to reconcile them. The value of MSGSTATUS_IN_CONFLICT is defined in the EDKMDB.H file.
If the form server for the message class is registered as one that can handle its own conflicts, the client does not launch the standard conflict resolution form. Instead, it launches the form registered for the message class as normal. It is then up to the form’s code to either reconcile the conflict itself (as described in Automatic Conflict Resolution) or display the conflict to the user using its own user-interface semantics,so the user can do the reconciliation. For more information on registering a form for conflict resolution, see Resolving Message Conflicts with Forms.
A mailbox application establishes itself as a public folder contact that can receive conflict notification messages. In this case, the conflict notification message will be mailed directly to the application. Conflict notification messages can be easily identified because they have the message class IPM.Conflict.Message.
The application opens the PR_CONFLICT_ENTRYID property on any notification message to find the original conflict message that contains (as attachments) the conflicting versions of the message. At this point, the mailbox application proceeds as described in Automatic Conflict Resolution.
In the time before an application receives and processes the conflict notification, either of the other resolution methods (described in A User Resolves the Conflict or A Custom Form Resolves the Conflict) might have occurred. Therefore, the mailbox application should be prepared for the possibility that the conflict has already been resolved.
Note The latency inherent in a replication schedule can cause special circumstances. If multiple applications resolve a conflict before the next replication, a new conflict is the result. Also, until a conflict resolution is replicated throughout the entire system, the conflict remains visible to users and applications. At this point, new attempts to resolve the conflict may cause further conflicts.