[ADSM-L] TSM scheduler can't reach TSM client even though it seems to know it's IP address.
2008-09-18 11:30:16
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.
|
|
|