Cloned Win servers and multiple backups
This is a strange problem. Once in a while, our Windows support team will clone a Windows server. The clone will have the exact same TSM setup as the source server. I'm not familiar with the Win BA client, but it seems it always has a nodename line for the dsm.sys file, so the clone reports to TSM server that it's the same node as the clone source. They both appear to respond to the same schedule. This results in the new server performing good backups to the exact same node as the server that is the clone source. The end result seems to be to two different servers happily backing up the same TSM node. Obviously what we get is a useless mess. When they clone a system they are supposed to use a source without a TSM setup, or, clean out the TSM setup right away, but sometimes this doesn't happen. I've tried to find a way to detect this from the TSM server, but I'm not coming up with anything obvious. I'm interested if anyone else has fought this problem and what you've done. Thanks! Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Cloned Win servers and multiple backups
You can setup a regular search in the TSM server actlog for the following msgno (our specific data masked): Date/TimeMessage -- 05/05/2009 08:00:15 ANR1639I Attributes changed for node : TCP Name from to , TCP Address from 10.99.99.999 to 10.88.88.888, GUID from 99.99.99.99.99.99.11.dc.89.50.- 00.11.25.9c.28.2c to 88.88.88.88.88.88.11.dc.ab.82.00.1a- .64.59.35.68. (SESSION: 1277591 Steve Schaub Systems Engineer, Windows BlueCross BlueShield of Tennessee -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Rhodes Sent: Tuesday, May 05, 2009 8:12 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Cloned Win servers and multiple backups This is a strange problem. Once in a while, our Windows support team will clone a Windows server. The clone will have the exact same TSM setup as the source server. I'm not familiar with the Win BA client, but it seems it always has a nodename line for the dsm.sys file, so the clone reports to TSM server that it's the same node as the clone source. They both appear to respond to the same schedule. This results in the new server performing good backups to the exact same node as the server that is the clone source. The end result seems to be to two different servers happily backing up the same TSM node. Obviously what we get is a useless mess. When they clone a system they are supposed to use a source without a TSM setup, or, clean out the TSM setup right away, but sometimes this doesn't happen. I've tried to find a way to detect this from the TSM server, but I'm not coming up with anything obvious. I'm interested if anyone else has fought this problem and what you've done. Thanks! Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. - Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm
Re: Cloned Win servers and multiple backups
Rick - Oh, Windows administrators, and their peculiar view of reality... For your detection, from the TSM server: If they did not also clone the PC's IP address (!), then the GUID should be different for the clone, where message ANR1639I should be expected in the TSM Activity Log. Richard Sims
Re: Cloned Win servers and multiple backups
Rick, If your hostnames are unique in of themselves, you can leave the nodename out of the dsm.opt file. TSM will use the hostname for the tsm nodename. If you have clients with the name of xyz.abc.com and xyz.qxr.com then you would have a problem with this scheme. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Rhodes Sent: Tuesday, May 05, 2009 8:12 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Cloned Win servers and multiple backups This is a strange problem. Once in a while, our Windows support team will clone a Windows server. The clone will have the exact same TSM setup as the source server. I'm not familiar with the Win BA client, but it seems it always has a nodename line for the dsm.sys file, so the clone reports to TSM server that it's the same node as the clone source. They both appear to respond to the same schedule. This results in the new server performing good backups to the exact same node as the server that is the clone source. The end result seems to be to two different servers happily backing up the same TSM node. Obviously what we get is a useless mess. When they clone a system they are supposed to use a source without a TSM setup, or, clean out the TSM setup right away, but sometimes this doesn't happen. I've tried to find a way to detect this from the TSM server, but I'm not coming up with anything obvious. I'm interested if anyone else has fought this problem and what you've done. Thanks! Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Cloned Win servers and multiple backups
I think this only work if you had open registration. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Len Boyle Sent: Tuesday, May 05, 2009 9:09 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Cloned Win servers and multiple backups Rick, If your hostnames are unique in of themselves, you can leave the nodename out of the dsm.opt file. TSM will use the hostname for the tsm nodename. If you have clients with the name of xyz.abc.com and xyz.qxr.com then you would have a problem with this scheme. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Rhodes Sent: Tuesday, May 05, 2009 8:12 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Cloned Win servers and multiple backups This is a strange problem. Once in a while, our Windows support team will clone a Windows server. The clone will have the exact same TSM setup as the source server. I'm not familiar with the Win BA client, but it seems it always has a nodename line for the dsm.sys file, so the clone reports to TSM server that it's the same node as the clone source. They both appear to respond to the same schedule. This results in the new server performing good backups to the exact same node as the server that is the clone source. The end result seems to be to two different servers happily backing up the same TSM node. Obviously what we get is a useless mess. When they clone a system they are supposed to use a source without a TSM setup, or, clean out the TSM setup right away, but sometimes this doesn't happen. I've tried to find a way to detect this from the TSM server, but I'm not coming up with anything obvious. I'm interested if anyone else has fought this problem and what you've done. Thanks! Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.
Re: Cloned Win servers and multiple backups
On 5 mei 2009, at 16:37, Tyree, David wrote: I think this only work if you had open registration. no, open registration and the default nodename are unrelated. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Len Boyle Sent: Tuesday, May 05, 2009 9:09 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Cloned Win servers and multiple backups Rick, If your hostnames are unique in of themselves, you can leave the nodename out of the dsm.opt file. TSM will use the hostname for the tsm nodename. If you have clients with the name of xyz.abc.com and xyz.qxr.com then you would have a problem with this scheme. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Rhodes Sent: Tuesday, May 05, 2009 8:12 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Cloned Win servers and multiple backups This is a strange problem. Once in a while, our Windows support team will clone a Windows server. The clone will have the exact same TSM setup as the source server. I'm not familiar with the Win BA client, but it seems it always has a nodename line for the dsm.sys file, so the clone reports to TSM server that it's the same node as the clone source. They both appear to respond to the same schedule. This results in the new server performing good backups to the exact same node as the server that is the clone source. The end result seems to be to two different servers happily backing up the same TSM node. Obviously what we get is a useless mess. When they clone a system they are supposed to use a source without a TSM setup, or, clean out the TSM setup right away, but sometimes this doesn't happen. I've tried to find a way to detect this from the TSM server, but I'm not coming up with anything obvious. I'm interested if anyone else has fought this problem and what you've done. Thanks! Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. -- Met vriendelijke groeten/Kind regards Remco Post r.p...@plcs.nl +31 6 24821 622
Re: Cloned Win servers and multiple backups
I had a problem like this where the builders were using a common image template to build windows servers. I had the good luck of them using an obsolete client name. I kept seeing this unregistered name pop up when I queried for unregistered nodes. I solved it by registering the node and locking it. I accidentally noticed that the IP address of the node changed from time to time. You could try running an SQL query comparing the IP Address of the node matches the ip address of the client server. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: Tuesday, May 05, 2009 10:53 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Cloned Win servers and multiple backups On 5 mei 2009, at 16:37, Tyree, David wrote: I think this only work if you had open registration. no, open registration and the default nodename are unrelated. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Len Boyle Sent: Tuesday, May 05, 2009 9:09 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Cloned Win servers and multiple backups Rick, If your hostnames are unique in of themselves, you can leave the nodename out of the dsm.opt file. TSM will use the hostname for the tsm nodename. If you have clients with the name of xyz.abc.com and xyz.qxr.com then you would have a problem with this scheme. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Rhodes Sent: Tuesday, May 05, 2009 8:12 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Cloned Win servers and multiple backups This is a strange problem. Once in a while, our Windows support team will clone a Windows server. The clone will have the exact same TSM setup as the source server. I'm not familiar with the Win BA client, but it seems it always has a nodename line for the dsm.sys file, so the clone reports to TSM server that it's the same node as the clone source. They both appear to respond to the same schedule. This results in the new server performing good backups to the exact same node as the server that is the clone source. The end result seems to be to two different servers happily backing up the same TSM node. Obviously what we get is a useless mess. When they clone a system they are supposed to use a source without a TSM setup, or, clean out the TSM setup right away, but sometimes this doesn't happen. I've tried to find a way to detect this from the TSM server, but I'm not coming up with anything obvious. I'm interested if anyone else has fought this problem and what you've done. Thanks! Rick - The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. -- Met vriendelijke groeten/Kind regards Remco Post r.p...@plcs.nl +31 6 24821 622 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.
