Richard, YOU GOT IT ! ! ! !
If you have clients that were registered prior to the level that
automatically created admin id's and those clients still don't have ids...
you get the blah 53.
I just took a box that was causing problems... registered an admin, set the
auth, and tried a client session.
FIXED !
So for each client that doesn't have an admin id...
register admin client_node_name client's_pswd
(I have client password access of prompt)
then
grant auth client_node_name class=node auth=owner
node=client_node_name
so say your node is AIXSRV01 with pswd of tsmpass01
register admin aixsrv01 tsmpass01
grant auth aixsrv01 class=node auth=owner node=aixsrv01
Whew...
Thanks Richard.
later,
Dwight
-----Original Message-----
From: Richard Sims [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 04, 2001 8:21 AM
To: [EMAIL PROTECTED]
Subject: Re: cuSignOnResp
>I've got the message
>07/01/01 21:30:45 cuSignOnResp: Server rejected session; result code: 53
>in dsmerror.log every time on every clients.
>Few months ago I asked IBM/Tivoli for help ....without success.
That's very sad. If the people who created the software say "I dunno"
when you ask for help on a straightforward problem like this, I would
have your management talk to their management about the meaning of support.
(Note in particular that this very error message has been present in the
product since 1996, if not earlier.)
But what underlies the message - which has been plaguing a number of
customers?
Dwight Cook yesterday posted a clear description of how it is occurring in
his
sessions, which shows that it occurs even in simple cases, non-scheduled.
Postings thus far have cited the client error log, but I haven't seen info
as to whether there are any corresponding server Activity Log messages,
which may explain what's happening.
If these instances involve clients with Passwordaccess Generate in effect,
I would look into any irregularities with the password storage area in the
client, and change the password.
(The Result Code 53 seems to correspond to the API Return Code
DSM_RC_REJECT_ID_UNKNOWN. See Messages manual.)
Another thing comes to mind... As of ADSM 3.1.2.1, whenever a Register Node
is performed, a node administrator userid is automatically defined, having
the same name and password as the node being registered. I'm wondering if
this is involved in the secondary session that everyone is seeing; and if
something happened to the admin id (maybe renamed or deleted, or a Lock
Admin
in effect?), or its password is inconsistent, perhaps that is behind the
error. I'll be very interested if affected users find anything in this
regard.
Richard Sims, BU
