DMZ backup issues

a) did you try to see if server and client can communicate with each other via their RPC addresses and via nsradmin

b) if a) is YES, then did you try to configure client manually (forget wizard)

c) if b) is YES and backup fails, try to run backup from client to server

I assume also that DMZ won't know name of server (as normally they do not share DNS) so you will have to set information in hosts table.

Hi,

on the NetWorker client and NetWorker server, please run:

nsrrpcinfo -p server_IP

nsrrpcinfo -p client_IP

to check whether communication is possible. Repeat the same, but use hostname instead of IP.

As Hrvoje stated, if you've doubts, whether the name resolution is working, add hosts to the hosts file. If you've doubts which name to add for the NetWorker server: Run nsradmin on the NW server and enter print NSR, "Name" is the name of the NW server.

Three questions:

1. Does the NW server have several Ethernet interfaces?
2. NetWorker client integration was possible in the past, just this host in the DMZ is causing problems, wasn't it?
3. Is there a NAT (network address translation) between DMZ and NW server?

Regards

Michael

Hrvoje,

Here is what I have tried.

Attempting to connect to nsrexec and portmap port numbers fail, but is allowed, from what I'm told. I tried both short and fqdn to Networker server via telnet.

C:\>telnet pdc00nwka802w 7937

Connecting To pdc00nwka802w...Could not open connection to the host, on port 7937: Connect failed

C:\>telnet pdc00nwka802w.ohlogistics.com 7937

Connecting To pdc00nwka802w.ohlogistics.com...Could not open connection to the host, on port 7937: Connect failed

C:\>telnet pdc00nwka802w 7938

Connecting To pdc00nwka802w...Could not open connection to the host, on port 7938: Connect failed

C:\>telnet pdc00nwka802w.ohlogistics 7938

Connecting To pdc00nwka802w.ohlogistics...Could not open connection to the host, on port 7938: Connect failed

I did configure the client manually, and attempted to run the backup. Received the following...

97512:savefs: Cannot access NetWorker server 'pdc00nwka802w.ohlogistics.com': Remote system error - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

savefs fdc00bizs804w.ohlogistics.com: failed.

--- Job Indications ---

fdc00bizs804w.ohlogistics.com:All: retried 1 times.

Trying to run the backup from the client side, I've not done before. If you are referring to using the Networker User agent on the client, and run the backup from there, it doesnt let me select the Networker server. Gives the same error as when I attempted the backup from the Networker server.

All of the servers in question have already been added into the system32 hosts and the nsr servers file, on the client, the networker server, and the NMC.

Kleinenbroich,

nsrrpcinfo -p from Networker server using IP, and long and short names, returns the following.

C:\>nsrrpcinfo -p 10.202.110.192

146727:nsrrpcinfo: Cannot contact NSR port mapper on host '10.202.110.192': Remote system error - A connection attempt failed because the connected party did

e, or established connection failed because connected host has failed to respond.

nsrrpcinfo -p from client server using IP, and long and short names, returns the following.

C:\>nsrrpcinfo -p 10.212.191.11

PROGRAM VERSION PROTOCOL PORT SERVICE

100000  2       tcp      7938 nsrportmapper Port Mapper

100000  2       udp      7938 nsrportmapper Port Mapper

390436  1       tcp      9131 nsrexecd      GSS Authentication

390435  1       tcp      8821 nsrexecd      Resource Mirror

390113  1       tcp      7937 nsrexecd      Remote Execution

The Networker server only has one network interface, and its a VM.

No, there is another server just like this one, having the very same issue. Plus, this server is not on the domain. However, we do also have another DMZ server that is on the domain that is also having the same issue.

As for a NAT between the Networker server and DMZ, I do not know. I have asked one of our network techs.

Hrvoje and Kleinenbroich,

Here is the answer for natting here. (PDC and FDC refer to the datacenters where my Networker server and the client reside.)

"We don’t NAT for traffic between PDC inside server and DMZ at FDC. You are able to ping between those. I’ll be opening TCP any between those servers at 3PM CST."

I ran a tracert from NW server to client, and its good.

I then ran same from client, back to NW server, and is good as well, but I'll see if Networking can run a different trace.

I thought that was odd as well when i first started trying this, and mentioned it in my initial post. It gets to the second screen for "select backup application tape", and does show OS type, but then starts crying about the GSS authentication.

Your assumption is correct....addresses are set statically, not DHCP.

For the save -s test, would I run this on the NW server, or from client?

OK, so what above shows is that client is running and you can't connect to nsrexecd from server.  One thing could be NAT translation if that is in the game.  But you can probably ask network guys to run tracing between server and client and do the same thing again to see where it breaks.  For example, client can reach server and obviously that part works fine.  The other way around not.  I think with NAT you would probably have an issue in both directions.  So, try to get that trace to see where it breaks.  But same reason is causing wizard to fails.  What confuses me a bit is that your screenshot shows OS type from the client and I wonder how sever knows this if no communication back is possible.  I assume this is not DHCP based system with some random allocation of addresses?  With that said, since communication from client works, I wonder if save would work too.  Try something very simple like:

save -s   -b

[this might work since client is defined and communication to server works though it doesn't back so... no idea really what to expect, but I'm still puzzled by that OS identification in first screenshot]

save always runs on the client.  So, you would run this from client in DMZ.

If ping works both ways (strange), this is even more puzzling.  Of course, you can also extend this by running netstat on both ends to see if session is there (and in which state).  I think GSS auth is most likely because of lack of communication, but just to be sure - is there any error mentioned in daemon.raw on client in DMZ?

Last line might suggest you need quotes around, but what was there before already suggest that there was something again blocking the communication... So you will need to have full network trace between these two to see which TCP connections are waiting and being dropped.

Not sure if my syntax was right. Look bad?

C:\>save -s pdc00nwka802w.ohlogistics.com  -b FDCPHYS01 C:\Members.txt

89987:save: Cannot determine the job ID: Remote system error - A connection attempt failed because the connected party did not properly respond after a period of time, or establis

because connected host has failed to respond.

. Continuing ...

100128:save: Unable to update job with id '0' with command value 'save -s pdc00nwka802w.ohlogistics.com -b FDCPHYS01 "C:\\Members.txt"': Invalid or NULL session channel

6999:save: C:\Members.txt: No such file or directory

Hi,

if ping works but nsrrpcinfo not, the routing is OK, but something on IP level is not OK. Is it possible for you to shutdown the firewall on client and server for some minutes? In that case you could repeat the nsrrpcinfo afterwards.

Windows firwall is more than allowing ports or not, it's also about what are the source IPs. Also, in case that the host is located in the DMZ and the NetWorker server not, there must be some firewall rules on the firewall (not the Windows personal firewall) between server and client.

Regards

Michael