Wouldn't it be easier/cleaner to just delete the "bogus" admin name? I
have noticed when you register new clients, that if you don't type in NONE
where it says
By default, an administrative userid will be created for accessing the
client remotely. Specify NONE, below, if you do not want this userid to be
created; or, another administrator's name if you want that administrator
to have OWNER access over the node.
User ID for remote Access
then it will create an id the same as client name-- and your admin list
will get really cluttered. I have just deleted them, and haven't noticed
any thing adverse .
Dwight-- you say .."prior to the level that automatically created admin
id's".. is this fixed in 4.1?
thanks
lisa
"Cook, Dwight E" <[EMAIL PROTECTED]>
07/05/2001 10:45 AM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc: (bcc: Lisa Cabanas/SC/MODOT)
Subject: Re: cuSignOnResp (SOLUTION ! ! !)
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
