April 15, 1994.(c) Copyright 1994 Palindrome Corporation. All
rights reserved.


                 PROTECTING NETWARE 4.X SERVERS

This document outlines general setup, backup and restore procedures
for using Palindrome Network Archivist NLM 3.1 and Backup Director
NLM 3.1 in NetWare 4.x environments.

SUMMARY
=======
The following major topics are discussed:

     >    Auto Login Issues
     >    Protecting NetWare Directory Services (NDS)
     >    NDS Recovery Techniques

In summary, to adequately maintain NetWare 4.x servers with your
backup product be sure to:

-    Set up your Auto Login user correctly
-    Replicate your NDS database
-    Keep records of how your NDS tree is organized (i.e., in what
     container objects other objects [e.g., servers] are located).


AUTO LOGIN ISSUES
=================

Enabling Bindery Emulation
---------------------------
Currently Network Archivist uses a bindery-based Auto Login
procedure to access NetWare resources.  This means that bindery
emulation must be enabled on each NetWare 4.x server that is to be
protected.  For bindery emulation to be enabled on a server, either
a Master or Read/Write replica of the partition containing the
bindery context must be stored on that server.

When you install a NetWare 4.x server into a new container object
(i.e., an Organization or Organizational Unit), the install program
creates a new partition by default.  When you install a NetWare 4.x
server into an existing container object, the install program by
default creates a Read/Write replica of the partition that holds
this container object on the new server.  In both of these cases
the install program enables bindery emulation by default.

There have been some problems reported during install when a server
is placed in an existing container object.  At times, the
Read/Write replica cannot be placed on the new server.  If this
happens, try to add the server to the Directory tree again, only
this time do not place a Read/Write replica on the new server. 
Once installed, use one of the Partition Manager utilities (either
NWADMIN or PARTMGR) to place a Read/Write replica of this partition
on the new server.  Then set the bindery context and update the
AUTOEXEC.NCF file accordingly.

To check what the current bindery context is on a server, type "SET
BINDERY CONTEXT" at the server console.  To change the bindery
context type "SET BINDERY CONTEXT=<context>" (e.g. SET BINDERY
CONTEXT=.OU=Sales.O=Palindrome).  To disable bindery emulation on
the server type "SET BINDERY CONTEXT=".

Refer to the NetWare 4.01 documentation set from Novell, Inc., for
further details.  For more information regarding bindery emulation,
see Chapter 2, "An Introduction to NetWare Directory Services",
NetWare 4.0 Application Notes.  For more information about creating
NDS partitions, see Chapter 4, "Managing the NetWare Directory
Services Database", Supervising the Network.

Setting Up the Auto Login User Object(s)
----------------------------------------
You may need to establish multiple Auto Login user objects ,
depending on the layout of your Directory tree.  An Auto Login user
must be defined for each container object (Organization or
Organizational Unit) that also contains servers requiring
protection.  If all of your NetWare 4.x servers reside in the same
container object you need only one Auto Login user; otherwise,
multiple Auto Login users must be defined.  Consider the following
examples.  In each the Auto Login user is called ARCHIVIST.

Example 1:  Your Directory tree consists of a single Organization
called ACME that contains two servers, CORP and SALES.  In this
example a single Auto Login User object is sufficient, namely
CN=ARCHIVIST.O=ACME.

Example 2:  Your Directory tree consists of an Organization called
ACME with several departments, SALES, MARKETING and FINANCE.  Each
department has its own server.  In this example it must appear to
either Network Archivist or Backup Directory as if three Auto Login
User objects exist, namely CN=ARCHIVIST.OU=SALES.O=ACME, 
CN=ARCHIVIST.OU=MARKETING.O=ACME, and
CN=ARCHIVIST.OU=FINANCE.O=ACME.

There are two approaches to creating these User objects.  First,
you may create three separate Auto Login user objects, each with
same Common Name and with appropriate trustee rights.  Alternately,
you may create a single Auto Login user in one container object
(e.g. SALES) and create Aliases to this object in the other
container objects (e.g. MARKETING and FINANCE).  The next section
identifies the trustee rights needed by the Auto Login User
object(s).

Trustee Rights Needed by the Auto Login User Object(s)
------------------------------------------------------
Even if your Directory tree requires multiple Auto Login User
objects, only one Auto Login User object need be responsible for
backing of the NDS database.  Palindrome recommends that the
NetWare Directory Services Target Service Agent (TSANDS) be loaded
on the server that contains the Master replica of the Root NDS
partition.  

