So there you are, minding your business, just trying to publish your Lync topology because you have the NERVE to want to peer you precious-little Lync Pools. The stones on this guy! So you do the whole right-click, Topology, Publish thing (or Enable-CSTopology for you shell-minded types). But whats this? failures? But why? Huh? ‘Multiple Active Directory entries were found for type ms-RTC-SIP-TrustedServer with ID’ – Auto-mo-bile?!



The setup:


1 Lync 2010 3-node EE pool in Site 1

1 Lync 2013 3-node EE pool in Site 1

1 Lync 2013 3-node EE pool in Site 2


The Problem:

Went to enable resiliency between the 2013 pool in site 1 and the 2013 pool in site 2. Once attempting to publish topology, the above error incurred. My rights are limited in AD but full rights for the Lync environment.


Ok then, no idea so to Bing we go. I had seen a similar issue in the past, but it was more along the lines of this article, or this one, (thanks be for MVP’s) where there were obviously duplicated entries in the various RTC folders in the Configuration partition, but in this case, at least at first glance not so much. So we dig.

Since I am old, I of course was going through each item in the configuration, trusted services  container looking for the gruuID mentioned in the log manually. This will take a while. I know there got to be a better way to go through these in powershell, but I am slow so I turned to someone much smarter than myself for help. And no, it wasn’t @patrichard – I bug him enough 🙂 Big thanks to Jesse Lange @JesseJLange for working through this with me.

Whats misleading about the above error (to me at least) is that its calling out the Distinguished Name (DN) of the object that holds the gruuID in question, not the DN of the duplicate object itself.  In the image below we see that the gruuID for msRTCSIP-TrustedServerData that Enable-CSTopology is beefing about is held on the actual object with a DN of 6da8c2ca……. There will be more that will need to be corrected in my case but this is just an example.



So the following was done to get into where this duplicate object (s) truly lived: Again, this was all @JesseJLange so thank you.

Get-ADObject -Filter {msRTCSIP-TrustedServerFQDN -like “*machinename*”} -SearchBase “CN=TrustedServices,CN=RTC Service,CN=Services,CN=Configuration,DC=contoso,DC=com” -properties DistinguishedName,msRTCSIP-TrustedServiceType,whenCreated | select DistinguishedName,msRTCSIP-TrustedServiceType,whenCreated | Sort WhenCreated

Clear the msRTCSIP-TrustedServerFQDN attribute from all objects from the above searchbase within a certain time period 

Re Run Enable-CSTopology to return next error. – In our case we had an issue with each Front end in the pool and all/most of the components. So each time we cleared one item and ran Enable-CSTopology, we would go to the next  error.


Get-ADObject -Filter {msRTCSIP-TrustedServerFQDN -like “*machinename*”} -SearchBase “CN=Configuration,DC=contoso,DC=com” -properties DistinguishedName,msRTCSIP-TrustedServiceType,whenCreated | Select DistinguishedName,WhenCreated | sort WhenCreated

Clear the MSRTCSIP-TrustedServerFQDN attribute value

Re Run Enable-CSTopology for the next failure

Trusted MCU errors. Run the following to find the duplicates.

Get-ADObject -Filter {msRTCSIP-TrustedMCUFQDN -like “*machinename*”} -SearchBase “CN=Trusted MCUs,CN=RTC Service,CN=Services,CN=Configuration,DC=contoso,DC=com” -properties DistinguishedName,msRTCSIP-MCUtype,whenCreated | Select DistinguishedName,msRTCSIP-MCUtype,WhenCreated | sort WhenCreated


Clear the msRTCSIP-TrustedMCUFQDN

Run Enable-CsTopology again for the next failure.

Next, Web Components. FUN!!

Run the following.

Get-ADObject -Filter {msRTCSIP-TrustedWebComponentsServerFQDN -like “*machinename*”} -SearchBase “CN=Trusted WebComponentsServers,CN=RTCService,CN=Services,CN=Configuration,DC=contoso,DC=com” -properties DistinguishedName,msRTCSIP-MCUtype,whenCreated | Select DistinguishedName,msRTCSIP-MCUtype,WhenCreated | sort WhenCreated

Remove value for msRTCSIP-TrustedWebComponentsServerFQDN.

Run Enable-CsTopology for the next failure.

Ran the following query and deleted the duplicate keys (oldest) for each Mediation (yes, a 3 node MED pool) server in the Trusted Services container.

Get-ADObject -Filter {msRTCSIP-TrustedServiceType -like “*Mediation*” -and msRTCSIP-TrustedServerFQDN -like “*machinename*”} -SERVER DC002 -SearchBase “CN=Configuration,DC=contoso,DC=com” -properties DistinguishedName,msRTCSIP-TrustedServiceType,msRTCSIP-TrustedServerFQDN,whenCreated | select DistinguishedName,MSRTCSIP-TrustedServerFQDN,WhenCreated | sort whencreated

Run Enable-CsTopology for the next failure.

Publishing now completes.

The Moral of the Story or What Went Wrong.

I am still not 100% certain what went wrong here but this is my theory at this point:

Prior to fully deploying and bootstrapping this pool, it was determined by management to change the name of the pool. The pool only existed in topology, but the servers were never actually deployed. Note also that the machines were already built and joined to the domain and kept the same name, just would be in a different pool. The pool was removed from topology and the topology was published. And thats where I believe the issue began. Like I said earlier, in this environment my AD rights are constrained. After removing the pool, I did receive an error with insufficient rights from topology builder and someone with more AD rights then went and published and it went through fine. Note also I was able to deploy the pool with no issues but not remove it.

So I am thinking something just didn’t get cleaned up correctly after the removal of the original pool. It does strike me that maybe Topology builder should do a little more verification on the capabilities of the account running Enable-CSTopolgy though as to avoid these issues. Or maybe just don’t change the pool name at the last minute.

Please let me know if you have any comments or questions.

Thank you.