We have upgraded a TMS installation from 13.0 to 13.2.2 - we are using TMS Agents to provisiong Movi users and have a database of over 100 users all manually created
After the upgrade when trying to access the TMS Provisioning Directory we get the following error:
In TMS Agent Diagnostics we also see these errors:
If we try to disable and re-enable the TMS Agent on the VCS it fails both on disable and renable with the following:
The event failed to complete. Details: Wrong username/password
We have uninstalled TMS and re-installed, tried rebooting several times, stopped/started the service
Nothing is fixing the issue
Please could someone help?
Hope you have a full backup, that would be the easiest way to revert the state, a vm snapshot + sqldb dump is always helpful!
Did you had TMSPE installed, even if it was not usded? There seems to be a bug which kills the provisioning,
not sure if this is related to what you experiance.
If its a wrong username password, was there a password set up for the replication?
Did you try to clear the replication and revert to a older backup?
Depending on what is causing the isssue a tms-agent-tms backup would be handy, do you have that in place?
You should consider opening a TAC case for it if you need direct help.
Please remember to rate helpful responses and identify
Yes we did do a TMS Agent Backup from TMS
TMSPE has never been installed or attempted to be installed.
I try to reset the passwords in TMS, but I get an "Unexpected error has occured"
I have also raised a TAC case, but was hoping someone might know the answer here quicker, as getting a resolution from TAC may take a few days...
This issue is relatively easy to fix if you are hit with the issue I think you are which is 95% of the times.
First open the OpenDS control panel, you know where this is right? Verify that the password is set to the default one which is TANDBERG uppercase.
If it is, Go to the c:\prgfiles\tandberg\tms\wwwtms\data\tmsagent
Rename the app.config to app.config.bak.
Restart the TMSAgent Service.
If its not TANDBERG you have to reset it.
Open command prompt
2. Go to the OpenDS-2.0\bat directory:
3. Run this command:
encode-password.bat -s SSHA512 -c TANDBERG > C:\ENCPASSWORD.txt
4. Stop the TMSAgents Windows Service, which will also stop the OpenDS Windows Service
5. Open the file:
6. Find the section:
dn: cn=Directory Manager,cn=Root DNs,cn=config
7. Replace the userPassword string with the sting in the ENCPASSWORD.TXT file (without the quotes)
8. Remove or rename the app.config file located in the following directory:
9. Start the TMSAgent Windows Service, wait about 1 minute and it will start the OpenDS Windows Service as well.
10. In the TMS Portal, go to Administrative Tools > TMS Agent Settings
11. Change the password fields to TANDBERG
12. Once the process is complete:
Stop the TMSAgent Windows Service, which will also stop the OpenDS Service
13. Remove or rename the app.config:
14. Start the TMSAgent Windows Service, which will restart the OpenDS Windows Service
Run the diagnostics, make sure you have renamed the app.config.
Think of it like this:
TMS is trying to connect to the OpenDS server, the app.config contains the password and is the file TMS is using to authenticate to OpenDS. If you delete the file or rename it. TMS just use the default password TANDBERG.
So if you setup a new server the OpenDS password is TANDBERG. If you have changed the password on the old server and take a backup. The backup file will contain a app.config file containing the custom password.
When you load the backup on the new server it will tell the TMS to use the app.config and authenticate to OpenDS using that password but loading the backup does not change the password in opends so TMS trying to authenticate with an invalid password. By deleting app.config. TMS will authenticate with TANDBERG which opends will accept on the new server. Once authenticated you can change the password from the TMS GUI. (the old password needs to be correct in order to change it to a new) which is why you are getting an unknown error when trying to change it.
So we need to establish. is it the opends that has the custom password set and TMS is using the default one, or vice versa? then we need to fix it.
Thank you magnus, this looks like its resolved the issue, I'm just waiting for customer to test and confirm but we are no longer recieving problems with agent diagnostics and replication looks good
Just went through your procedure on a TMS 13.2.1 ( stuck there because of server) and I am still getting the Error Connecting to local LDAP when I access Provisioning > Directory.
Any thoughts of what I need to check?