Joe Bloggs NRS help page

This page is my list of hints 'n' tips for those using, or about to use Novells NRS software. I'm usually a great fan of Novells products, but the NRS product had so much potential, and yet gives so many headaches..

Installation

1. Don't use NRS. If you're not already using NRS, then don't bother to buy it. Go and get yourself Novells new Zen for Servers. It does a much better job of file copying than clunky NRS.
2. Install the latest patches. The latest NRS patch I'm aware of is NRSIT5.EXE. However, it isn't something Novell go out of their way to advertise. (You try looking for it in the Knowledge base..) To get it, go to  http://support.novell.com/search/ff_index.htm  and enter NRSIT5.EXE. You'll also need the latest NetWare patch (NW4SP8a or NW5SP4a)
3. Edit the NRSLOAD.NCF file, and set-up your options. The main ones you should look at are:
• Set the periodic reconcile time, -Hhour (e.g. -H18 for 18:00) Reconciling can be very intensive on a server, so set the reconcile hour to be sometime which won't affect your users, or interfere with your backups. If you don't set this, NRS defaults to the time it was loaded.
• If you only do one-way push synchronization, specify -D and -B. These stop NRS making back-up copies of files on the replica servers

Server Sizing

Database Locations

Defining Replicas

1. When creating new replicas, only create one replica per link/master server at a time. (Novell say only two or three)
2. When creating a new replica, for the first sync NRS always does a "force logout of users whose open files prevent sync" - regardless of the settings in NWADMIN
3. If you've created a new replica, and intend to make it a link server by creating replicas of this new server, wait. Allow the new link server three or four sync periods with its' master before creating the replicas.
4. Also, before creating replicas of link servers, manually check that the link and master server are in sync. Never trust NRS.
5. Once your NRS systems starts to grow, creating replicas can take a very long time. At my site, we've set-up a PC just to run NWADMIN, and create NRS replicas. It can take upto a day !
6. Avoid creating replicas during periodic reconciles of the replicas master. It can lock-up your NRS NLMs

Unless you have high speed links between your servers, pre load data onto them. (It'll be quicker than NRS copying it out)

Reconciles

A synchronization reconcile occurs either:

• When NRS is loaded,
• Every 24 hours after NRS is loaded, or
• At the time specified by the -H start-up switch
• Whenever the "nrscon -r" command is entered at the system console.

There is a nasty bug in NRS to do with reconciles. If a reconcile is running, and another NRS activity starts, then that activity will wait until the reconcile is complete. However, if another NRS activity is currently running, and a reconcile starts, then the odds are that NRS will hang. Prior to NRSIT5, the only way out of this was to re-boot the server, as NRS wouldn't be keen on unloading. However, NRSIT5 is much better at unloading when NRS gets in a mess.

Moving NRS and its' databases (V1.21)

Monitoring NRS

The official way to monitor NRS, is via NWADMIN, through the NRS Synchronization tab. However, this isn't perfect, and if your server has a lot of replicas, it can take time to call this page up. (assuming NWADMIN is already running of course !)

The first thing to look at is the NRS screen on the server. If it is syncing with a server, it should show an active connection. The numbers at the right hand side of the line show how many NCP requests have been sent/received by the server. The bottom of the screen will also show how many files have been copied. The only thing I find this useful for, is to see whether NRS has hung or not.

With one of the patches (I know it definitely existed in NRSIT5, not sure about NRSFT3) Novell added the console command "nrscon -d". This is supposed to be debugging information. The only things it shows me is:

• When NRS is trying to re-connect to a server.
• When it sends and receives NCP packets.

I have two methods for seeing what NRS is really up to, both of them are quite crude.

Firstly, during synchronization, go to monitor, connection list, and find the connection of the master server for this replica. Press return on the connections, and you can see what files the master has open. You can also do this the other way round. (i.e. go to the master server, find the connection for the replica server, and press return on that one) By watching the KB read and written, you can see if NRS is actually copying files. You can also use it to guess how far NRS has got in synchronization.

HINT: NRS syncs files in roughly alphabetical order

When NRS shows it is syncing, but has no files open (usually just at the start of the sync period) it is updating it's databases. This usually doesn't last long, and I don't know of anyway to see what it is up to.

However, when a new replica is being created, NRS does a lot of database work. On the new replica look at the files in NRSDB\01. Over time you should see them increase in size. To work out how large they are likely to be, just look at the files on another replica. Again, not perfect, but you stand a chance of guessing how long it's going to take, and re-assuring yourself that NRS hasn't crashed (Yet)

Troubleshooting

1. Never, ever, type "UNLOAD NRS"  Odds are that you'll loose your command prompt. Always use the escape key from the NRS screen to unload NRS. (Since NRSIT5, unloading NRS is a lot more stable and reliable) NRS Doesn't always unload immediately, so give it five to ten minutes before downing the server.
2. Always try to avoid downing a server whilst NRS is still loaded.
3. Don't bother doing database repairs. They take forever. Just delete the NRS databases (LOAD NRS -P) and re-create that branch of your NRS tree from scratch.
4. If NRS has created zero byte files, or has corrupted files it is meant to be replicating, unload NRS (see above !), delete all the problem files on the replica (zero byte and corrupted) and then re-load NRS. It may take several syncs for NRS to sort itself out.
5. Always do your best to avoid downing a server whilst NRS is still loaded in memory. More often than not, you can end up corrupting your databases...