The simplest solution is
 upd node STLO-MPVADM HLA=10.52.27.204

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, John
Sent: Thursday, September 18, 2008 9:29 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM scheduler can't reach TSM client even though it
seems to know it's IP address.

Greetings,    
    We are running TSM 5.4.3.0 on AIX 5.3ML5.  Most of our TSM clients
are 5.4.x or 5.5.x.   Most of our clients run "schedmode prompted" so
the TSM server launches the schedule.
    We see an occasional problem where a Windows client is set up wrong
in Active Directory (which feeds DNS), and the TSM scheduler won't be
able to start the client scheduler.  It will get errors such as:
 
09/18/08 05:51:12     ANR8213W Session open with stlo-mpvadm.company.com
timed  
                       out. (SESSION: 243)

09/18/08 05:52:58     ANR8213W Session open with stlo-mpvadm.company.com
timed  
                       out. (SESSION: 243)

09/18/08 05:54:44     ANR8213W Session open with stlo-mpvadm.company.com
timed  
                       out. (SESSION: 243)

09/18/08 05:56:30     ANR8213W Session open with stlo-mpvadm.company.com
timed  
                       out. (SESSION: 243)

09/18/08 05:58:16     ANR8213W Session open with stlo-mpvadm.company.com
timed  
                       out. (SESSION: 243)

09/18/08 06:00:01     ANR2578W Schedule WIN_PROD_0300 in domain WIN_PROD
for    
                       node STLO-MPVADM has missed its scheduled start
up       
                       window.              
In looking into it, what seems to be happening is that it's forward
resolve in DNS doesn't match it's reverse resolve.  Here is an example:
 
W:\>nslookup stlo-mpvadm
Server:  stl-pdcp001.smrcy.com
Address:  10.2.215.158
 
Name:    stlo-mpvadm.smrcy.com
Address:  10.52.27.204

W:\>nslookup 10.52.27.204
Server:  stl-pdcp001.smrcy.com
Address:  10.2.215.158
 
Name:    stlo-mpvadm.company.com
Address:  10.52.27.204

W:\>
 
Notice that the domain name of the host is different on the forward and
the reverse resolve.  That is a mistake.
When you issue a 'q node stlo-mpvadm f=d'  the TSM scheduler clearly has
the correct address cached for it:
...
                   TCP/IP Name: STLO-MPVADM
                TCP/IP Address: 10.52.27.204 ..
So what is TSM's problem here?  It knows the correct IP address.  What
difference does it make that the reverse resolve doesn't match?  Or is
the problem with the client?  Is it not responding?  The client's
dsmwebcl.log and dsmerror.log show no evidence that it is getting
contacted at all.
 
The right way to fix this is to fix the Active Directory root cause, but
sometimes that requires a reboot of the client which can taken a week or
more to schedule.  
 
Is the schedmode setting at fault?  Would changing it to "polling" get
around this until a reboot can be scheduled?  If I don't hear anything
better I will try that tonight.

Best Regards,

John D. Schneider
Lead Systems Administrator - Storage
Sisters of Mercy Health Systems
3637 South Geyer Road
St. Louis, MO  63127
Phone: 314-364-3150
Cell: 314-750-8721
Email:  John.Schneider AT Mercy DOT net

 
This e-mail contains information which (a) may be PROPRIETARY IN NATURE
OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only
for the use of the addressee(s) named above. If you are not the
addressee, or the person responsible for delivering this to the
addressee(s), you are notified that reading, copying or distributing
this e-mail is prohibited. If you have received this e-mail in error,
please contact the sender immediately.