I tested Novell's most recent beta of its replication services, Novell Replication Services (NRS) 1.21, in our Savannah, Ga., lab and found that it offers a just-like-mom-used-to-make serving of automated file updates to multiple servers. But unlike homegrown file-copy scripts and other simplistic file-mirroring schemes, NRS is sophisticated enough to offer one- or two-way replication and include/exclude hierarchy, and support compression. It can link servers so that one server on one side of a WAN connection can update others, and it can deal with file clashes from different servers simultaneously updating different copies of a file.

Unfortunately, though NRS supports a NetWare network populated with Windows95 and NT PCs well, it cannot handle Macintosh or Unix file attributes nor replicate with non-NetWare servers. NRS also doesn't work well with database files because it won't replicate only part of a file. Still, NRS is hard to resist for a shop with numerous wide-area NetWare installs.

Getting Serious Installing the beta of NRS 1.21 was fairly simple; I used Novell's INSTALL console utility to put it on each server that would be participating in the replication. I was surprised that NRS didn't use a workstation-based installer, such as the GUI installer that comes with Novell's Z.E.N.works. However, I was pleased to see that the NRS NLM (NetWare Loadable Module) supports uninstalling from the INSTALL screen, and that each replica server now has a synchronization status screen on the server console; in past versions, status information was only shown on the workstation administration program.

After I installed copies of NRS, I ran a registration utility on my Windows workstation to let the NetWare administrator know about the NRS snap-in DLLs (Dynamic Link Libraries). The administration turned out to be a snap as well. The DLL adds three tabs to a server's property page and uses a cue-card feature to help you with the initial replication setup. During testing, the cue cards were almost more helpful than the full documentation, as they "anticipated" what I wanted to do and offered me a succinct how-to. Although supplied HTML documentation was decent, I experienced Java problems on my workstation's older browsers (Microsoft Internet Explorer 3.02a and Netscape Communicator 4.01) when I tried to use search and print features. These problems persisted even after I updated my browser. Novell says that such problems will be fixed in the next public beta.

After the Honeymoon From NWAdmin, I chose a "master" server and assigned replica servers. NRS then synchronized the master files to the replicas. While configuring the master, I specified an "exclude" directory for files I did not want copied. I changed the synchronization options in the administrator so that the servers would not synchronize between 9:00 a.m. and 5:00 p.m. This feature lets you schedule replication for low-cost transmission times.

The advantage to NRS running as an NLM is that NRS updates its file list on the fly as soon as a file is closed. This approach makes it easier to maintain a date-and-time stamp list without file polling, or the toll it takes on performance. This isn't a new feature, but it has been hazardous in previous versions: Our shop had used a previous version of NRS and experienced file-creation problems in "ignored" directories such as SYS:PUBLIC. I installed 1.21 on a test server that contained an earlier version of NRS, and the file-creation errors disappeared.

I tested NRS' "clash" resolution feature by simultaneously creating different files with the same name on both a master server and its replication server. NRS reported the file clash and saved the replica's differing file in a temporary directory. I would have liked NRS to have renamed the file within the same directory, so users could resolve the clash without administrator intervention.

Using a network analyzer, I tested NRS' compression features and measured a considerable bandwidth reduction (2:1) because of the compression. I also severed one of the server's links during synchronization, and the destination (replication) issued an alert, and as promised, the affected server recovered during the next synchronization.

Jonathan Feldman is the technical systems manager for Chatham County, Savannah, Ga. Send your comments on this article to him at jonathan@co.chatham.ga.us.