I just upgrade one of my master server from 7.0.1 to 7.1. And ever since then, I'm facing this problem.
Problem: Ping failed on host... error when trying to open host properties
Before any of you guys give me advice on firewall/DNS lookup/hosts file, let me just tell you how the master has been setup. it is due to the tight security that it was setup to be like this.
And let me rephrase, it has always been like this.
Before the upgrade, I can open any client's host properties without any problem. That's because the option "Disable "ping" connection checking was selected by default. I'm aware that this feature is enabled by defualt in 7.1 but it seems like it is not working. Now I'm questioning why the feature is even there if it is not working.
I logged a case with Symantec and was adviced to allow 13782 in firewall to make the ping test successful - which is not the option.
My concern is simple - to DISABLE the ping connection checking for good! I just want to bypass the ping test.
Hopefully you guys can help me. Again, we do not wish to change anything on firewall side as it has been working fine in the past.
If it worked in 7.0.1 and doesn't work in 7.1, we shouldn't be telling you to change your firewall - we should be figuring out what happened to cause the change in NetBackup's behaviour!
What O/S is your master? Are you using the Windows admin console or the Java one? (Is it possible to try both and see if one works and the other doesn't? That might narrow things down. It might also give you a temporary workaround!)
Do you have the ability to show that we're sending out ICMP requests (tcpdump output or something similar? Sorry, I don't know what you would use on Windows)
If you CAN provide something like this, you should probably send it to your TSE and politely but firmly request an escalation of your case to backline because it sure sounds like a defect.
I'm not seeing any open issues about this at the moment, but that doesn't mean you haven't discovered one that NEEDS to be opened!
Jason, easiest way is:
1. Allow ICMP packets.
1. Show to support guys that it's working.
2. Check if Host Properties works with ICMP.
In other case you can spend a lot of time with sniffing and discussing with TechSupport is it NBU trouble or not. It's quite fair cause support-guys can't know all your environment and most of them don't familar with Firewall configuration. Just allow ICMP traffic for a while to be sure that you faced with NBU issue.
So I contacted my firewall team to do a testing. It take quite long time since we are in corporate environment and there's a process to follow...
Anyway, port 13782 was allowed together with ICMP as well.
So the technical support done a lot of logs collection. And did a lot of troubleshooting but still unable to find the solution.
One thing though, the host properties can be opened from Java Console. Which I assume this is not related to port..
So now he want to compare the nbconsole log with the java log.
If you can provide evidence that ICMP packets are being sent while Disable Ping is checked, that's a Windows console bug and your case should be escalated to backline. Can you PM me your case ID?
One other thing you COULD check: does the registry key \HKEY_LOCAL_MACHINE\Software\NetBackup\General\PingOverride match the expected value? Should be set to "1" if checked to disable (I know that sounds backwards - think of it as enabling the disable :) )
Thanks for the reply.
Yes, PingOverride value is currently set to 1.
As for the ICMP packet matter, I think it has been gathered by the engineer that handled my case.
I will PM you the case ID once I posted this reply.
"This issue was accidentally introduced into 7.1 during the coding for IPv6 support." in TN http://www.symantec.com/docs/TECH176848
The Java based NetBackup Administration Console for Windows does not encounter this problem and can be used.
This issue is due for resolution in NetBackup 188.8.131.52 and 7.5.
If the above workaround is not an option and you can not wait for NetBackup 7.5, create a case with Symantec Support to discuss your options.