Topology publishing fails because Trusted Server and FQDN already exists for a different TLS target

When upgrading our Lync infrastructure from 2010 to 2013 I encountered some errors upon the first time I would publish the Lync Server 2013 Enterprise pool, consisting of three Front End servers and a fresh SQL server instance.

Diving into the resulting log file can quickly lead you to think that almost everything failed, as every parent category of the action point that actually went wrong will also be labeled “Completed with errors” or “Failed”. Therefore it is important that you (for your own mental well-being) filter out those things and drill down to the action point that is causing the problem, often with the “Execution result” column simply indicating “Error”.

Now, back to my specific problem. The one line that was causing my misery read:

A trusted server with the type “Microsoft.Rtc.Applications.TestBot” and the fully qualified domain name (FQDN) “pool.domain.local” was found for a different Transport Layer Security (TLS) target.

(during my initial research I also came across others having experienced the same problem, although their error could point to other trusted server “types” the first and last part of the error message would be the exact same)

What the error message actually says is that an object definition for the Audio Test Service (ATS) – code name “TestBot” – already exists and furthermore is conflicting with the one that Topology Builder is trying to publish. The conflicting object here is an Active Directory object related to Lync or previous versions of Office Communications server.

Some reasons this might occur:

1. You had a demo/lab environment that you did not properly remove before setting up the production environment of Lync
2. Your previous installation of Lync went wrong and you did not remove all traces of it before you tried over (simply reformatted the server or something like it)
3. You have migrated from previous versions of Lync/OCS/LCS and not kept the path clear of old (or “stale”) references to their instances
4. I have also seen references to this happening upon SIP domain changes

There may be other reasons as well, perhaps. More important is how to fix it. Alas, there is no “simple” fix – only manual search and delete including ADSI edit. The following should not be undertaken if you are unfamiliar to the use and more so the consequences of misusing this powerful tool, as it can have fatal results for your Active Directory. Make a system state backup so you have something to fall back to if something goes wrong!

If you are still up to the task, then here’s what to do:

1. Open ADSI edit (adsiedit.msc) on your Lync server or a domain controller
2. Highlight the top level item “ADSI Edit” and select “Action” -> “Connect to” from the menu bar
3. In the popup window you will be asked to select what server and what part or “naming context” of Active Directory you will be inquirying. For the naming context there will be two possible choices, and you will have to check out which one is right in your environment:
   
   • The “Configuration” context is more common, and the one which Microsoft recommends. By chosing this and then drilling down to Services container you should locate another container named “RTC Services”.
   • For environments that have been carried over from OCS 2007 or previous versions, chances are that the objects we are looking for reside in the “Systems” container. To get to this, choose “Default naming context” from the previously mentioned popup window and from there drill down to “System” and “Microsoft” – and there should be the “RTC Services” container
4. Once you know where your Lync AD objects are located, simply right-click the “RTC Services” container, select Properties and double click the distinguishedName attribute from the list that appears. Copy the contents of this, which should look something like “CN=RTC Services,CN=….”
5. The next step is to export (to text file) the objects of this AD container. Open a command line window and type/paste in:
   ldifde -d "[paste here]" -f lyncobjects.txt (including the ” but not the [ or ])
   This will export the “RTC services” container (and subtree) to the lyncobjects.txt file.
6. Using Notepad or your editor of choice search for “testbot” (or other trusted server reference in the error message)
7. Within the text paragraph you get a search hit there should be attributes like TrustedServerFQDN or TlsTarget. If you know the value of these to be wrong, outdated or stale then make note of the name attribute of the object – it will be in the GUID format (long string of alphanumeric characters with hyphens inbetween).
   
   Remember that there will also be VALID references to the same service object, so make sure you do not go ahead with the wrong object from here!
8. Once you know that you have found a reference to an outdated or invalid object go back to your ADSI edit window
9. Within the same “RTC Services” container there will be another container named “Trusted Services”
10. Look for an object with the same name/GUID reference that you found in the text editor, and once located – right-click and select Delete
    
11. Repeat for other instances you may have found

Once you are rid of the stale objects in AD, leave some time for the domain controllers to get in sync and then retry publishing your topology. Which SHOULD now be okay, at least from the Active Directory point of view.

Advertisement