Hello,
I would remove any reference that is obsolete on forward and reverse 
look-up for any alieas\cname etc from DNS & ensure proper name resolution 
for long and short name is resolvable ?
Have you tried using interface setting for the client in question on the 
backup server ?
HTH




gharma <networker-forum AT BACKUPCENTRAL DOT COM> 
Sent by: EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
11/07/2008 07:04 AM
Please respond to
NETWORKER AT LISTSERV.TEMPLE DOT EDU


To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc

Subject
multihomed windows client backup problems, v7.4






Hi,
I previously posted with the full details of this issue on Sept 19 
see:
http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/emc-networker-19/how-to-understand-this-7-4-behavior-on-multihomed-windows-92743/
 

or: 
http://tinyurl.com/5obxha

Briefly, the issue is that this W2k3 R3 server allows communications with 
the backup server on only one interface and the hardware firewall between 
them does the same. 

The backup is defined using the save -c <proper DNS fqdn> 
as was suggested in the reply to my reference prior posting here.

Now, sufficient time has passed for the behavior to again develop.

Basically, with no changes to the client or server, one day backups start 
failing and remain failing despite efforts that have included an uninstall 
of the client, removal of storage and of registry used by the client 
install, search for related files in temp directories and removal, all 
followed by client software reinstall.

Note that client reinstall does not require reboot.  So far the only thing 
that has in the past cleared the inability of the backup server to use the 
correct interface has been a reboot of the client, which of course is 
problematic for a production server.

The nature of the failures is exampled by the following, which appears for 
each saveset in the emails I receive (note: I run the client not the 
backup system).  In the example below I have substituted <right fqdn> and 
<wrong fqdn> for where the correct and incorrect DNS hostnames (fully 
qualified) appear.
As was said in the initial posting, the client does not know any name for 
itself except its <right fqdn> unless for some reason it were to do a 
reverse DNS lookup on the IP of that other interface.
Example of report for a saveset, all are 
* <right fqdn>:ASR:\ 1 retry attempted
* <right fqdn>:ASR:\ 39078:save: SYSTEM error: client `<wrong fqdn>' is 
not properly configured on the Sun StorEdge(TM) Enterprise Backup Server
* <right fqdn>:ASR:\ 
* <right fqdn>:ASR:\ 5777:save: Cannot open save session with <right fqdn>


Any ideas?
IIRC use is made by the backup server of reverse DNS resolution.  What 
might happen if I caused that to no work (i.e. get the PTR DNS record for 
the wrong fqdn removed from the DNS in-addr.arpa zone) ? 

Also, I would like to more clearly thank Patti Clark for her prior reply 
pointing out use of the -c option on the save command, as when I tried to 
do so in the prior thread it had become polluted by a reply with a new 
post so my thank you may have been obscured.

Roger

+----------------------------------------------------------------------
|This was sent by abell AT asu DOT edu via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type 
"signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER



To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER