We are seeing strange problems attempting to upgrade the client software on
one of our Windows NT systems from 184.108.40.206 to 220.127.116.11. 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 18.104.22.168 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,
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
The administrator is now proposing to remove all traces of the 22.214.171.124
client and then install 126.96.36.199. 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.