No, the problem is that the node TSM is trying to reach is
stlo-mpvadm.company.com but the machine that's responding is
stlo-mpvadm.smrcy.com and TSM knows there's a difference. You MUST
correct the DNS problem because TSM uses it in some way to verify
authentication.
I've seen this a dozen or so times before. When I've seen it the worse
is where they have moved the machine to a new domain, but didn't update
the machine's node and domain name info. So the machine was reporting
nodename.olddomain.com while the DNS was saying nodename.newdomain.com
and TSM would not allow the schedule to proceed. Once we corrected the
domain info, the backups proceeded normally.
See Ya'
Howard
> -----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 12:49 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] TSM scheduler can't reach TSM client even though
> it seems to know it's IP address.
>
> Tim,
> We have tried this, but it doesn't help. 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 the TSM scheduler seems to still know what the IP address is, but
> for
> some reason still does a DNS resolve I guess.
>
> Best Regards,
>
> John D. Schneider
> Phone: 314-364-3150
> Cell: 314-750-8721
> Email: John.Schneider AT Mercy DOT net
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Conway, Timothy
> Sent: Thursday, September 18, 2008 11:09 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] TSM scheduler can't reach TSM client even though
> it seems to know it's IP address.
>
> 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.
> 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.
|
