Local TMS Agent fails - OpenDS Authentication

[Wintershall]

We are struggleing to get our VCS and TMS talking again.

Looking at various logs we have decided that there is a problem with the OpenDS component.                   

Running a Diagnostic against the local agent seems to confirm this.

If OpenDS is not available, the TMS Agent will not function properly.
If OpenDS is not running, please re-start the server. If an authentication failure is reported, please read documentation on how to re-cover from such a state.Error details from TMS Agent:
cn=Directory Manager could not authenticate with OpenDS

WHERE in the documentation can I find the information on how to recover from this state?

Its also manifesting itself if we try to set the LDAP password.

In the openDS access.log  we see:

[16/Oct/2012:15:27:37 +0200] CONNECT conn=240 from=127.0.0.1:60579 to=127.0.0.1:389 protocol=LDAP

[16/Oct/2012:15:27:37 +0200] BIND REQ conn=240 op=0 msgID=1 type=SIMPLE dn="cn=Directory Manager"

[16/Oct/2012:15:27:37 +0200] BIND RES conn=240 op=0 msgID=1 result=49 authFailureID=196887 authFailureReason="The password provided by the user did not match any password(s) stored in the user's entry" etime=0

[16/Oct/2012:15:27:37 +0200] DISCONNECT conn=240 reason="Client Disconnect"

Any suggestions?

[Magnus Ohm]

Hi

Go to c:\progfiles\tandberg\tms\wwwtms\data\tmsagent

Rename the app.config to app.config.bak. Restart the tmsagent service.

This should resolve the issue at least on the local tmsagent. I dont know about your vcs but lets take one thing at the time.

/Magnus

Sent from Cisco Technical Support iPhone App

[Wintershall]

Thanks,

That fixed the local TMS Agent.  Its Diags now pass. 

My next problem is that the local agent is the only one listed in the TMS Agent browser. 
How can I get our VCS listed? 

The VCS is listed in the System Navigator, and indicates a TMS Agent Critical Error. 
Under TMS Agent on the VCS "Enable TMS Agent Data Replication" is un checked. 
Trying to enable its gives an error -
17/10/2012 09:22 - Unable to enable replication for 'winzvc001'. A DNS lookup of the TMS host name on this VCS does not match the TMS IP address.

We have already tried the procedure of stopping provisioning and opends on the VCS as detailed in

https://supportforums.cisco.com/thread/2164173 and
https://supportforums.cisco.com/thread/2136274

In the thread 2136274 they also have a similar issue.  He mentions that he puts the FQDN in the connection tab.  We already have its there.   
SSH'ing into the VCS and testing DNS (nslookup) gives no errors for the VCS or the TMS.  How can I check what hosts the VCS is trying to lookup? 

[Wintershall]

Ok,

Tried one more thing.  Removed the FQDN from the connection tab, saved and then pasted it back.  Saved.

Next tried to enable replication again.  This time I get a different error.

17/10/2012 10:25 - Event Created
17/10/2012 10:25 - Event executed by WINZAP036
17/10/2012 10:25 - TMS agent data replication will be set up for the following system(s): winzvc001
17/10/2012 10:25 - Reading local TMS agent status
17/10/2012 10:25 - Reading TMS agent status on 'winzvc001'
17/10/2012 10:25 - Clearing replication setup on 'winzvc001'
17/10/2012 10:26 - Writing TMS agent settings to 'winzvc001'
17/10/2012 10:26 - Setting up LDAP data replication between the local TMS agent and the TMS agent on 'winzvc001'
17/10/2012 10:26 - Setting up LDAP data replication failed
17/10/2012 10:26 - Failed to enable TMS agent data replication for 'winzvc001'
17/10/2012 10:26 - The event failed to complete. Details: TMS agent data replication setup failed for the following system(s): winzvc001

But at least the VCS is now in the TMS Agent diagnostics list.
Runing All diagnostics gives an error.

If the VCS IP address isn't in the Local TMS Agent list of replicating agents, replication will fail.
TMS agent data replication is enabled for this TMS Agent, but the network address of this VCS was not found in the list of replicating agents read from the local TMS agent. If you have recently enabled data replication for this system, please wait and refresh after the background event on the TMS Server setting up the replication has finished. If not, try to reenable the replication by turning if off and then back on again for this VCS in the System Navigator page under the TMS Agent tab. You should perform a "Create TMS Agent backup file" on each VCS peer BEFORE disabling and re-enabling data replication.

Error details from TMS Agent:
System IP (10.122.249.80) or host name (winzvc001.wintershall.nl) not found in list of replicating agents.

Any suggestions?

[Wintershall]

Aargh..

Following through the thread https://supportforums.cisco.com/thread/2136274,  mguguvcevski  describes a similar error. 

