The list of APARs fixed in 4.2.1.26 that comes with the README file
packaged in the client is not quite accurate. The README file on the FTP
site correctly lists IC32379 and IC32797 (both with corrected abstracts)
as being fixed in 4.2.1.26. I apologize for the confusion. However, as far
as I can tell, there is nothing in 4.2.1.26 that isn't in 4.2.1.20 that
would address your problem. But staying on 4.2.1.26 is fine.
It would help to know what your dsm.opt file looks like. However, when
just trying to get basic function to work, I like to take a very basic
approach. In your case, I would probably try something like this:
1) Make a copy of your current dsm.opt file, then edit dsm.opt down to a
very simple configuration, like this (use NOTEPAD, not the client
preferences editor or setup wizard):
COMMMETHOD TCPIP
TCPSERVERADDRESS your.tsm.server.address
NODENAME yournodename
PASSWORDACCESS GENERATE
That's it; nothing more, nothing less. Don't get fancy. :-)
2) From an OS command prompt, change into the directory where TSM is
installed (where dsmc.exe is located). On most machines, the default is
C:\Program Files\Tivoli\TSM\baclient. Depending on where you installed
TSM, your configuration may differ.
2) Run the command DSMC QUERY SESSION. If you can establish a session with
the TSM server, then your basic options file is configured correctly.
3) Run this command:
DSMC S DSM.OPT
Verify that the file backs up correctly.
4) Now run this command:
DSMC RESTORE DSM.OPT C:\JUNK.TXT
Verify that the file restores correctly. You can delete C:\JUNK.TXT, as it
isn't needed any more.
Note that while seemingly trivial, steps 3 and 4 above are useful in
validating at least basic function (you need to be able to walk before you
can run).
5) Now try this command:
DSMC BACKUP SYSTEMOBJECT
Does the command work? What does the output look like? If it works
correctly, it should run for a few minutes, as it will back up all of the
system files.
If the command fails or complains about something, try this command:
DSMC SHOW SYSTEMOBJECT
This will show you the state of all the Windows 2000 system objects you
have installed (such as registry, active directory, RSM, etc.). What does
this output look like? Also, look at dsmerror.log: what is in that file?
The above steps should help get you started on understanding what is and
is not working on your system. If you continue to have problems, you can
post the results of the above steps to ADSM-L, and we'll see what we can
see.
If the above works just fine, then try reinstating your previous dsm.opt
file and repeat the steps. What are the results?
If the previous dsm.opt file works alright, then perhaps the problem is
with the scheduler configuration. That is a bridge that can be crossed
when we get there.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Steven Bridge <ccaasub AT UCL.AC DOT UK>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03/08/2002 06:01
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Problems with latest Windows client
We have just started installing the latest Windows client 4.2.1.20
on 'new' Windows 2000 machines and and have come across a number of
problems and peculiarities.
I saw just recently on the list that there is a new patch level 4.2.1.26
but looking at the 'IP22373 26 READ1STC.TXT' it doesn't include any
additional APARS than the README for 4.2.1.20.
Can anyone tell me what fixes are included in this other than
IC32797 which addresses memory problems ?
4.2.1.20 has been running OK on a couple of machines - but another
is having trouble backing up the system object. The client scheduler
initiated by the Client Acceptor service was being started at the
appropriate time but was dying and being restarted every 10 minutes
only to die again. 'q files' on the server indicated that the system
object was being backed up every 10 mins. I removed 'domain systemobject'
from the opt file and this worked fine.
So I tried backing it up via the GUI and went through each system object
in turn ( COM+DB and Event Log had backed up OK via the scheduler
according to restore info ) Registry and RSM were OK but 'System Files'
caused the GUI to die. I couldn't find any error messages either in the
Event Viewer or in dsmerror.log.
Previously we had assumed that the registry was always backed up with
the incremental command - and the documentation implies the option
'backupregistry=yes' is the default when the system disk is being backed
up.
Even when supplied it appears to have no effect.
We've found that this is no longer the case in the 4.2 client - hence the
'domain systemobject' line now being in our revised basic opt file.
Playing around with the GUI preference editor, I noticed that changing
the drives that you wish to backup also had the unfortunate consequence
of removing 'systemobject' from an existing domain line even though
the registry backup box was ticked ( Presumably this just affects the
backupregistry setting which as I've said above appears to be ignored ).
So moving to this new version has not been the easy ride I had hoped.
I'm reluctant to stay with 4.1 but so far not so good.
+----------------------------------------------------------------------+
Steven Bridge Systems Group, Information Systems, EISD
University College London
email: s.bridge AT ucl.ac DOT uk tel: +44 (0)20 7679 2794
|
