Unsolved
This post is more than 5 years old
2 Intern
•
154 Posts
0
1173
NMC monitoring screen showing "OK" pop-up when looking at savegroup information
As part of our upgrade from NW7.6 to NW8.x we have a NMC running on NW8.1.1.3 on a win2008 system, while the NW server it manages is running NW7.6.5.7 (the last NW7.x release). When clicking on a finished savegroup we see a "OK" pop-up (similar to the one from Error OK (not)). This pop-up can't be clicke away, just generates another one, etc, etc. Simply have to kill the NMC process. The NW servers manager are linux RH and SUN solaris and both generate this error when running NW7.6.5.7. This does not occur with servers already upgraded to NW8.
Besides that it is also cumbersome to find out a good setting on the NW server to be able to manage the NW server using the NMC. for now I only have it set to the default (tried reducing nsrauth to only a subnet consisting out of the the IP of the NW 8.2 NMC but that didn't work, this as on NW7.6 we have multiple clients that cause issues with nsrauth, hence oldauth is only used, but with NMC 8.2 one has to set nsrauth for the NMC server):
auth methods: "0.0.0.0/0,nsrauth/oldauth"
I was able to reproduce the exact same pop-up error on my own laptop.
- laptop windows7 runs NW8.2 server + NMC
- VM with linux centos6.5 runs NW7.6.5.7 server
After running a savegroup called test of the NW server on the VM, when viewing its contents via the NW 8.2 NMC on the windows7 system the pop-up occurs when clicking OK at the bottom of the savegroup details window. Always comes back again.
This way a migration is cumbersome as the NW server only can only be upgraded once all of its clients are done also (which with hundreds of clients and a lot of customer approvals required is a lengthy exercise). So running with NMC8.1.x and NW7.6 server will last some time.
ble1
2 Intern
2 Intern
•
14.3K Posts
1
September 22nd, 2014 08:00
If you wish to manage NW7 with NMC8, you will need to have nsrauth enabled - no other way. However, 8.1.x based NMC might be too different - for NW7 servers in such case you should use NW 8.0.x based one. I would argue that easiest way to handle this, while you have mix of NW7 and NW8 servers, is to have 2 NMC servers - one NW7 and one NW8. That's what I did at the end (as in my case I didn't want to enable nsrauth on NW7 servers).
bbeckers1
2 Intern
2 Intern
•
154 Posts
0
September 22nd, 2014 12:00
testing with NMC8.0.x towards the NW 7.6 server was next on my list of things to try out, however knowing that it is not that desirable as we would have to either downgrade the current NMC or introduce a new one.
And with trying to sort out a working nsrauth/oldauth in the auth methods, it doesn't really help that NW isn't that helpful in stating what is actually the matter except the message that NMC states when trying to connect to the NW server. It would help if NW would state who was trying to connect how and why credential was rejected (without having to increase debugging level, which we haven't even tried yet to see if that would show why it goes awry, not just that it goes awry...).
ble1
2 Intern
2 Intern
•
14.3K Posts
0
September 23rd, 2014 03:00
The message you show is typical when one side does not use nsrauth. For example, if you use NMC 7.x and try to administer NW8 server you may get that when no nsrauth is used by both parties. When I faced your problem I found that:
a) NMC7 can connect NW8 server with nsrauth disabled for monitoring, but all groups are shown as good even if they failed. Going into administration was not possible.
b) NMC8 could not handle NW7 unless nsrauth was enabled
This is why I used NMC7 for NW7 and NMC8 for NW8 servers until all has been leveled up.