Re: [ADSM-L] Changing attributes
2010-03-18 10:38:59
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 DOT EDU] On Behalf Of
Thomas Denier
Sent: Tuesday, March 16, 2010 1:18 PM
To: ADSM-L AT VM.MARIST DOT 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.
|
|
|