Fixing the dsm.opt may not be enough. When Windows nodes are cloned with the TSM client in place, the registry will cause this interesting behavior even after the dsm.opt is updated. I've found I have to deinstall the TSM client and then delete the ADSM subkey HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM (from both controlset instances) before reinstalling. - Margaret
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Schneider, Jim Sent: Tuesday, March 09, 2010 12:13 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Changing attributes In my environment we get that when server OLORIN was cloned from an image of NIROLO. Both servers have the same nodename value their dsm.sys (Unix) or dsm.opt (Windows) file. The name change occurs when the scheduling daemon or process checks with the TSM server. Fix the dsm.opt/dsm.sys file or stop the scheduling service on the server that is not supposed to be backed up. HTH, Jim Schneider -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Fred Johanson Sent: Tuesday, March 09, 2010 2:02 PM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] Changing attributes I've got a client that generates this 5-6 times a night: 03/09/10 03:29:03 ANR1639I Attributes changed for node NIROLO: TCP Name from OLORIN to NIROLO, TCP Address from 128.135.19.3 to 128.135.19.5, GUID from fd.5f.d0.81.cd.7b.11.de.a8.c7.00- .25.64.90.25.15 to 9a.9c.1b.81.31.8b.11.dd.a6.6f.00.19.b- 9.46.ae.e1. (SESSION: 103251) It goes back and forth, causing great confusion to TSM. I've asked the owner what he's doing and he asks me the same. Anyone with an explanation?
