Merge Topology Failure, Microsoft Lync Server 2010

For a co-existence scenario using Microsoft Office Communications Server 2007 (or R2) and
Microsoft Lync Server 2010. There is a process that must be completed once the Lync CMS and first pool has been deployed. This is the merge topology process. The process is wizard driven using the topology builder and allows the user to input manual edge server details but will query AD to import the rest of the data. Part of the process completes a validation of the existing topology and objects within AD to ensure the data being merged across is clean and duplicates do not exist.

I came across this issue when attempting to merge the topology and it can be time consuming to troubleshoot.

A typical error message encountered is:

ERROR : Topology error description: "There was a problem validating the topology XML against the XSD that defines the schema."
ERROR : Topology error instances: "[ System.Xml.Schema.XmlSchemaValidationException: There is a duplicate key sequence 'urn:application:Rgs SipServer Primary Mtls' for the 'urn:schema:Microsoft.Rtc.Management.Deploy.ServiceRoles.2008:ComponentPortId' key or unique identity constraint. ][ System.Collections.Generic.List`1[System.Object] ]"
ERROR : Topology error reason: "FailedSchemaValidation"
ERROR : There were errors while creating and validating a topology.

The important entry from this error log to note is 'urn:application:Rgs SipServer Primary Mtls'

This particular entry denotes a duplicate entry for the RGS service; however the urn:application could one of a number of different entries including Cas, Caa etc

Once you know what entry you are looking for, the easiest way to find the duplicates is to run an LDAP search within ADUC. For the error above we can run a custom LDAP search across AD for the following: (msRTCSIP-TrustedServiceType=Microsoft.Rtc.Applications.Acd).
This will return a number of entries per pool all named with GUIDs. Open each one and note which pool and entry they are for looking for the duplicate entries.

Once the duplicates are identified it is then important to identify which ones are current are ones are the duplicates and although the timestamps will be different, I would recommend running a validation of that component on the pool in question and searching the logs to find out which ones are the valid current ones and which ones can be removed. There will typically be multiple entries for an Enterprise pool due to entries for the poolname and entries for the individual front end server. These should be treated as a group of entries.
Once sure of the duplicates, remove them from AD, allow time for replication and then the merge topology should succeed.

Other typical issues include:
Mis-configuration of global components within OCS
Orphaned objects (this can occur if servers have been turned off without the correct role decomissioning process being followed)

This is not a definitive list but the key to remember for troubleshooting this type of error is that the process is ensuring the configuration is clean and valid before allowing the merge to take place which can only be a good thing.