The Auto Login User object in the same container object as the server 
on which TSANDS.NLM is loaded must be granted the Supervisor object 
right to the Root object.  The Supervisor object right gives the 
Auto Login User object sufficient rights to back up the NDS database, 
and all file servers.  This is the same right that the NetWare 4.x 
Install program gives to the ADMIN User object, thereby allowing it 
to administer the rest of the network.

     Note:     Do not confuse the Root object with the container
               object that happens to be at the top of your
               current context.  The Auto Login User object must
               be made a trustee with Supervisor object rights to
               the  object named "[Root]" (represented by a globe
               in NWADMIN).

If additional Auto Login User objects are required, these objects
need only be granted the Supervisor directory right in the root
directory of each volume for which they are responsible.

Palindrome recommends that you use either the NETADMIN text utility
or the Network Administrator graphical utility (NWADMIN) to create
the Auto Login User object(s) and grant rights, and not the SYSCON
utility supplied with NetWare 3.x.  You may also use either the
FILER or RIGHTS utility to grant an Auto Login User object the
Supervisor directory right.

It is also possible to use Alias objects instead of additional Auto
Login User objects.  The Alias objects should reference the Auto
Login User object that is a trustee with the Supervisor object
right to the Root object.  Be sure to remember which object is
truly a User object and which objects are Alias objects.

PROTECTING NETWARE DIRECTORY SERVICES 
=====================================

NDS Database Replication
------------------------
Although Palindrome provides comprehensive backup of NDS,
Palindrome and Novell strongly recommend that you have at least two
replicas of each partition of your Directory tree.

Replicating the NDS database among multiple servers has several
benefits:
     >    It provides faster access to NDS information for users
          across a wide area network data link.
     >    It eliminates a single point of failure.  If a disk
          crashes or a server goes down, a replica on another
          server can continue to authenticate users to use the
          network and to provide information on objects in that
          partition.
     >    It allows a partition that becomes corrupted to be either
          rebuilt or recreated from a replica.

Note that if every NDS partition but one is replicated, your
Directory tree is still susceptible to database corruption.  One
very dangerous scenario is when every partition is replicated     
except the Root partition.  In this scenario it is possible that
many users would be prevented from accessing portions (or all) of
the network anytime the server containing the Root partition goes
down.  The extent to which users are prevented from doing work
would, of course, depend on the structure of your Directory tree. 
Note, however, that if this partition were lost due to a disk
crash, the entire network (the entire NDS database, and all file
servers in the Directory tree) would need to be restored from
backup in order to recover fully from this failure.

Another scenario that can lead to problems is when a server is
added to the Directory tree on a temporary basis.  There is a
possibility that you could lose the ability to add this server back
into the Directory tree again if the server is not removed from the
network in the proper manner when you are done with it.  You might
even cause an NDS database corruption by removing a server in the
incorrect manner.  Palindrome recommends that you first consult
your NetWare technical support provider better attempting any such
operation.

Backup
------
To back up NDS, Palindrome uses the NetWare Directory Services
Target Service Agent (TSANDS.NLM). TSANDS is provided by Novell,
Inc.  The version that ships with Palindrome Network Archivist and
Backup Director NLM 3.1 is dated October 26, 1993.  This version
has been tested by Palindrome and should be used in place of the
original agent (TSA_NDS) that shipped with NetWare 4.01.

TSANDS backs up the entire NDS database for a Directory tree from
a single point, regardless of the number of partitions that exist. 
A Directory tree need only be added once to the Network Archivist
or Backup Director Protected Resource List.  If performance becomes
an issue while backing up the NDS database, you may wish to
consider storing a replica of each partition on the server where
TSANDS is loaded.

Additional NDS Information Required
-----------------------------------
Palindrome recommends that you complete the "NetWare v4.0 Server
Worksheet", Figure 2-9 in Chapter 2 of Novell's Installation and
Upgrade manual  for each server in your Directory tree.  In
addition to the information requested on the worksheet, be sure to
note the full name of the container object in which the server was
added (for example, OU=Sales.OU=Chicago.O=Acme).

Should you ever need to re-install NetWare Directory Services, you
should call the new Directory tree by the same name as the tree it
is replacing. You must add servers to the same container objects as
before.  Due to a current NetWare Directory Services limitation, it
is not possible to move a server from one container object to
another.  It also may not be possible to recover from a situation
where the restored NDS data does not map perfectly into the new
Directory tree.

For example, if server S1 existed in container object OU=SALES in
the old Directory tree, do not attempt to place S1 in any other
container object besides OU=SALES in the new Directory tree.  To do
otherwise could cause the new tree to become corrupted.

