cancel
Showing results for 
Search instead for 
Did you mean: 

Windows admin console - connection to Master Server (UNIX)

Paul_C1
Level 3

Hi chaps

 

I have worked with backups in a previous role, and have been asked to help out in my current role. I am currently refreshing the brain cells on NBU so I apologise if I ask something blindingly daft.

 

Probably best for a vauge set up description first:

  • Unix Master Server
  • No additional media servers
  • Isolated backup vlan
  • Virtualised (Hyper-v) Windows client on the backup vlan - attempting to install the NBU administration console on it

 

The problem I am having is that whilst the admin console installs, it does not allow a connection to the master server, giving the error:

 

The host "<master server name>" does not have the BPRD service operating. (Error 23).

 

After clicking on OK to the pop up, the admin console shows this:

Top left: <server name> (Unknown Type)

Bottom right: Unknown type: <server name | Connected

 

 

I should point out that I have a support call logged with Symantec for this, but thought I would attack this from another angle in case someone has experienced that same thing.

We have worked through a lot of things today, so I will try and cover them here:

  • host file entries on both UNIX and Windows hosts correct
  • telnet and ping from both on port 13724 allowing connection
  • bp.conf file has an entry for the Windows machine as "SERVER = <name>"
  • I have tried adding the FQDN of the Windows machine into bp.conf too
  • connection and name resolution testing was carried out by Symantec (and me too) using the command "bpclntcmd" with the various switches
  • BPRD daemon is running on the Master Server
  • Windows client added to Servers list for the master server properties
  • services / daemons restarted multiple times

 

If anyone can help I would really appreciate it. I am currently being forced into using the Java console for admin, which is really quite horrible, and by admission via a support call I had logged previously, it seems to lack some functionality.

13 REPLIES 13

Will_Restore
Level 6

needs to be open bi-directionally

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Please ensure that PBX port (1556) is also open in both directions.

Test comms between master and Windows admin console as follows:

Create bpcd log folder on Windows machine.
 

Run the following on master:

bptestbpcd -client <windows-hostname> -verbose -debug

Please post output of command as well as bpcd log.

 

Also create bprd, bpdbm as well as admin log folders on master. Restart NBU to enable logs.

Connection attempt from Admin Console should be logged in one or more of these logs.

Mark_Solutions
Level 6
Partner Accredited Certified

In addition to the excellent advice above also ensure that you have local admin rights on your PC

Without these you cannot use your Admin Console

Hope this helps

Paul_C1
Level 3

Hi both

 

Thanks for the reply. Port 1556 is open.

 

Here is the output from the bptestbpcd:

 

13:01:13.719 [4448.2540] <2> setup_debug_log: switched debug log file for bpcd
13:01:13.719 [4448.2540] <2> bpcd main: VERBOSE = 0
13:01:13.719 [4448.2540] <2> logparams: bpcd
13:01:13.719 [4448.2540] <2> bpcd main: Got socket for input 332
13:01:13.722 [4448.2540] <2> process_requests: offset to GMT 0
13:01:13.729 [4448.2540] <2> logconnections: BPCD ACCEPT FROM 172.31.0.10.42916 TO 172.31.0.9.13724
13:01:13.729 [4448.2540] <2> process_requests: setup_sockopts complete
13:01:13.782 [4448.2540] <2> bpcd peer_hostname: Connection from host lon02-nbu-01 (172.31.0.10) port 42916
13:01:13.784 [4448.2540] <2> bpcd valid_server: comparing lon02-nbu-01 and lon02-nbu-01
13:01:13.785 [4448.2540] <4> bpcd valid_server: hostname comparison succeeded
13:01:13.800 [4448.2540] <2> process_requests: output socket port number = 1
13:01:14.012 [4448.2540] <2> process_requests: Duplicated vnetd socket on stderr
13:01:14.012 [4448.2540] <2> process_requests: <---- NetBackup 7.0 0 ------------initiated
13:01:14.012 [4448.2540] <2> process_requests: VERBOSE = 0
13:01:14.012 [4448.2540] <2> process_requests: Not using VxSS authentication with lon02-nbu-01
13:01:14.068 [4448.2540] <2> process_requests: BPCD_PEERNAME_RQST
13:01:14.069 [4448.2540] <2> bpcd peer_hostname: Connection from host lon02-nbu-01 (172.31.0.10) port 42916
13:01:14.137 [4448.2540] <2> process_requests: BPCD_HOSTNAME_RQST
13:01:14.207 [4448.2540] <2> process_requests: BPCD_CLIENTNAME_RQST
13:01:14.278 [4448.2540] <2> process_requests: BPCD_GET_VERSION_RQST
13:01:14.349 [4448.2540] <2> process_requests: BPCD_GET_PLATFORM_RQST
13:01:14.421 [4448.2540] <2> process_requests: BPCD_GET_VERSION_RQST
13:01:14.491 [4448.2540] <2> process_requests: BPCD_PATCH_VERSION_RQST
13:01:14.491 [4448.2540] <2> retrieveLocalPatchVersion: Reading from C:\Program Files\Veritas\NetBackup\bin\version.txt
13:01:14.805 [4448.2540] <2> parsePatchVersionString: parsing = >7.0
<
13:01:14.805 [4448.2540] <2> parsePatchVersionString: theRest = ><
13:01:14.870 [4448.2540] <2> process_requests: BPCD_GET_VERSION_RQST
13:01:14.870 [4448.2540] <2> process_requests: BPCD_PATCH_VERSION_RQST
13:01:14.870 [4448.2540] <2> retrieveLocalPatchVersion: Reading from C:\Program Files\Veritas\NetBackup\version.txt
13:01:14.876 [4448.2540] <2> parsePatchVersionString: parsing = >7.0
<
13:01:14.876 [4448.2540] <2> parsePatchVersionString: theRest = ><
13:01:14.939 [4448.2540] <2> process_requests: BPCD_GET_VERSION_RQST
13:01:14.939 [4448.2540] <2> process_requests: BPCD_READ_HOST_CONFIG_RQST
13:01:15.011 [4448.2540] <2> process_requests: BPCD_GET_STDOUT_SOCKET_RQST
13:01:15.011 [4448.2540] <2> process_requests: socket port number = 1
13:01:15.283 [4448.2540] <2> process_requests: Connected on output socket
13:01:15.283 [4448.2540] <2> process_requests: Skipping shutdown of send side of stdout.
13:01:15.283 [4448.2540] <2> process_requests: Duplicated socket on stdout
13:01:15.286 [4448.2540] <2> process_requests: BPCD_DISCONNECT_RQST
13:01:15.286 [4448.2540] <2> bpcd exit_bpcd: exit status 0  ----------->exiting

 

