Authentication error after password update! TSM 6.3

okriss

ADSM.ORG Member
Joined
Nov 6, 2015
Messages
141
Reaction score
0
Points
0
Hi all,

i would like to ask some help!!

I have an sqlsched. cluster resource which is in failed state. (earlier on other server i set a virtual node for restore with flashcopy and i had to update password for that node, because flashcopy needed authentication and the password wasnt correct.. ...update node (new_password), i set the same password that was before.
Now the node which run active sql instances, cant authenticate with password, the cluster resource cant run, i cant run backup with flascopy manager, scheduled jobs dont start.

The dsmerror log give the message below, dsmschederrorlog is the same.

02/04/2016 17:52:58 ANS2050E TSM needs to prompt for the password but cannot prompt because the process is running in the background.
02/04/2016 17:52:58 ANS2050E TSM needs to prompt for the password but cannot prompt because the process is running in the background.
02/04/2016 17:52:58 ANS1029E Communication with the TSM server is lost.


I updated the password on tsm server (admin too), updated on client node with gui and with dsmc, CAD was restarted.
opt file is correct, because the password acces generate is being set.

What should i do? I tried everything what i can!

Thank you for help!!
 
I replaced this thread to TSM operation! I cant delete! ADMIN PLEASE DEL!
 
As the error says, there is a process running in the background. Stop any TSM backup process and try again.
 
As the error says, there is a process running in the background. Stop any TSM backup process and try again.

I checked every process with processexpolerer on the node, and canceled every session on tsm server what belong to this server.
Could be the problem with the other server (test environment) where we were done the test restore?....after the restore the server was restarted...
What should i check to background processes? I dont see anything!
On this active server we keep 8 sql instance and its have own schedule. Could that sessions the cause of my problem?
 
Could be the problem with the other server (test environment) where we were done the test restore?....after the restore the server was restarted...
With password access generate, if you login to that node on another machine that also has password access generate, it updates the password and screws up the original machine. On the test machine, use virtualnodename instead of nodename so that it doesn't screw up the password.

Basically what happens, is anytime you login to using that node on a different machine, you have to go log back in manually on the original machine to save the password again.
 
With password access generate, if you login to that node on another machine that also has password access generate, it updates the password and screws up the original machine. On the test machine, use virtualnodename instead of nodename so that it doesn't screw up the password.

Basically what happens, is anytime you login to using that node on a different machine, you have to go log back in manually on the original machine to save the password again.

Hi!

We used virtualnode parameter. After we can restore the backup, but after the original server gave failed.
When i realized it, i updated the password on tsm server and on the node, but the result was the same. (error message above).
Last night we can run a backup and some logbackup with flashcopy, but now we get the same error message and this:
ANS1025E Session rejected: Authentication failure

We think that the scheduled service doesn't store the password and it cause the problem! Earlier i havent got any problem after pass update!
Why cant store the password?
We did every password change methode what we found on the net, and those was succesfull password update in registry too), but we get the same error messages.
 
ANS1025E Session rejected: Authentication failure
That means wrong password.
  1. Do you have multiple option files? If so, do some have the password hard coded? They should all be set the same way.
  2. When you successfully login with the GUI with the new password. If you close the GUI, and re-open it, are you prompted for a password?
  3. Are you logged in as a local admin when entering the password in the GUI?
We think that the scheduled service doesn't store the password and it cause the problem!
That's right, the schedule service doesn't store the password, it just uses the stored password that was stored in the registry using when logging in the GUI or command line, or using using "dsmc set password".
 
That means wrong password.
  1. Do you have multiple option files? If so, do some have the password hard coded? They should all be set the same way.
  2. When you successfully login with the GUI with the new password. If you close the GUI, and re-open it, are you prompted for a password?
  3. Are you logged in as a local admin when entering the password in the GUI?

That's right, the schedule service doesn't store the password, it just uses the stored password that was stored in the registry using when logging in the GUI or command line, or using using "dsmc set password".

I had to write the password everytime when open dsm. Every tdpsqlc query failed with authentication error, but if i fill the -tsmpassword with the appropiate password, it worked very well.
We have multiple tdpsql cmd file to run backup.

......But i think we could solve the problem.
In registry we didn't find the password key, because the failover cluster resource had wrong set ( ithink).
We had to update password with dsmc and after we had rerun the Add-ClusterCheckpoint ps script for the appropiate reg. folder therefor we are able to bring online the scheduler resource! Backup runs, everything is green.
I'm happy!

Thank you for your help! ...Again! :)
 
Back
Top