Could you please check and let us know the if there is a list of special characters which is not supported by Pulse v6.0.5 for passwords. As we have few generic account that are used for connecting with the tm1 instances for document/change tracking and their password is auto-rotated every few days for security purposes.
Sometimes, after the rotation of password they are unable to connect with the tm1 instances in v6.5.0 whereas the same credentials works for the same generic account in the Pulse v5.8.0
Can you give further details on what do you mean by auto-rotated? What is your usual process? Do you mean, every month for example, you go into Pulse’s Instance Settings page and change password from there?
Auto-rotated as in there is a script which runs every few days and it changes the password of the generic account at backend. Once the password is rotated, we manually fetch the password through our process and then we update the new password on the Pulse web client in the instance settings → Document/change tracking section
The same updated password & generic account user id combination works on the Pulse v5.8.0 web client but it does not work for Pulse v6.0.5 web client.
How are you updating the new password into the Instance Settings? By going there manually? Or do you mean, you have automated ways of doing this?
As for the new credentials, we would suggest to go into the pulse.log file to check what is the message being returned when you click on the Save button on the Instance Settings page.
We are updating the password into instance settings manually.
This is the message being returned when clicking on the save button (it also contains the servername\instance name, which has been removed)
There could be some other underlying issue. The technologies of how they are being authenticated differs between Pulse 5 and 6.
With Pulse 6, it is now authenticated through the REST API.
Perhaps a quick check would be, depending on if you are using IntegratedSecurityMode 1, you can check from the browser if you are able to login into that instance given the new credentials that you have.
For example, if that TM1 server is configured with its HTTPPortNumber as 8882 and is running at IP X.X.X.X, then try to access the following URL, and use your updated credentials to see if you can log in.
If you are not able to login as well from there, this confirms the issue at hand already, and is something to do with the REST API of TM1 not recognizing those credentials yet.