I'll have a look at the last part of the log creation as soon as I can.

 

Thanks

Mark_Solutions
Level 6
Partner Accredited Certified

As well as being a local admin on your PC is your console the same version and patch level as the Master

(i.e. 7.1..0.2 etc.)

Paul_C1
Level 3

Hi


Mark - Sorry for the delay. I am logged onto the Windows with a domain admin account, and I have attempted to run it normally, as well as "run as administrator" - to no positive outcome. The NBU Master is at version 7.0, which is the same as the Remote Admin console that is installed.

 

The log folders advised already exist on the master server, so I will have a look through them for anything obvious.

 

Not sure if this is related in some way, but the hosts all exist on the same Hyper-V host. I have been trying to configure backups for the other guest OS's (all Server 2008 R2), and connectivity appears to be working, but every backup fails with status 13 - aside from the backups of Exchange 2010, which fail with status 72.

 

Might be totally un-related / coincidence, but thought it should be mentioned.

 

Thanks again all.

Paul_C1
Level 3

Here is the output for the command: ./bptest-client <windows_client> -verbose -debug

(Sorry, missed that one)

 

<master_server># ./bptestbpcd -client <windows_client> -verbose -debug
16:33:08.327 [27741] <2> bptestbpcd: VERBOSE = 0
16:33:08.328 [27741] <2> db_freeEXDB_INFO: ?
16:33:08.474 [27741] <2> vnet_vnetd_service_socket: ../../libvlibs/vnet_vnetd.c.2054: VN_REQUEST_SERVICE_SOCKET: 6 0x00000006
16:33:08.474 [27741] <2> vnet_vnetd_service_socket: ../../libvlibs/vnet_vnetd.c.2068: service: bpcd
16:33:08.686 [27741] <2> logconnections: BPCD CONNECT FROM 172.31.0.10.47480 TO 172.31.0.9.13724
16:33:08.686 [27741] <2> vnet_connect_to_vnetd_extra: ../../libvlibs/vnet_vnetd.c.188: msg: VNETD CONNECT FROM 172.31.0.10.47481 TO 172.31.0.9.13724 fd = 4
16:33:09.098 [27741] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs/vnet_vnetd.c.541: VN_REQUEST_CONNECT_FORWARD_SOCKET: 10 0x0000000a
16:33:09.301 [27741] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs/vnet_vnetd.c.558: ipc_string: 54950
1 1 1
172.31.0.10:47480 -> 172.31.0.9:13724
172.31.0.10:47481 -> 172.31.0.9:13724
16:33:09.435 [27741] <2> bpcr_get_peername_rqst: Server peername length = 12
16:33:09.505 [27741] <2> bpcr_get_hostname_rqst: Server hostname length = 13
16:33:09.575 [27741] <2> bpcr_get_clientname_rqst: Server client name length = 13
16:33:09.645 [27741] <2> bpcr_get_version_rqst: bpcd version: 07000000
16:33:09.715 [27741] <2> bpcr_get_platform_rqst: Server client platform length = 7
16:33:09.785 [27741] <2> bpcr_get_version_rqst: bpcd version: 07000000
16:33:09.856 [27741] <2> bpcr_patch_version_rqst: theRest == > <
16:33:09.856 [27741] <2> bpcr_get_version_rqst: bpcd version: 07000000
16:33:09.926 [27741] <2> bpcr_patch_version_rqst: theRest == > <
16:33:09.926 [27741] <2> bpcr_get_version_rqst: bpcd version: 07000000
PEER_NAME = <master_server>
HOST_NAME = <windows_client>
CLIENT_NAME = <windows_client>
VERSION = 0x07000000
PLATFORM = win_x64
PATCH_VERSION = 7.0.0.0
SERVER_PATCH_VERSION = 7.0.0.0
MASTER_SERVER = <master_server>
EMM_SERVER = <master_server>
16:33:10.005 [27741] <2> vnet_connect_to_vnetd_extra: ../../libvlibs/vnet_vnetd.c.188: msg: VNETD CONNECT FROM 172.31.0.10.47482 TO 172.31.0.9.13724 fd = 5
16:33:10.058 [27741] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs/vnet_vnetd.c.541: VN_REQUEST_CONNECT_FORWARD_SOCKET: 10 0x0000000a
16:33:10.259 [27741] <2> vnet_vnetd_connect_forward_socket_begin: ../../libvlibs/vnet_vnetd.c.558: ipc_string: 54953
172.31.0.10:47482 -> 172.31.0.9:13724
<2>bptestbpcd: EXIT status = 0
16:33:10.270 [27741] <2> bptestbpcd: EXIT status = 0

