(I have a case open with Sun on this, but I'd love feedback from the real world 
as well :-))

We're preparing for scheduled (offsite vendor) disaster-recovery tests with a 
pre-test of our own on a local isolated network, and I've run into a Catch-22 
in a previously "works fine" procedure. This is Sun's OEM-ed Networker (EBS 
7.2) on Solaris 8/SPARC, BTW.

Here's what has worked 4 or 5 times so far :
1. On the DR test server, build up Solaris and install a clean (i.e., eval) 
copy of Networker, full server installation, all packages

2. On the production server, shutdown Networker and tar up the entire contents 
of /nsr to tape

3. On the DR server, shutdown Networker, 'mv /nsr /nsr.default' and untar the 
tape of production's /nsr

4. Reboot the DR server, (restart Networker, etc.) reconfigure tape devices, 
libraries, etc. as necessary, delete all backup pool volumes and start 
recoveries from clone tapes

Here's the problem we're having :

In the past, step 4 would generate a warning that the authorization codes are 
invalid and the enablers will be good for only X number of days, which is OK 
(plenty of time for testing). What's happening now is, the Networker server 
processes apparently start, the invalid authorization codes are detected and 
the server processes then just shutdown, leaving only the client daemons 
running (two nsrexecd's and an nsrd process).

There are only a couple of lines in /nsr/logs/daemon.log :

    nsrd: server notice: started
    nsrd: registration notice: invalid auth codes detected.

...and that's it. The server processes won't start because the codes are bad, 
but I can't remove the codes using nwadmin (or any other way I know of - 
nsrcap, etc.) since the server processes won't start.

How do we get around this? Any known issues here?

All of the codes (AFAIK) used to be in /nsr/res/nsr.res prior to 7.x, but 
apparently not anymore. I don't want to go poking around in the config database 
without good reason, however, if we can manually delete the codes somehow, they 
can be re-entered (but in the past we've never even had to do that).

Unless we can work around this, we'll have to mmrecov, manually recover the 
indexes, etc. (which will decimate the time we have at our DR vendor for 
testing). Besides, our procedure has worked fine at least three times before... 
?

Thanks in advance.

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER