Environment:
Server: TSM 4.1.0.0 running over AIX 4.3.3.0 ML6
Clients: Mostly TSM 4.1.x running over either NT4SP5 or AIX 4.2.x or 4.3.x

Since we upgraded to TSM from ADSM 3.1 in April, we've found great benefit
(for security and troubleshooting purposes) in the admin command logging on
the server, i.e. "ADMIN PSYCHO issued command DELETE DATABASE".

We were hoping to implement another feature new to us, namely named admins
(such as Help Desk personnel) who had AUTHORITY CLASS=node NODE=whatever to
allow them to do restores on selected machines for us.

In experimenting with this functionality, though, it appears that the
analogous logging doesn't exist for sessions accessed via a node admin
through the web interface. Worse (from our perspective) the server log
doesn't even report that it was a node admin that logged on unless there's
an error (i.e. a bad password), rather everything is listed under the TSM
node name. We were hoping (and, according o our fuzzy memories, led to
believe by a visiting consultant) that the same thing would be logged, i.e.
ADMIN HELPDESK.SMITH issued command RESTORE C:\MyFiles\Stuff\*. Have we
missed a "verbose" option somewhere?

We see the local logging on the client node. This is somewhat better, as it
logs the specific admin. It still doesn't seem to track what they were
attempting to restore, though. And, even if it did log the specifics of the
restore in a log on the client, a plain text local log is much more
susceptible to tampering to cover one's tracks than if that information was
sent to the server, which would presumably be more tightly secured.

If this isn't the designed functionality, it seems that it should be. From
our perspective, it would be most helpful (again, for security and
troubleshooting purposes) to be able to have logged who is doing backups
(and especially restores), what they're restoring, and where (to what
node). If TSM considers itself to be an enterprise solution, managing all a
company's data, including any amount of material that would be considered
proprietary or otherwise desirable to be tightly controlled, this level of
logging, to a central server, would seem a most obvious and basic component
of its operations.