ADSM-L

Re: [ADSM-L] TSM client schedules fail because of reverse resolves

2008-05-05 18:17:34
Subject: Re: [ADSM-L] TSM client schedules fail because of reverse resolves
From: "Schneider, John" <John.Schneider AT MERCY DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 5 May 2008 17:16:23 -0500
Howard,
        Thanks for your email.  The problem in our situation is that
this is a largish organization, and we have no control over DNS, it is
owned by another group.  We don't know about mistakes, and neither does
anyone else apparently, until a client backup fails, and we have to fix
them on a case-by-case basis, which is time consuming.


Best Regards,

John D. Schneider
Lead Systems Administrator - Storage
Sisters of Mercy Health Systems
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
Howard Coles
Sent: Monday, May 05, 2008 10:55 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM client schedules fail because of reverse
resolves

This is fairly easy to fix, and prevent, however, I agree that it's a
pain.  It's a security thing I think.
What you have to do is perform a small backup after the DNS entries are
fully switched over.  Also make sure that once the IP address / domain
name are changed that you delete the old one so TSM doesn't get
confused.

We've done our share of DNS / Network IP address scheme changes to see
this problem once in a while.

See Ya'
Howard


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Schneider, John
> Sent: Monday, May 05, 2008 10:34 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] TSM client schedules fail because of reverse
resolves
> 
> Greetings,
>       We are seeing some unusual client schedule behaviors that seem
> to be related to the fact that our company is combining multiple DNS
> domains into one big new domain.  Sometimes a client will be moved to
> the new domain, but the DNS entry may show it still reverse resolving
> to
> the old domain.  The client schedule then fails with:
> 
> 05/03/08 18:30:10     ANR2716E Schedule prompter was not able to
> contact
> client
>                        SPRG-VNACERT using type 1 (sprg-
> vnacert.smrcy.com
> 1823).
>                        (SESSION: 1122)
> 
> 05/03/08 18:30:41     ANR8212W Unable to resolve address for
> sprg-vnacert.smrcy-
>                        .com. (SESSION: 1122)
> 
> 
>       I don't see why TSM has such a big problem with this.  When the
> TSM client first connects to the server, the TSM caches the IP
address.
> You can see the IP address with 'q node xxxxxx f=d'.  I always thought
> the reason for this was that when it came time to reach that client to
> run its schedule, it would do it using the IP address.  But now I
> understand that it tries to do a reverse resolve on the IP address.
In
> this case, a reverse resolve on the cached IP address yields:
> 
> sprg-tsm1_root# nslookup 10.126.33.164
> Server:  stl-pdcp001.smrcy.com
> Address:  10.2.215.158
> 
> Name:    sprg-vnacert.sprg.mercy.net
> Address:  10.126.33.164
> 
> sprg-tsm1_root#
> 
> Note that the domain name is different.  But if I try to forward
lookup
> the name it works correctly:
> 
> sprg-tsm1_root# nslookup sprg-vnacert.smrcy.com
> Server:  stl-pdcp001.smrcy.com
> Address:  10.2.215.158
> 
> Name:    sprg-vnacert.smrcy.com
> Address:  10.126.33.164
> 
> sprg-tsm1_root#
> 
> So what if the reverse look up doesn't work?  TSM has the IP address,
> and that is what it needs to reach the client, isn't it?
> 
> Best Regards,
> 
> John D. Schneider
> Lead Systems Administrator - Storage
> Sisters of Mercy Health Systems
> 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.

<Prev in Thread] Current Thread [Next in Thread>