Backup Central

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?

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:ADSM-L < at > vm.marist.edu] On Behalf Of
Fred Johanson
Sent: Tuesday, March 09, 2010 2:02 PM
To: ADSM-L < at > 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?

Two different ips, 128.135.19.3 and 128.135.19.5, both using the same tsm node name. Could result in an "interesting" restore scenario.

David

Fred Johanson <Fred < at > UCHICAGO.EDU> 3/9/2010 3:02 PM >>>
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?

Sounds like you've got the same client name on two different servers.
Each time they check in with TSM, they are updating their IP and
GUID. Go check the dsm.opt on both those servers.

Gary
On Mar 9, 2010, at 2:02 PM, Fred Johanson wrote:

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?

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:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Schneider, Jim
Sent: Tuesday, March 09, 2010 12:13 PM
To: ADSM-L < at > 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:ADSM-L < at > vm.marist.edu] On Behalf Of
Fred Johanson
Sent: Tuesday, March 09, 2010 2:02 PM
To: ADSM-L < at > 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?

-----Margaret Clark wrote: -----

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.

Windows adminsitrators at our site occasionally rename existing
Windows systems. We almost never specify node names in dsm.opt
files for Windows client; we let the client use the machine name
as the node name. When a Windows client is renamed the client
scheduler service continues to use the old node name, presumably
because the node name was recorded in the registry when the service
was created. We have always been able to clean this up by removing
and recreating the service. We did not need to deinstall the client
software or manually remove registry keys.

You can also edit the registry keys to fix the name. That is how we handle the problem.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Thomas Denier
Sent: Tuesday, March 16, 2010 3:18 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Changing attributes

-----Margaret Clark wrote: -----

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.

Windows adminsitrators at our site occasionally rename existing
Windows systems. We almost never specify node names in dsm.opt
files for Windows client; we let the client use the machine name
as the node name. When a Windows client is renamed the client
scheduler service continues to use the old node name, presumably
because the node name was recorded in the registry when the service
was created. We have always been able to clean this up by removing
and recreating the service. We did not need to deinstall the client
software or manually remove registry keys.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments.

Thank you.

Thomas Denier wrote: " We have always been able to clean this up by removing and recreating the service. We did not need to deinstall the client software or manually remove registry keys."

That's fine as long as the client releases are relatively recent. Somewhere in the client history, TSM changed how it uses the registry, and you can get some very mysterious failures.
Mysterious failures also happen when a Windows client is upgraded without first removing the services. The services registry key has to be manually corrected before the "multiple schedulers may be active" warnings will stop.

- Margaret


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of Thomas Denier
Sent: Tuesday, March 16, 2010 1:18 PM
To: ADSM-L < at > VM.MARIST.EDU
Subject: Re: [ADSM-L] Changing attributes

-----Margaret Clark wrote: -----

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.

Windows adminsitrators at our site occasionally rename existing
Windows systems. We almost never specify node names in dsm.opt
files for Windows client; we let the client use the machine name
as the node name. When a Windows client is renamed the client
scheduler service continues to use the old node name, presumably
because the node name was recorded in the registry when the service
was created. We have always been able to clean this up by removing
and recreating the service. We did not need to deinstall the client
software or manually remove registry keys.