Hi Bill,
A few things to check:
1) Verify that all the .exe, .dll, and dsc*.txt files in your
..\tsm\baclient directory have the same timestamp on them (or
at least within a couple of seconds of each other).
2) Verify that adsm32.dll, adsmv3.dll, dsmntapi.dll, dsmutil.dll,
dsmw2k.dll (if Windows 2000), and tsmapi.dll all have the same
timestamp as the files in #1 above.
3) Verify that if your run DSMC SCHEDULE in the foreground (while
logged on) it works okay.
4) Assuming that all of the above check out okay, try configuring the
scheduler service to use the local system account. Also, don't do
anything else fancy; just use dsm.opt located in ..\tsm\baclient.
Make it as basic as possible. For now, don't bother with any kind
of pre- or post-schedule commands, include/exclude lists, or any
other options not necessary to test the basic function. For
example:
commmethod tcpip
tcpserveraddress your.tsm.server.address
passwordaccess generate
nodename yournodename
schedmode prompted
"nodename" and "schedmode" are not necessary if you are already
using the default values of the local machine name and "polling",
respectively.
If this works, then the problem may indeed be related to the
particular account your administrators assigned you, or something
else in the configuration. Sometimes this "back to basics" approach
can be useful in identifying the problem. At the ver least, it
eliminates a lot of variables.
If this still does not work, then you should open or re-open your
PMR with Tivoli support and work with them with the "back to basics"
configuration above (then they can't blame your setup, unless the
NT administrators did something to disable the local system account).
I am not clear if the inability to back up the registry results in
the Dr. Watson errors, or if those are two separate conditions. At
any rate, the client should not be crashing; if it is crashing, then
that also needs to be addressed. Insist on going to Level 2 support
if Level 1 isn't able to move this along (a crash should go to Level
2 unless Level 1 can find a "hit" amongst known problems), and Level
2 can engage development if necessary.
Regards,
Andy
Andy Raibeck
IBM/Tivoli
Tivoli Storage Manager Client Development
e-mail: andrew.raibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."
I have 15 NT clients at 3.7.2.01. I installed the TSM client code myself
on each system with an id that was set up by the system administrators.
The problem that I am having is with backing up the registry on four of the
15. I originally set up all of the clients to run incremental backups
through the services using dsmcutil install. Four of the NT systems were
failing every day and were getting Dr. Watson's errors. I went through and
added the backup registry no parameter to these four systems and set up
separate schedules to run the registry backup as a command. The registry
backup continues to fail as a scheduled process. I contacted TSM support
and they felt that it was a permissions issue even though I can
successfully run the backup manually. I contacted the system
administrators and they can not find any difference between these systems
that work and those that don't. I can log into the NT systems and execute
the same command to backup the registry as the scheduler executes. The
following is the error message that I am getting in dsmerror.log from the
scheduled backup:
09/12/2000 20:58:40 ANS1228E Sending of object 'C:' failed
09/12/2000 20:58:45 ANS1435E An Error Occurred saving the Key.
09/12/2000 20:58:45 ANS1428E Registry Backup function failed.
Does anyone have any ideas on this problem? What can I have the system
administrators do to set up the scheduler so that I can pinpoint the
permissions problem? If the system administrator stops and starts the
service, does that take on their permissions?
Thanks in advance,
Bill Sherrill
Analyst International Corporation
|
