I check connect form Server NW to client by means of nsradmin -p nsrexec -s HOST X.
And I did this:
Stop the NW client daemon
- Add/correct the NW server to ../nsr/res/servers
- restart the NW client daemon to reread the file
But problem remained.
When you install a Networker client, and start the client for the first time, the client will write some more or less
static info to the local installation.
A) Resource called NSRLA
B) Phassphrase key for the uniq installation.
Don't know where you abandoned the installation. But on the client connect to the local repository by;
nsradmin -p nsrexec.
nsradmin> print type:NSRLA
In the output, check hostname and my hostname, should reflect your installation host.
Next check the local key.
nsradmin> show certificate
nsradmin> option hidden:on
ON you backup server open the NMC --> Config --> Local Hosts
Select your backup server(left pane), select the problematic client in right pane.
- Does your passphrase keys match, if not delete klient key from the backup server.
New features in Networker rely on the phassphrases, and nsrauth. Don't disable it in favour
of oldauth. (If you are not totally sure you want it.)
I don't think that disabling GSS authentication will help here, as for NW 8.x nsrauth is required in order to work with client wizard (and other features).
I think this is more related to certificates (peer information) as pointed already, so please, make sure you delete the peer information of server on client, and of client on server.
Also make sure that DNS and/or hosts file is configured correctly, and also check if on the client side there is any firewall (if Windows then OS firewall could be an issue. Also make sure UAC is disabled, at least for testing purposes).
Make sure you have ports opened between NW server and Host X.
Also, look at firewall settings. I have observed such issue on Windows clients caused by firewall settings.
1. Check the Client auth methods & make sure that nsrauth is enabled.
on Client run "nsradmin -p nsrexec"
nsradmin > p type : NSRLA
You should see similar as "auth methods= "0.0.0.0/0,nsrauth/oldauth”
2. Check for any nsr peer information Conflicts error for the same host on the networker server daemon log files.
EX: Conflicting Peer info for host "XXX"
3. From the Error message that the networker server has rejected the authmethods , I would first make sure that the nsrauth is set @ client side.
4. You can shutdown networker services on client & rename nsrladb on client & restart the services ,
Note : To Perform the above activity , you need to delete the existing Peer info of the client "XXX".
On Networker Server
nsradmin -p nsrexec
nsradmin> p type : NSR Peer information ; name : XXX (FQDN name)
nsradmin> p type : NSR Peer information ; name : XXX (Shortname)
Same activity has to be performed on SN's as well , if you are backing up the clients to a different SN other than Networker Server.
Once these steps are performed we can restart the services by renaming the nsrladb ( This will clear the peer info / authmethods / Port ranges set on the Client) - Port range has to verified if you are using restricted port range on networker datazone.
BTW - another good tool to verify all network related necessities is the NetWorker Health Check Tool (HCT) which is available upon request from EMC support.
Thank guys!!! We did this problem!
I did this:
Run the following commands on both NetWorker Server and the problematic client:
C:\>nsradmin -p nsrexec
NetWorker administration program.
Use the "help" command for help.
nsradmin> . type: nsrla
Current query set
nsradmin> show auth methods
Does it show as below on both NetWorker Server and the problematic client?
auth methods: "0.0.0.0/0,nsrauth/oldauth";
If not, run:
update auth methods:"0.0.0.0/0, nsrauth/oldauth "
2. Update peer information:
On the client:
nsradmin -p nsrexec
print type: nsr peer information; name: <networker server name>
On the networker server:
nsradmin -p nsrexec
print type: nsr peer information; name: <client name>
My problem disappeared!!!