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.
