Thomas, One other thing. You mention that you have actually managed to complete this method successfully with 5.1.x.x and 5.2.x.x code. Bear in mind that there were a number of bugs with the early levels of code regarding the backup of W2K system objects. So while it may have worked for you, there may have been underlying problems for others, which have subsequently been solved, but unfortunately have scuppered your internal DR procedures.
I really think that your only option is to build a dedicated restore LAN segment and then use the original machine names for the Windows BMRs. Leigh -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Denier Sent: 24 January 2006 21:25 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] System object restore problem We just went through a disaster recovery test, using the following process for each Windows 2000 system involved: 1.Give the replacement system a different computer name than its production counterpart. 2.Execute a 'rename node' command against the recreated TSM database to change the node name matching the production computer name to a node name matching the replacement system computer name. 3.Execute 'rename filespace' commands to make the corresponding changes to computer names embedded in UNC volume names. 4.Restore the C drive. 5.Restore the system object. 6.Restore the remaining drives. At step 5 the attempt to restore the system object finished almost instantly, with no data movement. This was true whether the GUI or the command line client was used. The 'query systemobject' claimed that there were no matching files. I called IBM and was told that a system object cannot be restored to a system with a different computer name than the system that backed up the system object. We were using 5.2.6.0 server code under mainframe Linux. We were, in most cases, installing 5.3.2.0 client code on the replacement Windows systems (one Windows administrator tried the 5.1.5.0 client code and got the same results). Some of the original production systems had been running 5.3.2.0 client code, and some had been using lower client levels. Several of the Windows administrators confirmed my recollection that the process described above had been used successfully at our previous disaster recovery test 14 months earlier. We are then using 5.2.2.0 server code and a variety of 5.1 and 5.2 client code levels. This raises a number of questions: 1.Why did our test recovery process stop working? 2.Is there any way to get the process to start working again? 3.Nearly every book or article about disaster recovery emphasizes the importance of testing. Why did Tivoli introduce a restriction that seems to have been designed to make disaster recovery testing nearly impossible?