Forum Discussion

Paul_C1's avatar
Paul_C1
Level 3
14 years ago

Windows admin console - connection to Master Server (UNIX)

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.

7.1.x and Earlier
Backup and Recovery
Configuring
Error messages
Installing
NetBackup

13 Replies

  • Marianne's avatar
    Marianne
    Level 6
    14 years ago

    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's avatar
    Mark_Solutions
    Level 6
    14 years ago

    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's avatar
    Paul_C1
    Level 3
    14 years ago

    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's avatar
    Mark_Solutions
    Level 6
    14 years ago

    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's avatar
    Paul_C1
    Level 3
    14 years ago

    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's avatar
    Paul_C1
    Level 3
    14 years ago

    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's avatar
    Mark_Solutions
    Level 6
    14 years ago

    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!

  • Paul_C1's avatar
    Paul_C1
    Level 3
    14 years ago

    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