Our policy has been to lock admin accounts rather than remove them. Is
this viable for you?
On 07/08/10 05:10, Nick Laflamme wrote:
My current shop has a collective memory of "bad things happening" when old
Admin userids are removed from TSM servers. Memories are a bit vague, and all of us have
Thanks for the responses, people. Fortunately, we've been implementing
centralized management slowly, and as a byproduct of that, the administrative
schedules have all been updated recently by current staff members. The rest of
the issues, like scripts outside of TSM that query TSM, have been an
An auditor-mollifying measure could be to perform a REName Admin to change it
to a 64-character name of relative gibberish, pending full extrication of the
old administrator.
Richard Simswith my name in everything, for job security
Good luck with removing the admin id.
My main co-admin is no longer employed with us. Thus his admin id touched
lots of things. At first, I was not able to delete his id. Every time I
tried to delete it, I got some kind of error that it was still in
needed/in use (or something like that). From
I think if you remove the admin that defined an admin schedule, the schedule
fails.
When the admin schedule runs, note it says the defining admin "issues" the
command:
ANR2750I Starting scheduled command DAILYCHECKIN ( run
checkin ). (SESSION: 31664)
ANR2017I Administrator XX issue
The side effect of removing admins is that any administrative schedule last
touched by them will not be run if their account is removed. Run the command "q
sched type=admin f=d" and look at the "Last updated by (administrator)" field.
Make sure that the last admin to touch it is not the ones you
The only side effect I have had is when you remove the admin for an AIX node.
The AIX node had password issues and would not run the backup consistently.
This probably has to do with how we run backups on AIX.
We have not seen any problems removing "people" admins from TSM.
Andy Huebner
-