Mark_Solutions
Level 6
Partner Accredited Certified

That does sound like a firewall issue then

13724 from client to Master (vnetd)

13724 from Media to Master

1556 from client to Media (pbx)

Always useful to have 13782 (bpcd) open as well

If you can have all three open in all directions even better!

Mark_Solutions
Level 6
Partner Accredited Certified

Ahh! 7.0.0.0

Really needs to be patched (or upgraded all together to 7.1.0.3)

Take a look at this one (not quite the same):

http://www.symantec.com/docs/TECH137565

I would at the very least patch to 7.0.1 and then apply any required patches:

http://www.symantec.com/docs/TECH139092

Paul_C1
Level 3

Yeah, it's odd!

 

No firewall inbetween the servers as they are on the same vlan.

UNIX master server is not running iptables.

Windows firewall is up and running, but the backup NIC is not being controlled by it.

 

Infrastructure guys have been helping me out, and monitored the traffic with wireshark - no blocks that they could see.

 

Cheers

 

Paul

Mark_Solutions
Level 6
Partner Accredited Certified

Just re-read everything here ... and you say that all of your other backups are also failing, so we need to really take a look at the Master Server itself rather than worry about your Admin Console.

Could you run bpps on the Master Server and post its output on here (wondering if bprd and everything else is actually running on the Master)

It may be worth, in view of the changes made to either reboot the Master or at least re-start NetBackup (this will also register your PC as a Server if you have not done it previosuly)

To stop NetBackup:
/usr/openv/netbackup/bin/goodies/netbackup stop

To start NetBackup:
/usr/openv/netbackup/bin/goodies/netbackup start

Paul_C1
Level 3

Hi Mark

 

Sorry for my delayed reply - been out of the office.

 

I have been working through some tests that Symantec have asked me to do too, including installing the admin console on another machine (a VM) - but this is also failing with the same error.

 

Just to clarify, the existing backups are running as normal. It is anything new that is failing - all machines are VM's (hyper-v), Win 2008 R2. I have had one of them work, which is running DFSr. As I am unable to browse the remote machine through the java console, I am having to use Symantec scripts to stop and start DFS services. This however, works.

 

All other servers (running Exchange 2010 or SQL for example) fail when backing up flat files at the moment, as well as the status 72 for Exchange backups too.

 

As part of the new VM for the admin console install that Symantec requested, I restarted all NBU services on the NBU master server too.

 

I have not looked at bringing the version of NBU up yet though sorry - this would require a CR and all sorts, so would not be a quick thing to report on. I have spoken to my account manager today, and asked for my case to be escalated too.

 

Cheers again.

Mark_Solutions
Level 6
Partner Accredited Certified

OK - a couple of things here ....

From your admin console you will not be able to browse clients (via the backup selections or in Client Host Properties) unless your PC is in their Servers list.

Interesting that old policies work but new ones do not!

Could you post the Admin log from the Master Server on here (attach as text file) so that I can see if I can spot anything

Finally for now - are you sure the firewall is turned off on the Master? I have seen a Master server put into a defective OU that causes issues - if possible it is worth creating a new OU with no UAC of Firewall settings and moving the Master into that OU - followed by a gpupdate - to see if it makes any difference

Thanks

#edit# still worth adding the Master to the Server list on your own PC as per the tech note I listed earlier:

http://www.symantec.com/docs/TECH137565