TSANDS Limitations
------------------
Palindrome has seen the following limitations with the NetWare
Directory Services Target Service Agent (TSANDS.NLM) dated October
26, 1993:
     >    No partition information is saved.  You may have to
          repartition and/or replicate the database manually during
          a restore operation.
     >    No schema information is saved.  Applications that modify
          the NDS schema may need to be re-installed if data is
          restored into a new NDS database as opposed to an
          existing NDS database.  This is because only the default
          schema is available whenever NDS is installed. 
          Palindrome recommends that users add "<tree>/Full
          Directory Backup" to the Network Archivist or Backup
          Director Protected Resource List, rather than
          "<tree>/Root", as this ensures that schema information
          will also be backed up once this capability is added to
          TSANDS by Novell.
     >    Bindery Emulation login scripts are not saved.  Login
          scripts created via the NetWare 3.x SYSCON utility for
          users who log in via bindery emulation are stored as
          files in the appropriate MAIL directory, rather than as
          a property of the User object (as is the case with the
          login script for a user who logs into NDS).  While these
          login files are backed up by Network Archivist and Backup
          Director, the directories in which they reside are based
          on a user identification number under the SYS:MAIL
          directory that becomes invalid once NetWare Directory
          Services is removed from a server.

     >    It is possible to restore a single object once it has
          been deleted.  Note, however, that restoring a single
          object does not restore that object's rights to other
          objects, nor are directory and file rights of the deleted
          object restored.
          
          For example, if a User object is deleted, then later
          restored, the User object and data associated with that
          object are restored (i.e., the user's name, location,
          telephone number, login script and other properties are
          restored).  However, rights to other objects must be
          restored manually (i.e., the groups to which the user
          belonged, the printers that the user had rights to use,
          the files and directories the user could access or owned,
          etc.).

     >    Printers are likely to need re-configuring after
          restoring an NDS database.  Not all of the information
          relating the Print Servers, Print Queues and Printers is
          restored properly.

     >    The entire NDS database must be backed up from a single
          point via a single NetWare Directory Services Target
          Service Agent.  This presents several problems:

          -    It may take considerable time for portions of the
               tree that may exist on the other side of a WAN
               link.  In this case, a local replica of the remote
               partition can be extremely useful.

          -    Multiple system administrators may be responsible
               for different portions of the NDS tree.  To avoid
               this problem you should consider two alternatives: 
               
               1) make one administrator responsible for backups
               of the NDS database; or

               2) allow each administrator rights to back up the
               entire NDS database (i.e., backup NDS multiple
               times from multiple Network Archivist or Backup
               Director installations).

          Future releases of Network Archivist and Backup Director
          will be enhanced to back up portions of the NDS database
          once Novell provides the mechanism to do so.

An update to TSANDS is expected sometime during the second quarter
of 1994.  After this, quarterly updates are expected to be released
by Novell.  These updates can be obtained from Novell via the
NOVLIB forum on Compuserve.  Once updates have been certified by
Palindrome, they will also be made available on the Palindrome BBS.

NDS RECOVERY TECHNIQUES
=======================
Whenever a problem with NDS is encountered, a multi-step approach
should be taken before attempting to re-install NetWare Directory
Services.  Palindrome strongly recommends that you familiarize
yourself with all of these steps by studying the NetWare 4.x
documentation before you have a need to restore NDS.

Repairing the NDS Database
--------------------------
DSREPAIR is a server utility that checks and repairs the NDS
database similar to the way VREPAIR checks and repairs volumes.

You can use DSREPAIR to repair the NDS partitions and replicas
stored on the server where you run it.  If the problem persists
after running DSREPAIR, run the utility again on any other servers
that contain the same partition replicas.  To repair the entire NDS
database, you must run the utility on each server that contains a
part of the NDS database.

For further information refer to the following Novell
Documentation: "Repairing the NetWare Directory Services Database"
in Chapter 4 of Supervising the Network, and "DSREPAIR" in Chapter
4 of Utilities Reference.

Rebuilding NDS Replicas
-----------------------
You can rebuild the replicas of a partition from the Master replica
using either the Network Administrator graphical utility (NWADMIN)
or the Partition Manager text utility (PARTMGR).

If the replicas of a partition do not appear to be synchronized
with the Master replica, or if a replica becomes corrupted, you can
replace the replica(s) with a new copy of the Master replica.  If
you suspect that the Master replica is corrupt, but that other
replicas still contain valid data, you should first make one of the
other replicas the new Master replica before proceeding with this
operation.  If you have many replicas of the same partition, you
probably should try rebuilding all replicas.  However, if you have
only one or two replicas other than the Master replica, delete
these and create new replicas.  This latter method ensures that all
other replicas contain the same data as the Master replica.

