NetBackup 7.1 Java Administration Console (Server running 6.5.5)

[MSheresh]

I am attempting to use the NetBackup  7.1 Java Administration Console to connect to NetBackup Server 6.5.5.

Desktop is a Dell Optiplex 980, 16 GB RAM, Windows 7 Enterprise w/SP1, 64-bit OS.

The Java console login screen pops up no problem, but when I attempt a connection
I receive the following error in the jbp.<date>.log file:

java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)
Connecting to vnetd service over PBX port = 1556
Connecting to vnetd service over PBX port = 1556
ServerInterface:Logon:Exception encountered null
ServerInterface:Logon - Initial host:null, Current host:MNMIS37, PBX port:1556
Can not connect to the NB-Java authentication service on MNMIS37 on port 1556.  Exception:
java.io.EOFException
ServerInterface:Logon:Exception encountered null

And the following error is displayed:

There are no long files being written on the server related to this issue.

I am able to connect using the 6.5 Java console so login credentials are good.

My understanding was that 7.1 is backward compatible with 6.5.5 (which is what our server is running).

Thank you in advance for any help you may be able to provide.

[Marianne]

Your Java Console version needs to match the NBU master version. A higher patch version will still work (e.g. my 7.0.1 Java works on our customer's 7.0 master).

It is possible to install different versions on the same desktop - just do a custom install and choose a different installation directory.

I have at least 3 different Java versions installed on my laptop...

[vilhena]

Have you searched  for some compatibility documentation?

I'm not sure, but I think I read somewhere that the admin console must be the same version of the master server.

Regards,

Ricardo Vilhena

[vilhena]

http://www.symantec.com/business/support/index?page=content&id=TECH29677

Administration Consoles cannot be at an earlier version than the NetBackup server version they connect to via the "change server" functionality in the console

Regards,

Ricardo Vilhena

[MSheresh]

Java consoles before version 7.1 will not work on Windows 7.

[MSheresh]

It is not.  Admin console is ver. 7.1, NetBackup server is version 6.5.5

Java Console 7.1 is supposed to be backward compatible back to 6.5.4

[Marianne]

Where do you see this information?

"Java Console 7.1 is supposed to be backward compatible back to 6.5.4"

I have been working with NBU for 12 years now - this has never been the case.

Have a look at this NOTE in the NBU installation Guide:

Note: The host that is specified in the logon dialog box and the system that runs
the NetBackup Administration Console must run the same NetBackup version.

I have NBU 6.5.6 Java plus 7.0.1 Java installed on my Windows 7 laptop.
(I have 3 different versions installed on my old XP laptop).

[Will_Restore]

"About back-level administration capabilities by the NetBackup-Java console

NetBackup 7.0 provides additional ways to perform back-level administration of

the supported back-level versions. This includes the packaging and the installation

of the NetBackup 6.0 MP7 and NetBackup 6.5.4 versions of the NetBackup-Java

console on supported UNIX and Linux platforms."

But do not read this to say you can use 7.x console to administer 6.x server.

[CRZ]

We always include some backrev GUI environments (libraries and whatnot) for you to use via the -r command switch with jnbSA; however, that's UNIX/Linux only.  It doesn't exist on Windows.

For example, on my Solaris box running 7.1:
jnbSA -r 7.1 is kinda pointless, because it will do the same thing that a plain ol' jnbSA would do...bring up a 7.1 GUI.  But you can do it if you want!  :)
jnbSA -r 7.0 brings up a 7.0.1 Java console, on the other hand.  (But my display said "7.0.1RC4" - ?  Hmmm...)
jnbSA -r 6.5 will bring up a 6.5.6 console
Finally, jnbSA -r 6.0 will totally throw you back with a 6.0 MP7 console (and a really cool spinning V!!!)

None of this helps YOU, of course, because you're on Windows.  :)  You'll need to install a backrev Java console to its own separate directory (or perhaps on a different desktop) and run it from there, like Marianne already said.

[leonworkman]

We have the same issue with a 7.1 server and 7.1 Java Console software (either issued from PC desktop or the server itself), so I'd be interested if someone finds a resolution to this.

What we found is that the issue doesn't occur until we put vnetd/bpcd under inetd control and tcp-wrapper it instead of letting it run as standalone daemons like the post-6.5.x software does.  That's why I believe this is related, since you likely have your 6.5.x software running under inetd control instead of standalone.  Maybe even wrappered.

We like to wrapper our services ourselves, and it would be nice if the same functionality to fall back to vnetd was still there when pbx connections fail for the client software.  I'm not sure what the hand-off problem is here, but running the daemons standalone just isn't as secure as running it with wrappers.

Leon