So I diasabled replication, and stopped and started provisioning and openDS.  Im now back at the DNS issue.

Unable to enable replication for 'winzvc001'. A DNS lookup of the TMS host name on this VCS does not match the TMS IP address.

[Magnus Ohm]

Hi

Did you check the FQDN configured on the VCS through an NSLOOKUP on the TMS server that the TMS server is able to resolve that address to the correct IP?

Also on the TMS server does the TMS server have an FQDN, i.e is the server part of a domain? You should be able to do an NSLOOKUP on the VCS from the root interface as well to see what the VCS actually resolved. I don't know the background here, for example did you switch domain or did you migrate windows servers?

Since the TMS FQDN is contained in the TMS database, i.e if you restore the database this field:

Does this match the actual server FQDN? And most important does it resolve? Does the VCS use a different DNS server than the TMS server?

It's not the worst error that you can get...

/Magnus

[Wintershall]

Testing using nslookup on the VCS as root gives the correct results for the hostname and the full dns name for both the vcs and the tms names.  It also gives the correct results for the reverse. 

Testing using nslookup on the TMS also gives the correct results for the hostname and the full dns name for both the vcs and the tms names. It also gives the correct results for the reverse.

The TMS is in a domain. and uses the same dns server as the VCS.

The entry for the "TMS Server Fully Qualified Host Name" under aministrative tools\configuration\network settings is correct and matches the A record for the server and also the servers actual name.

For a bit of background:

TMS 12.6 Server needed replacement.
New server created with a different name. Before installing TMS a backup of the database on the SQL Server was made and restored onto a newer SQL Server.
Also a backup of the TMS agent had been made.
Installation of TMS had been done onto the restored database which was upgraded during the TMS installation (now 13.1.2).
New server renamed to original name. TMS Agent was restored onto the new server.
VCS was not responding to HTTPS so restarted the HTTPD service which is mentioned in the install/upgrade guide.
OpenDS problems started to occur.

[Magnus Ohm]

Hi

Take a look at this document:

https://supportforums.cisco.com/docs/DOC-23654

If you are unable to resolve this I would recommend a TAC case since they should be able to efficiently get this back to normal operation

/Magnus

[Martin Koch]

As much as I personally dislike TMSPE because of some limitations for our deployments, you find my comments in the forum). It can be still in many deployments quite useful.

If you have the local tms agent in a state which is ok, I would check that it has no external hosts in the replication list,

no errors TMS agent diagnostics and then just see to upgrade to TMS13.2, X7.1 and use TMSPE end the

migratiion tool to get the data over and use the provisionig extension on the VCS.

OpenDS can sometimes be a pain in the $%&/. It helps if you would know the system internals how it works.

Maybe you should ask a partner or TAC to help you in a on site or online session.

[daleritc]

Now, now Martin let's be constructive and not let our personal feelings come into things. At the end of the day, we're not talking about 'nukes' or 'hand grenades'

And since your reputation procedes you and your well known by all of us here in the Oslo BU and we all greatly appreciate your thoughts, ideas, feedback and challenges that you provide to us, let's be honest and open with the audience here when it comes to both Legacy TMS Agent and TMSPE....meaning you do come at this from a Service Provider point of view and both Legacy TMS Agent and TMSPE were not designed as Service Provider tools. In fact, I believe you've asked these questions to TMSPE developers during tech meetups locally here in Norway and that is the messaging you have received from them as well.

Now that doesn't mean that we don't expect Service Providers like yourself to find inventive ways to sell services to customers using our product but I'm just being totally up front in stating that this particular tool was not designed or scaled to fit into service provider environment and this is probably why I think/believe you have this current 'dislike' for product...meaning Legacy TMS Agent did have a bit more flexibility in it, if you could get passed the challenges with OpenDS and multi-replication model...but TMSPE (and unfortunately for you) has taken away some of that flexibility. However, it's been a huge success to those business customers who are maintaining and managing their own provisioning solution deployments themselves...which is what both products were specifically designed to do.

Again, alway appreciate your input and look forward to meeting up with you sometime here in Norway.

cheers,

Dale

[amit.kak1]

Hi,

Getting below issue

6/19/2015 3:00 AM - Event executed by PETHOU-VAP001

6/19/2015 3:00 AM - The event failed to complete. Details: Unable to connect to the local TMS agent

c:\progfiles\tandberg\tms\wwwtms\data\tmsagent

found PrecompiledApp.config instead of app.config........ i did : PrecompiledApp.config.bak

In services i coundn't find local tms agent ..... Found backup agent

Kindly suggest what to do....

[Magnus Ohm]

It will resolve the issue assuming the local opends has the default password set. Just to make that clear. :) it will be default if you reinstalled tms and then reloaded an old backup and after that this issue occured

Sent from Cisco Technical Support iPhone App