You get a second new filespace on the server. Confusion & waste. At 03:06 PM 6/7/2011, Hughes, Timothy wrote: >What happens if you don't rename the filespaces at the same time period of a >machine rename? > >regards > >-----Original Message----- >From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Paul >Zarnowski >Sent: Tuesday, June 07, 2011 2:31 PM >To: [email protected] >Subject: Re: TSM & client machine renames > >Thank you for all of your suggestions. > >To answer some of your questions: >- The nodename is usually specified in the dsm.opt, not defaulted from the >machine name; >- Our nodenames are generally NOT related to the machine name (but this may >change as a result of our AD reorg); >- We do not have central administration of all of our desktop systems, so we >cannot "reach in" to each system from one central location (again, this will >likely change AFTER the AD reorg, but that doesn't help me now); >- Most of our systems use Scheduler Service, with a smaller percentage using >CAD; >- We have no standard disk configuration, so cloptsets are probably not a >solution. > >Here is what I think we need to do: > >For each machine being renamed: >1. On TSM server, rename filespaces at same time period as machine rename >(before the next daily backup runs); Preferably have tool that will allow us >to trigger this rename remotely, in a secure manner; >2. On client system, edit the dsm.opt file and change any references to >machine names to have the new machine name (e.g., in DOMAIN, INCLUDE, or >EXCLUDE options); >3. IF the TSM nodename is being renamed, also on client system modify the >registry entries to change the old nodename to the new nodename; Uninstalling >and re-installing the scheduler will be cumbersome, so we will be looking for >a script that can do this quickly; I'm also hoping to avoid a password >re-seed. I don't know (yet) if we will be renaming TSM nodes as part of this >exercise or not, but suspect we might be. > >..Paul > > >At 12:22 PM 6/7/2011, Huebschman, George J. wrote: >>Paul, >>Regarding the characteristic where the TSM Scheduler remembers the nodename. >> >>For Windows: >> >>" The service seems to remember the node name in effect when the service was >>created, even in the absence of a 'nodename' option in dsm.opt. I don't know >>whether there is a way to change the node name the service uses; we advise >>client system administrators to remove the service and create a new one when >>a Windows system is renamed." >> >>** Your way of fixing this is best; uninstalling then reinstalling the >>scheduler. ** >> >> There is a registry entry for the TSM Scheduler service that contains >> the node name. I used to have a problem with some of the new Windows >> servers that came into TSM MISSing their backup for authentication reasons. >> A Windows admin eventually told me why and their way to fix it. >> In our case, the servers were all built from the same image. They >> all had the same machine name. When TSM was installed and the Scheduler set >> up and tested, it was under the standard "build" nodename. Subsequently, >> before the machine went into production, it was renamed. Sometimes the >> nodename in the dsm.opt file was changed, but authentication still failed. >> >>The Windows folks used to edit the Registry entry for the TSM Scheduler >>service...but your method is much safer. >> >> >> >>-----Original Message----- >>From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of >>Thomas Denier >>Sent: Thursday, June 02, 2011 3:20 PM >>To: [email protected] >>Subject: Re: [ADSM-L] TSM & client machine renames >> >>-----Paul Zarnowski wrote: ----- >> >>IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason >>therefore recommends that you do not send any confidential or sensitive >>information to us via electronic mail, including social security numbers, >>account numbers, or personal identification numbers. Delivery, and or timely >>delivery of Internet mail is not guaranteed. Legg Mason therefore recommends >>that you do not send time sensitive or action-oriented messages to us via >>electronic mail. This message is intended for the addressee only and may >>contain privileged or confidential information. Unless you are the intended >>recipient, you may not use, copy or disclose to anyone any information >>contained in this message. If you have received this message in error, please >>notify the author by replying to this message and then kindly delete the >>message. Thank you. > > >-- >Paul Zarnowski Ph: 607-255-4757 >Manager, Storage Services Fx: 607-255-8521 >719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [email protected]
-- Paul Zarnowski Ph: 607-255-4757 Manager, Storage Services Fx: 607-255-8521 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: [email protected]
