With IBM PCs&NetVistas comes very nice tool - ConfigSafe. It allows to
track registry additions/deletions/changes, same for DLLs, ini-files
entries, etc.
If you have ANY such computer, you can make a "snapshot", install the
client (or any other program) and compare results. Even you can create
report for printing or save it as text file. I used this approach in
Win9x, NT & 2k with success.
This is way I am checking what registry keys/values & files a program
alters on install. Sorry, I've never did it for TSM client. Others may
have other solutions.
Zlatko Krastev
IT Consultant
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: NT client upgrade problem
We are seeing strange problems attempting to upgrade the client software
on
one of our Windows NT systems from 3.7.0.0 to 4.1.2.12. We have the
self-extracting install package (IP22151_12.exe) located on one of our
Windows file servers. We have used this copy of the install package
successfully for many installations and upgrades.
The first attempt to upgrade the problem client may have complained of
inability to access some files (the system administrator's memory is
somewhat vague on this point), but continued to the point of asking
for permission to reboot. The administrator agreed to this, and the
system failed with a blue screen of death while rebooting.
The administrator subsequently created a recovery partition. He installed
the 4.1.2.12 client in the recovery partition using the same install
package mentioned above.
The administrator then made another attempt to upgrade the TSM client
software on the production partition. This time the installer reported
that it did not have the necessary rights for the following:
adsm32.dll, adsmv3.dll, comcat.dll, dsmntapi.dll, mfc42.dll, msvcrt.dll,
and tsmapi.dll
The system then failed with a blue screen of death before the installer
requested permission to reboot. The administrator booted from the recovery
partition, examined the production partition, and found that all of the
files listed above had sizes of 0. He copied these files from the recovery
partition to the production partition. This made it possible to boot the
production partition successfully, but the TSM scheduler service would not
start. The server log does not show even a connection attempt from the
client system.
The administrator is now proposing to remove all traces of the 3.7.0.0
client and then install 4.1.2.12. Because of the convoluted history, he
does not trust the uninstall utility. He has asked me for a list of
files and registry entries created by ADSM or TSM, with the idea of
removing all of these manually. This idea makes me very nervous.
Does anyone have any suggestions for cleaning up this mess? The client
system is a production server, so we need to keep the number of reboots
within reasonable limits.
|
