|This articles goes into how to remove AD objects. BE very judicious in this endeavor or you could have dire results. Don’t remove anything from AD without understanding the context of what you are doing!|
Publishing Topology Fails
There are a few reasons why an initial topology may fail to complete. There is one unique first case, I thought may be useful to someone in need.
The scenario is you publish the topology and you get a cannot connect to database error . There may be a few errors possible, but essentially you cant connect to the database. The error goes so far as to say “the existing topology identifies database a\rtc as the Central Management store, but the topology you are trying to publish identifies b\rtc as the central management store.”
The first thing you want to do is go to ADSIEDIT.MSC and go to the configuration container. Then choose Microsoft->Rtc Service->Topology Settings->go to the properties of the GUID object here. the GUID should be the topology settings. Look for the attribute editor object MSRTCSIP-BackEndServer. this object may already have been set by a previous installation. This is a very difficult item to troubleshoot because you may not have been the person who did the initial install. You wouldn’t necessarily know the setting was there.
The easier way to deal with this is to run get-CSManagementStoreReplicationStatus. this will return the value to compare to verify this is not the correct location. then run Remove-CSConfigurationStoreLocation. That’s it!
Now realize, that when you do this, you are effectively breaking you deployment. The Topology builder will re-publish and the Configuration wizard will likely run and install new databases, but realize what you may have done. You may have a new deployment, and old objects in AD that are no longer valid. This is likely to come up somewhere in your deployment. So in the end things are working but not how you like. So now, how you might try to get our of that situation. By the way, I would say Microsoft would call this install toast. But I know how you are, you want this working, and your not killing the only AD you have!
Now you can connect when you run the Topology builder. The topology builder first run is very important as it adds this AD attribute if it doesn’t already exist. The means that if the topology builder had been ruin and the decision was made to wait and install Lync later, this would be the case where you find this problem.
ADSIEDIT to remove AD objects in lync or at least find them
The location to be familiar with is the RTC service in Active Directory. The location is adsiedit.msc then configuration partition->services->rtc service->global settings. you see this isn’t a friendly place in figure 1
You really need to use ldp.exe to see the objects any deeper. To really get to where you can see, run start->run->ldp.exe
Choose (connection) bind as a valid user
go to view-> tree->select the default DN
Go to the same location in LDP the you looked at in ADSIEDIT.msc. (double click in ldp). You will see the same three guids there. However, this one is searchable
Right Click the global settings and click search————————————————————-
Use the filter field to enter (msRTCSIP-TrustedServerFQDN=lync.1domain.com)————–
And…the results will show you the attributes for that object in Adsiedit. if you see the object is not part of Lync you can delete it here as well————————————————
Errors in publishing topology like TLSTARGET
So this was an exercise to just figure out how to see the objects and potentially find objects that need to be deleted. However, the skill is used for a far more more useful purpose. The example I have is having Lync installed and the services did not install correctly. the services installed with an old server FQDN attached to the service. the tipoff was in the failed topology publish. the error made reference to the object TlsTarget.
I searched forever and no luck. Ultimately, one of my customers was better at AD then I was. I expressed what I was looking for and he drove the ldp queries. For future reference, the Lync TLS Target is likely a service attribute. we went into LDP at the level of services and ran the search
- Base DN – CN=RTC Service,CN=Services,CN=Configuration,DC=domain,DC=com
- Filter (objectClass=*)
- Scope “Subtree”
The results (on the right pane) should be copied to a notepad. then search for the term of the error. the search in this case was “TLSTarget”, see here:
The Dn for object is -b107dc04—33bd—44b3—a455—57082c76b9f1. Now go look for this object under services:
Also notice the the line where we find the tlstarget begins with the name of the object attribute- MSRTCSIP-Extensiondata. if we open this attribute, what do we expect to find? The object that would be from the old configuration
you can delete the object from adsiedit.msc or you can do it from ldp. This concludes a lesson on how to get to the AD attibute and how to filer it and delete it as in our TLS target example.