For more information see "Rebuilding Replicas" in Chapter 4 of 
Novell's Supervising the Network manual.

Restore the NDS Database into the Existing Directory Tree
----------------------------------------------------------
When you restore data into an existing database, trustee ID
information is maintained, thereby avoiding the need to
re-synchronize the file system data with a new NDS database.  The
NDS database can be restored using the Network Archivist or Backup
Director in one of two ways:

     >    From the System Screen, tag the NDS resource and select
          "Restore/Full Resource".

     >    At the server where Network Archivist or Backup Director
          is installed, enter the appropriate command:

     LOAD PNAREST /RO /OA "<tree>/Full Directory Backup"   \*.*
     LOAD PBDREST /RO /OA "<tree>/Full Directory Backup" \*.*  

     where <tree> is the name of your Directory tree.  Be sure to
     include quotation marks around the resource specification
     since Full Directory Backup contains spaces.  Also, it is
     necessary to separate the resource specification from the \*.*
     by a space.

Installing a New Directory Tree
-------------------------------
If none of the above procedures is successful, or you need to
recover from a situation where a partition has been lost that is
not replicated, then you may need to re-install NetWare Directory
Services on all of your servers.  This procedure has far-reaching
consequences.  Once NetWare Directory Services is removed from a
server, that server's file system trustees are invalidated, even
though the file system data is still valid.  Thus, the trustee
information on all NetWare volumes that were in the Directory tree
must also be restored as part of this procedure.

This procedure is not currently automated within Network Archivist
or Backup Director.  However, the special utilities PNARTRUS and
PBDRTRUS (available from Palindrome make the recovery process more
efficient.  PNARTRUS and PBDRTRUS are modified versions of PNAREST
and PBDREST.  They restore file trustee information only, rather
than wasting recovery time by overwriting file system data that is
still valid.

The procedure  for re-installing NetWare Directory Services is
summarized below. 

     >    Remove NetWare Directory Services from each server in the
          Directory tree.  This is done using the INSTALL utility
          at each server containing a part of the NDS database. 
          The order in which this is done can be important.  You
          should remove NetWare Directory Services from servers
          containing partitions that are furthest down in the
          treeand work upwards, leaving the Root partition until
          last.

     >    Install NetWare Directory Services on the first server,
          specifying the same Directory tree name, Organization,
          and optional Organizational Unit(s) as before.  This is
          done using the INSTALL utility at the server console.

     >    Install NetWare Directory Services on each of the
          remaining servers that existed in the Directory tree
          prior to removing the NDS database.  Ensure that the same
          Directory tree, Organization and Organizational Unit(s)
          are specified as existed prior to removing the NDS
          database.

     >    Run the DSREPAIR utility on each server.  This operation
          removes old (obsolete) trustee IDs from the file system.

     >    Load EXTENDFX on each NetWare 4.01 server in the tree. 
          EXTENDFX is a patch provided by Novell, Inc., that allows
          an application such as Network Archivist or Backup
          Director to modify files and directories that no longer
          have valid owners.  This fix should be available from
          Novell soon.  Contact Palindrome if you have difficulty
          locating this patch.

     >    Recreate the Auto Login User object in the container
          object of the server where TSANDS is loaded.

     >    It should not be necessary to re-install Network
          Archivist or Backup Director.  If you have difficulty
          because some of the files are no longer owned by the Auto
          Login User object, try changing the owner of the problem
          files using the FLAG utility.  See "FLAG" in Chapter 3 of
          Novell's Utilities Reference manual.

     >    Restore the NDS database data from backup using one of
          the following commands at the server where Network
          Archivist or Backup Director is installed:
     LOAD PNAREST /RO /OA "<tree>/Full Directory Backup" \*.*
     LOAD PBDREST /RO /OA "<tree>/Full Directory Backup" \*.*  
     where <tree> is the name of the Directory tree.

     >    Reconstruct the trustee information on each server volume
          in the NDS tree.  This can be accomplished by the
          following Network Archivist or Backup Director commands
          repeated for each server/volume in the Protected Resource
          List that are in the NDS tree being restored:
     LOAD  PNAREST /RD /OA <server>/<volume>
     LOAD  PNARTRUS /RO /OA <server>/<volume> \*.*    OR

     LOAD  PBDREST /RD /OA <server>/<volume>
     LOAD  PBDRTRUS /RO /OA <server>/<volume> \*.*

The first operation restores the directory trustees.  The second
operation restores the file trustees while leaving the file data as
it was before.  You may use PNAREST/PBDREST  in place of
PNARTRUS/PBDRTRUS if you wish to replace the file data as well as
the trustee information.
