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”.

Publishing error log

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:
    ADSI connect

    • 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).
    LDIFDE output
    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
    ADSI delete object
  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.

Advertisements

7 thoughts on “Topology publishing fails because Trusted Server and FQDN already exists for a different TLS target

  1. Weekly IT Newsletter – June 16-20, 2014 | Just a Lync Guy

  2. Hello,
    I did all these steps,and showed 0 entries
    bit still unable to publish topoply due to the existence of users,contacts,..
    Is there any tool which shows what r the users contacts they still in the pool

    all down gave 0 entries
    ?Get-CsUser
    ?Get-CsExUmContact
    ?Get-CsCommonAreaPhone
    ?Get-CsAnalogDevice
    ?Get-CsRgsWorkflow
    ?Get-CsDialInConferencingAccessNumber
    ?Get-CsAudioTestServiceApplication
    ?Get-CsTrustedApplicationEndpoint
    ?Get-CsPersistentChatEndpoint

    • If I understand you correct, you don’t get the “TLS target” error but cannot publish because you have existing users in the pool?
      Judging from what you say about the output from the cmdlets it looks like you are installing a new, clean pool and not upgrading – am I correct? In that case I would consider manually remove any object from AD (using ADSI edit) residing in the RTC Service container to make sure there are no “leftovers” from a test install or whatever. If you ARE doing an upgrade you should see the existing users/devices and there is something else creating trouble – in that case, review the “publishing failed” log.
      I am not aware of any tool to browse for users or devices in the pool apart from powershell cmdlets, but they all reside in the backend database and can easily be retrieved using SQL Server Management Studio. Common Area Phones also have an AD contact object.
      Not sure if this was helpful at all, but feel free to pass along some more info about the error if you feel like I can assist you in either way.

      Brgds,
      Rune

  3. It keeps saying no entries found
    something really weird. isn’t there a way this can be done from GUI. or perhaps more hints of the command. I’m entirely new to using command to do things

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s