Windows Server 2012 & 7.5.0.6

Ignore me at your peril! 

You haven't addressed the problem I found yesterday.  I'm STILL seeing that extra space I shouldn't see in your bpcd log for the reverse DNS of your master server's hostname.

To make it easier to spot, I've replaced the space with percent signs in this excerpt from your most recently posted bpcd log:

12:07:39.250 [2680.1320] <2> setup_debug_log: switched debug log file for bpcd
12:07:39.250 [2680.1320] <2> bpcd main: VERBOSE = 0
12:07:39.250 [2680.1320] <2> logparams: C:\Program Files\Veritas\NetBackup\bin\bpcd.exe -standalone
12:07:39.250 [2680.1320] <2> process_requests: offset to GMT 0
12:07:39.266 [2680.1320] <2> logconnections: BPCD ACCEPT FROM 10.132.112.22.55614 TO 10.132.113.127.1556 fd = 292
12:07:39.266 [2680.1320] <2> process_requests: setup_sockopts complete
12:07:39.266 [2680.1320] <2> bpcd peer_hostname: Connection from host bfbackup.ipcmedia.com% (10.132.112.22) port 55614
12:07:39.266 [2680.1320] <2> bpcd valid_server: comparing bfbackup.ipcmedia.com and bfbackup.ipcmedia.com%
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo_and_update: [vnet_addrinfo.c:1585] in failed file cache ERR=11001 NAME=bfbackup.ipcmedia.com% SVC=NULL
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo: [vnet_addrinfo.c:1275] vnet_cached_getaddrinfo_and_update() failed 6 0x6
12:07:39.266 [2680.1320] <8> vnet_same_host_and_update: [vnet_addrinfo.c:2848] vnet_cached_getaddrinfo() failed STAT=6 RV=11001 NAME2=bfbackup.ipcmedia.com%
12:07:39.266 [2680.1320] <2> bpcd valid_server: comparing lonbfbnbumedia1.corp.ad.timeinc.com and bfbackup.ipcmedia.com%
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo_and_update: [vnet_addrinfo.c:1532] in failed cache ERR=11001 NAME=bfbackup.ipcmedia.com% SVC=NULL
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo: [vnet_addrinfo.c:1275] vnet_cached_getaddrinfo_and_update() failed 6 0x6
12:07:39.266 [2680.1320] <8> vnet_same_host_and_update: [vnet_addrinfo.c:2848] vnet_cached_getaddrinfo() failed STAT=6 RV=11001 NAME2=bfbackup.ipcmedia.com%
12:07:39.266 [2680.1320] <2> bpcd valid_server: comparing lonbfbreddev.ipcmedia.com and bfbackup.ipcmedia.com%
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo_and_update: [vnet_addrinfo.c:1532] in failed cache ERR=11001 NAME=bfbackup.ipcmedia.com% SVC=NULL
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo: [vnet_addrinfo.c:1275] vnet_cached_getaddrinfo_and_update() failed 6 0x6
12:07:39.266 [2680.1320] <8> vnet_same_host_and_update: [vnet_addrinfo.c:2848] vnet_cached_getaddrinfo() failed STAT=6 RV=11001 NAME2=bfbackup.ipcmedia.com%
12:07:39.266 [2680.1320] <4> bpcd valid_server: bfbackup.ipcmedia.com% is not a master server
12:07:39.266 [2680.1320] <16> bpcd valid_server: bfbackup.ipcmedia.com% is not a media server either
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo_and_update: [vnet_addrinfo.c:1532] in failed cache ERR=11001 NAME=bfbackup.ipcmedia.com% SVC=NULL
12:07:39.266 [2680.1320] <8> vnet_cached_getaddrinfo: [vnet_addrinfo.c:1275] vnet_cached_getaddrinfo_and_update() failed 6 0x6
12:07:39.266 [2680.1320] <8> vnet_is_local_host: [vnet_addrinfo.c:327] vnet_cached_getaddrinfo() failed STAT=6 RV=11001 NAME=bfbackup.ipcmedia.com%
12:07:39.266 [2680.1320] <2> process_requests: output socket port number = 1

You can also see from this bpcd log that OTHER hosts do not have the extra space after the hostname - for example...

12:06:45.848 [2216.2056] <2> bpcd peer_hostname: Connection from host LONBFBVMCONN2.CORP.AD.TIMEINC.com (10.132.113.127) port 53900

...so it's something unique to JUST your master.

Can you explain why your client's reverse DNS for 10.132.112.22 is appending some invisible space to the FQDN of your master when the reverse DNS for 10.132.113.127 doesn't append that space to *its* FQDN?

The problem with invisible space is...you might not see it when you're doing test DNS lookups, because it's invisible.  :)

Embarrased or what, we have located the original issue with the hosts file, this was saved as a .txt file so the server was ignoring this, once this was corrected we could then connect.

Still unsure as to why it is seeing the extra space in DNS though, the QIP entry has been checked and looks good so unless this is in the DNS cache somewhere we are unsure but as I said all our other servers use the same DNS entries without error.

I will continue to look into this.

Thanks for all you help