SMS divides the storage management function into four areas of responsibility:

These are incorporated into four modules or applications, as illustrated by Figure 8.1.

FIGURE 8.1 Novell’s SMS architectural overview.

The Storage Management Data Requester (SMDR) provides transparent local and Remote Procedure Call (RPC) links between the SMS modules running on the storage engine and the SMS modules running on the target. When you’re running an SMS-compliant tape backup software on a NetWare server that is backing up a remote NetWare server, for example, SMDR.NLM must be running on both servers to facilitate the communication; a Windows SMDR module (called w32smdr.exe) is included with eDirectory for Windows and is installed in drive:Novell dssms.

The ability to back up data from a specific operation system platform is provided through the Target Service Agent (TSA), which runs on the target. In SMS parlance, an SMS target is what you want to back up (the source of your data). The TSA is SMS’s access road to a target’s data. Through a set of generic Target Service APIs, SMS can read from, write to, and scan the target. All of SMS, except the TSA, treats the target’s data as “black box data”—only the TSA knows the target’s data structure. Generally, one TSA is required for each target. The following are the different TSA modules available for NetWare:

TSA500 and higher support both the traditional NetWare file system and the Novell Storage Services (NSS) released with NetWare 5 and above. The initial release of TSA500, however, does not support NSS mounted DOS FAT file systems. If you need to back up a DOS partition, use TSADOSP.NLM instead. To back up from or restore to the DOS FAT partition on a Net-Ware 6.0 and later server, load DOSFAT.NSS and TSA600.NLM (or TSAFS.NLM for NetWare 6.5). After loading the DOSFAT.NSS module, any DOS FAT partitions are dynamically made available as logical volumes. TSA600/TSAFS considers these logical volumes as resources for backup and restore.

Storage Management Engine (SME) is the heart of an SMS-compliant backup system. Its main task is to retrieve and dispense data. It is in this module where third-party vendors provide value-added features, such as maintaining a database of backed up files and management of tapes.

Instead of directly communicating with the various types of storage devices, SMS communicates with them via the Storage Device Interface (SDI) module. With the assistance of Media Manager, SDI provides SMS a logical view of the media and storage devices. Because of this, any applications using SDI can use all SMS-compatible devices without making any changes. In essence, SDI is a storage device abstraction layer within the SMS architecture, so the higher layers within SMS, such as the SME, don’t need to know how to address a specific storage device for data retrieval or writing to it.

SMS’s capability to work with many different types of targets or services (such as NetWare file systems, eDirectory, Windows 2000, and so on) whose data structures are varied is due to the System Independent Data Format (SIDF). SIDF specifies how a target’s data is formatted, who does the formatting, how a session is placed on the media, and so on. The TSA is responsible for formatting and “deformatting” the target’s data set (such as file data and name-space information) according to the specification. The SME simply writes the SIDF-formatted data to the storage media. Therefore, in concept, SMS’s use of SIDF is very similar to the use of XDR (External Data Representation) in NFS (Network File System) developed by Sun Microsystems, except the receiving side (the SME) does not deformat the data before recording it.

The interactions between the various SMS modules are complex. The following example offers you a high-level look at how an SMS backup session works and gives you some insights into how and why SMS-compliant software functions the way it does. The example assumes that the SMS engine (SME, SDI, and SMDR) is running on a NetWare 6.5 server and it is backing up the SYS volume of a remote NetWare 5.1 server, which has a TSA and SMDR running (see Figure 8.2):

FIGURE 8.2 The SYS volume of the NETWARE5-B server is being backed up, across the wire, by NETWARE65.

You can use a non-SMS solution to back up your file system provided it is NetWare-aware (so file system trustee information is properly backed up). Because it doesn’t make use of TSA, however, it cannot back up NDS/eDirectory; some of the DS files are kept open by DS.NLM and thus can’t be backed up or copied by conventional means—unless it provides its own agent.

Included with NetWare (from NetWare 3.0 and up) is an SMS-compliant backup utility called SBackup. It is an NLM-based tape backup program. NetWare 5 and higher ship with an enhanced version of this backup engine, called SBCon. It contains all the functionality provided by earlier versions of SBackup and has the following enhancements:

The sections that follow outline the necessary steps for backing up and restoring your NDS/eDirectory using SBCon, which is shipped with NetWare 6.5. Before learning that, however, you need to know how to correctly set up and configure SMS for your DS environment.

Configuring SMDR and QMAN

As mentioned earlier in this chapter, SMS-compliant applications make use of SMDR, and SBCon is no exception. Unlike previous versions of SMDR that use Service Advertising Protocol (SAP) to locate other SMDRs on the network, the newer SMDR uses DS and the Service Location Protocol (SLP). Older versions of SMDR advertised the server name where it was loaded using SAP type 0x23F. This mechanism worked well in small LAN environments, but did not scale well in large environments and does not work at all in a pure IP environment. In a pure IP environment, SMDR uses either DS or SLP as a service locator instead of SAPs.

NOTE

SMDR v5.04 and later can use SLP for locating other SMDRs. This enables SMDRs to locate other SMDRs running on servers belonging to different trees. Every SLP-enabled SMDR will register itself in the SMDR.Novell domain when loaded. The SLP-enabled SMDRs will query this domain for locating registered SMDRs.

NOTE

Each server that will be running SMS-compliant software needs to have its own SMDR object.

You need to install and configure SMDR and QMAN (SMS Queue Manager) before you can use any SMS applications, such as SBCon. Some third-party SMS applications may include their own queue manager instead of using QMAN. The configuration can be done during the server installation by choosing to install SMS, or you can add this service at a later time using NWConfig. If SMDR fails to load or if the SMDR object is corrupted, you can restore it to the state when the server was first installed and before it was configured. To do so, you need to delete two configuration files and two DS objects using the steps in the following procedure:

1.   Log in to the server as a user that has Admin rights.

2.   Make your working directory SYS:ETCSMS.

3.   There are two files within this directory, SMDR.CFG and SBACKUP.CFG (SBCON.CFG on NetWare 6.0 and later). Both of these files are text based and can be viewed with any text editor. Either delete or rename these two files. (There is also a TSA.CFG file on NetWare 6.5 servers but you don’t need to delete this file.)

4.   Use a management tool, such as NetWare Administrator, to locate the two SMS-related objects in the tree. Usually these two objects are generally in the container where the NCP Server object is located. If the objects are not there, look through the tree for them. Once they are found, delete them. The default names of the objects are “SMS SMDR Group” and “server name Backup Queue.” For example, for a server named “NETWARE65,” the object names are “SMS SMDR Group” and “NETWARE65 Backup Queue.”

5.   At the server console prompt, type LOAD SMDR NEW. The NEW switch brings up the SMDR Configuration Screen (see Figure 8.3), and you’re asked for three pieces of information:

   The default context for the SMDR group: enter the desired context (such as OU=Servers.O=Company) or press Enter to use the default context.

   The default SMDR context: enter the desired context (such as OU=Servers.O=Company) or press Enter to use the default context.

   The name and password of the user who has managing rights to the object that will be created in the specified context: An example of a user name is given. When entering the user name, use absolute fully distinguished naming such as

     .CN=Admin.OU=Servers.O=Company.

FIGURE 8.3 The SMDR configuration screen.

     The previous steps create a new SYS:ETCSMSSMDR.CFG configuration file that looks similar to this:

            #This is SMDR default configuration file
            #Lines beginning with # are treated as comment

            SMDR Context: OU=toronto.O=dreamlan
            SMDR Group Context: OU=toronto.O=dreamlan

            #Both the protocols are enabled

6.   At the server console prompt, type LOAD QMAN NEW. The NEW switch brings up the SMS Queue Manager Configuration Screen (see Figure 8.4). Similar to configuring SMDR, you’ll be asked to specify the context and the name of the SMS Job Queue. After the job queue name is created, the name of the user who has managing rights is requested. This time, however, an example of the user name is not given. Follow the previous step’s suggestion for the user naming. It is suggested that the same user be given rights to the queue object as the SMS group object.

FIGURE 8.4 The SMS Queue Manager configuration screen.

     If everything is entered correctly, the configuration screen clears and a console message similar to the following is displayed:

            Started service the job queue .CN=NETWARE65 Backup Job
            Queue.OU=toronto.O=dreamlan
            Using transfer buffer size 65536 bytes.

     Also, this step creates a new SYS:ETCSMSSBACKUP.CFG (SBCON.CFG on NetWare 6.0 and later) configuration file that looks similar to this:

# This is QMANAGER Configuration file
# Lines beginning with # are treated as comment.
# QMAN.NLM reads the information from this file when
# loaded
Sbackup Job Queue: .CN=NETWARE65 Backup Job Queue.
 OU=toronto.O=dreamlan
# Default Transfer buffer size
# Transfer Buffer Size: 64000

Now you’re ready to run SBCon.

In NetWare 5 and above, the SBackup NLM has been renamed to SBCON.NLM (NetWare Storage Management Console; on NetWare 6.5 it is referred to as SMS—Backup Management Console) and has a slightly different look than previous versions of SBackup (see Figure 8.5). The main difference is in the Job Administration option, which enables you to create, submit, and administer jobs in a DS queue.

FIGURE 8.5 The version of SBackup shipped with NetWare 5 and above is now called SBCon.

The following steps outline how you can use SBCon to back up your DS tree. It is assumed that you have already correctly installed and configured your tape device:

1.   Load the controller and storage device driver for your tape device, if not already loaded. Load NWTAPE.CDM if required by the device driver.

2.   Load TSANDS.NLM on one of your NetWare servers (SMDR will be auto-loaded if not already loaded). On NetWare 6.5 servers, you can run the SMSSTART.NCF file at the console that loads SMDR, TSAFS, and TSANDS.

TIP

You only need to load TSANDS on one server. For best performance, you should load TSANDS.NLM and SBCON.NLM on the server holding the most replicas. This reduces the amount of tree-walking required during the backing up of the whole DS tree.

NOTE

If you see the “SMDR Group Context is invalid” message displayed when SMDR is loading, this means you have not completely configured the SMDR object. Refer to the earlier section, “Configuring SMDR and QMAN,” to (re)configure SMDR.

3.   On the server with the tape device, load QMAN.NLM and then load SBCON.NLM.

4.   From the Main Menu, select Storage Device Administration.

5.   From the Select a Device menu, highlight the device you want to use (see Figure 8.6). If the device is an autoloader, press Enter to display a list of loaded media.

FIGURE 8.6 Select the backup device and media using the Select a Device menu.

TIP

If SBCon can’t communicate with the tape drive, or if the console LIST DEVICES command shows the device in an Unbound state, ensure NWTAPE.CDM is loaded. If the LIST DEVICES console command sees the tape device properly, but SBCon does not recognize the device, it’s possible that SBCon does not support the tape device. A list of SBCon-supported tape devices can be found in TID #10059850.

6.   Highlight the media you want to use and press Enter to select it.

7.   Press Esc to return to the Main Menu.

NOTE

Steps three through six are not absolutely necessary. These steps help you ascertain whether the job will be able to access the tape device or not before you submit the job.

8.   Select Job Administration.

9.   Select Backup from the Select Job menu.

10.   Use the Target Service option of the Backup Options menu to select the target server. If the selected target server has multiple TSAs running, such as TSANDS and TSAFS, you also need to select the appropriate service. The name of the TSANDS service is server name.Novell Directory (for example, NETWARE_65_A.Novell Directory; see Figure 8.7).

FIGURE 8.7 Select the TSANDS service for backup.

11.   You’re then prompted for a username and password with sufficient DS rights to back up the tree; use the .username.org naming syntax. Upon successful login, a message similar to “You are connected to the target service name <Press ENTER to continue>” is displayed. In the Target Service option, you’ll now see the DS tree name listed.

12.   Use the What to Back Up? option to select backing up the whole Directory tree, the schema, objects or a branch of the tree. After selecting the option, the List Resources menu is displayed.

13.   Press Insert to bring up a list of DS resources that you can select for backup (see Figure 8.8). To back up the schema, for example, highlight Schema in the Full Directory Backup menu, press Enter, and the Schema menu is displayed; you’ll see “[..]” in the menu. Press Esc and the word Schema is now shown in the List Resources menu indicating it will be backed up.

FIGURE 8.8 You can back up the whole tree, the schema, the selected objects or the selected branches of the tree.

NOTE

Selecting Full Directory Backup will back up all objects in the tree, including schema. Selecting SYS volume backup will also back up Server Specific Information (SSI) data, which is important when restoring a crashed server (see the “Server Recovery Using Server Specific Information Data” section later in this chapter for more details.)

TIP

To make it easier to back up portions of the DS tree, you can create a TSANDS.CFG file, which enables you to specify the names of containers where you want backups to begin. TSANDS.CFG is a text file listing DS contexts (one per line) located in the SYS:SYSTEMTSA directory on the server that TSANDS.NLM is loaded on. When this file is present, SBCon lists the additional contexts as available resources that you can select for backup. Note that not all backup programs support the additional resources made available by TSANDS.CFG.

14.   Repeat Step 13 to select any other DS resources you want to back up.

15.   Enter a description (up to 23 characters), such as NETWARE 6.5 tree backup, in the Description field.

16.   Use the Device/Media Name field to select the tape device that will be used.

17.   Use the Advanced Options menu to schedule when the job will run (see Figure 8.9) and to designate whether it’s a repeating job (see Figure 8.10).

FIGURE 8.9 Use the Advanced Backup Options menu to further control what data to back up and to schedule the job.

FIGURE 8.10 You can schedule the job as a run-once or as a recurring job.

18.   Use the Append Session option to specify whether the data on the tape is to be appended or overwritten.

19.   Press Esc and select Yes in response to the Do you want to submit a job? prompt. At this point, you are returned to the Select Job menu.

The job will execute automatically at the scheduled time. You can use the Current Job List option to manage the submitted jobs: from the Main Menu, select Job Administration, Current Job List. A list of queued jobs is displayed in the Queue Job menu. Similar to managing print jobs, you can put a backup job on hold and change its execution time and scheduling (see Figure 8.11).

FIGURE 8.11 Use the Current Job List to manage submitted SBCon jobs.

You can monitor the runtime status of an executing job by highlighting the job in the Queue Job menu and pressing Insert. A real-time display similar to the one that existed in previous versions of SBackup is shown (see Figure 8.12). From this menu, you can delete or stop the job by pressing Delete.

FIGURE 8.12 Real-time status of a currently executing job.

You can also check the execution status of a job using SBCon’s status screen. SBCon creates two NLM screens; one is the user menu screen and the other an SMS Activity Log screen (see Figure 8.13). The information displayed in the SMS Activity Log screen is recorded in the SYS:SYSTEMTSALOGACTIVITY.LOG file and available for review at a later time. Alternatively, you can use SBCon’s run logs to determine what resources were backed up and whether there were any errors. You can access the run log from the Main Menu: Log File Administration, View a log file. To access the error log, use Log File Administration, View an Error File to access the error log. By default, the SMS activity and SBCon run files are stored in the SYS:SYSTEMTSALOG directory.

FIGURE 8.13 SBCon reports the success or failure of a given job using the SMS Activity Log screen.

The mechanics for restoring DS using SBCon is very similar to that of backing up DS except now your source is the tape instead of TSANDS. You can restore a single object, a branch of the tree, or the whole Directory tree. Before you restore DS data from a tape backup, you need to be aware of the following implications to your existing tree:

The following steps outline how to use SBCon to restore your DS (we assume that you have already correctly installed and configured your tape device):

1.   Load the controller and storage device driver for your tape device, if not already loaded. Load NWTAPE.CDM if required by the device driver.

2.   Load TSANDS.NLM on one of your NetWare servers. (SMDR will be auto-loaded if not already loaded.)

3.   On the server with the tape device, load QMAN.NLM and then load SBCON.NLM.

4.   Select Job Administration.

5.   Select Restore from the Select Job menu to bring up the Restore Options menu (see Figure 8.14).

FIGURE 8.14 Configure your restore options using this menu.

6.   Select the Target Service to select the server to which you want to restore DS. Press Enter to bring up a list of servers running TSAs. If the selected server has multiple TSAs running, such as TSANDS and TSAFS, you also need to select the appropriate service. The name of the DS service is server name.Novell Directory (for example, NETWARE_65_A.Novell Directory).

7.   You’re then prompted for a username and password with sufficient DS rights to the tree; use the .username.org naming syntax. Upon successful login, a message similar to “You are connected to target service name <Press ENTER to continue>” is displayed. In the Target Service option, you’ll now see the DS tree name listed.

8.   Enter a description (up to 23 characters) to identify the job in the Description field.

9.   Select the device and media on which DS data is stored.

10.   Select the correct session on the media containing the DS data you want to restore.

11.   Use Advanced Options to set any filters desired in restoring the DS, whether any existing objects should be overwritten, and configure the execution time and run schedules (see Figure 8.15).

FIGURE 8.15 The Advanced Restore Options menu.

WARNING

Be careful when configuring the Overwrite Parent and Overwrite Child options. Any recent DS-related changes (this does not include file system trustee assignments, because they are not stored in DS) to the object, including password, will revert the values to whatever they were at the time of the backup.

12.   Press Esc and then select Yes in response to the Do you want to submit a job? prompt. You’re then returned to the Select Job menu.

As previously mentioned in the “Backing Up eDirectory” section, your job will execute automatically at the scheduled time. You can manage and monitor your restore jobs through the Current Job List option.

During a DS backup, the TSANDS.NLM sends every object—those defined by both native (base) and extended schemas—to the backup program for backup. Versions of TSANDS.NLM prior to v4.14, however, do not send the extended schema definitions of the object types you have added to the DS database. Consequently, the resulting backup of DS contains information for objects defined in an extended schema, but not the extended schema data that defined those objects. This means that before you restore these DS objects, you have to first re-extend the schema so the definitions for extended objects exist in the tree during the restore. If this is not done, NDS/eDirectory will contain restored objects that it doesn’t know how to use and will display them as Unknown objects.

The version of TSANDS.NLM shipped with NetWare 4.11 and higher, as well as the one included in SMSUP6.EXE and higher for NetWare 4.10, backs up and restores any schema extensions by default. You no longer have to re-extend the schema before DS can recognize restored objects defined by an extended schema.

Novell has extended the SMS architecture to include Windows NT and higher. You can use any SMS-compliant backup/restore utility to perform backup and restore operations on your eDirectory database located on your Windows eDirectory server. You can also back up the eDirectory on Windows database to a NetWare server, and vice versa. The following components facilitate the SMS-based backing up and restoring of data on Windows systems.

SMSEngn is a basic Storage Management Engine (see Figure 8.16) provided by Novell for Windows NT and higher. Unlike its NetWare cousin SBCon, SMSEngn can only back up to or restores data from a set of files—a data file (.DAT) and an index file (.IDX). A BackupLog.log file is either created or overwritten if it already exists. You will need to back up these files to a tape or other removable media as part of the Windows file system backup.

FIGURE 8.16 SMS Backup and Restore Engine for Windows.

When eDirectory is installed, the SMDR and TSANDS are set up by default as a Windows service (called “W32 SMDR”). The service is always available though it may be disabled or stopped. You can verify its status via Program Settings, Control Panel, Administrative Tools, Services on Windows 2000 and higher, or Program Settings, Control Panel, Services for Windows NT. If it is not listed in the Services applet, start W32SMDR.EXE located in the drive:NovellNDSSMS directory.

The ndsbackup utility is a Unix command-line utility that allows you to back up and restore eDirectory objects to and from a single file (referred to as the ndsbackupfile). Like all Unix utilities, the actions of the ndsbackup utility are controlled by command line options. The command line options that you can give are a string of characters containing exactly one function letter (c, r, t, s, or x) and zero or more function modifiers (letters or digits). The string contains no space characters, and function modifier arguments are listed on the command line in the same order as their corresponding function modifiers appear in the string. The supported command line options and function modifier arguments are listed in Table 8.1.

TABLE 8.1 ndsbackup Parameters

The command syntax for ndsbackup is

To archive, restore, or list eDirectory objects, you need to specify the fully distinguished name of a leaf object or container that is to be archived, extracted, or listed. To archive the whole tree, specify the Tree object (or leave the eDirectoryObject name from the command line). You can also back up the eDirectory schema by specifying Schema as the eDirectory object.

The following is a partial output from ndsbackup when backing up the whole tree:

In the previous example, the order of the function modifiers is fR, which means the name of the ndsbackupfile is fullbackup.april-01-2004 while the address of the replica server is 10.6.6.1. An eDirectoryObject name is not provided, thus the backup mode defaults to full backup. Since there is no command line option to specify a password (this is for security reasons—but it also makes automating the backup process more challenging), ndsbackup prompts you for the password, which is not echoed (not even as a series of asterisks). If you omit the -a option, you will be prompted for the username.

The “a” that appears in front of each object name in the ndsbackup output is the result of the verbose (v) option. It indicates that each of those objects is being archived.

You can customize the backup process of the ndsbackup utility by choosing specific eDirectory objects to be excluded or included in the backup session. Whether you use exclude (X) or include (-I) usually depends on the size of the data you want to back up, compared to the size you do not want to back up. As an example, to back up most of the eDirectory tree structure while omitting only a small part, use the exclude option to omit the part you do not want to back up as it is more efficient than using include and needing to specify everything else.

There are a number of third-party SMS-compliant backup solutions available for NetWare. Although not required, we recommend that when selecting a server-based application (such as a SMS-compliant backup solution) for your NetWare servers be certain the product has Novell’s YES, Tested and Approved certification.

In order to receive a Novell YES, Tested and Approved certification, generally referred to as the YES certification, a software application must be subjected to a number of testing criteria, such as low memory conditions to see how the application handles exceptions. In the case of backup systems, testing requires that the client/server application correctly back up and restore NetWare volume (which includes NSS volumes), file, and eDirectory information.

Novell Technical Support works closely with companies that test products through Novell DeveloperNet. If you call Novell for end-user or system integrator support and your network incorporates YES, Tested and Approved third-party products, Novell technicians can reference existing support documentation such as YES Bulletins and TIDs. If the error persists, technicians can duplicate the situation in one of Novell’s labs or work with the product vendor, leveraging the relationship that was developed during the testing process to resolve the problem. In short, YES, Tested and Approved is Novell’s first line of interoperability assurance for Novell customers.

Every YES, Tested and Approved product has a YES Bulletin that details what products were used in the testing—such as versions of Novell products, network adapters, controller devices, and supported drivers. The YES Bulletin also indicates specific product configuration, date of the testing, special network configuration information or other related information important to product interoperability in the network environment. For example, a YES Bulletin can tell you whether a particular backup solution can properly back up and restore all the various file formats supported on your network or whether a device driver handles memory over 16MB correctly. This information may be in the form of a configuration note or a line item indicating whether or not certain functionality is supported.

The following are some of the more popular backup system choices that have received the YES certification:

From our experience, the major YES certified data backup solutions players for the Intel platform are BrightStor ARCserve and VERITAS Backup Exec. Many large sites that have mainframes use a combination of BrightStor ARCserve and Backup Exec along with some form of mainframe-based backup solution (such as IBM’s Tivoli Storage Management, formerly called ADSM) for their enterprisewide backup strategies.

There are a number of good, but not YES certified, backup solutions favored by customer sites. Chief among these solutions is Legato’s Networker for NetWare (www.legato.com/products/networker/netware.cfm).

The information presented in this section explains how to restore NDS/eDirectory (prior to eDirectory 8.7) for a specific NetWare server after you have a hardware failure that involves the SYS volume. The procedure is not applicable when you are upgrading or replacing server hardware—instead, refer to the “Upgrading/Replacing Hardware on NetWare” section in your eDirectory 8.6.x documentation.

Following are steps to restore a crashed server or a SYS volume in a multiserver tree where DS information is replicated:

1.   Don’t panic!

2.   Don’t delete the NCP Server or Volume objects for the failed server from the DS. Leave them intact to preserve references that other objects (such as Directory Map objects) may have to these objects as well as any DS trustee assignments made. If the NCP Server or Volume objects are deleted and you have objects that depend on them, you’ll need to re-establish the relationships through a selective DS restore.

WARNING

As discussed in Chapter 2 and elsewhere, when an object is missing its mandatory attributes, it will turn into an Unknown object. Because of this, you need to pay special attention when doing a partial DS restore so that any dependent object(s) are also restored, otherwise the restored object may not be functional.

3.   From your most recent tape backup of the failed server, restore the “Server Specific Information” files to another server. These SSI files, SERVDATA.NDS, DSMISC.LOG, VOLSINFO.TXT, STARTUP.NCF, and AUTOEXEC.NCF, will be restored to a subdirectory, named after the failed server in the DOS “8.3” naming format, under SYS:SYSTEM. For example, if the server was called TEST-NW6A, the SSI files will be restored to SYS:SYSTEMTEST-NW6.A.

4.   If the failed server held a Master replica of any partition, go to another server in the replica ring that has either a Read/Write or Read-Only replica and use DSRepair to promote that replica to a Master. (You can use the information recorded in DSMISC.LOG to determine what replicas were stored on the failed server and which servers are in the respective replica rings.) Repeat this step for every Master replica stored on the failed server. You then need to clean up the replica rings to remove the downed server from the lists. (Refer to the “Replica Ring Inconsistency” section in Chapter 11 for detailed steps.)

TIP

After your replica ring cleanup, you should spot-check the DSTrace output on a number of servers to see whether the replica rings are okay and verify that everything is synchronizing correctly. You don’t want to install a server into a tree that’s not fully synchronized.

NOTE

You can’t use NDS Manager or ConsoleOne to perform the task in Step 4 as they require the Master replica to be up and all servers in the replica ring to be available. You must use DSRepair for this step.

5.   If the failed server contained any non-Master replicas, you need to clean up the replica rings following the procedures given in the “Replica Ring Inconsistency” section in Chapter 11.

6.   Install the new server hardware or new hard drive (if it was only the SYS volume that had failed). Do not yet connect the new server to your network; leave it in an isolated environment.

7.   Install the NetWare operating system on the new hardware as per your standard procedure to set up the LAN and disk driver and create the volumes. (Use VOLSINFO.TXT to determine how many volumes you had on the crashed server, their names, and whether additional name spaces are required.)

     When prompted for server name and server ID (in NetWare 5 and higher; internal IPX network number in NetWare 4), enter the same server name and addressing information. (Use the AUTOEXEC.NCF included with the SSI for these data.)

     When you reached the point of installing DS information, create a new (temporary) tree. This allows you to complete the OS re-installation with the minimal amount of trouble.

     The reason behind creating a temporary DS tree at this point is that the GUI installation program in NetWare 5 and later doesn’t have the option (that is available in NWCONFIG.NLM; and in INSTALL.NLM in NetWare 4) for you to restore DS data using SSI information. You could, however, not create a temporary tree by aborting out of the GUI setup when prompted for DS information and use NWConfig to restore the DS data and manually copy the server files. But it can get confusing and is a lot more extra work—something you don’t need during a disaster recovery. Also, the up side of this technique is that you can build the server off-site (or have a hot standby server pre-built) and then bring it in to replace the crashed server.

8.   After the server OS installation is complete, restart the server (but keeping it off the production network) to ensure everything is working okay. Apply any server updates, such as Support Pack, that you have previously installed and then restart the server again to ensure the updates haven’t messed anything up.

WARNING

Do not restore file system data until after eDirectory has been restored. When file system data is restored, the process looks for the trustee objects in eDirectory. If an object that is a trustee does not exist in the eDirectory database (such as in a new installation before eDirectory has been fully restored), the rights assignments for that object will not be restored.

     Log in from a workstation to test the server LAN card configuration, exercise the hard drives, and so on. After you’re satisfied that the hardware is working correctly, create a directory off the root of your SYS volume and place the five SSI files there. The most important file is SERVDATA.NDS. Log out from the workstation after you’ve copied the files.

     If your new server’s hardware configuration is different from the crashed server’s (such as different network card, thus different driver), make a backup copy of the new STARTUP.NCF and AUTOEXEC.NCF files as they will be overwritten when you restore the SSI data.

NOTE

If your set of SSI files is small enough, you can place them on a diskette instead.

9.   At the server console, load NWCONFIG.NLM (or INSTALL.NLM in the case of NetWare 4) and use the Directory Options selection to remove DS from this new server.

10.   Connect the server to your production environment. Bring up your server and load NWConfig (or Install) and select the Directory Options menu.

11.   Select the Install Directory Services onto this server option. At the screen to “Select a Directory tree,” press F5 (the option to Restore NDS, as indicated at the bottom right of the screen; see Figure 8.20).

FIGURE 8.20 Restore SSI data by pressing F5.

TIP

Do not select a tree by pressing Enter. A new window comes up with two options: A: (the default) or “Press <F3> to specify a different path”.

     If your SSI files are on a diskette, insert the disk and continue with the restore. Otherwise, press F3 and specify the path to where the SSI files were copied to in Step 8.

     Alternatively, you can use the Restore local server information after hardware failure option from the Directory backup and restore options menu to restore the SSI files, as shown in Figure 8.21.

FIGURE 8.21 Restore SSI data via the Restore local server information after hardware failure option.

     After you enter the path and press Enter, the SSI files will be copied to the SYS volume. DSMISC.LOG, VOLSINFO.TXT, and AUTOEXEC.NCF are copied to the SYS:SYSTEM directory; STARTUP.NCF is copied to the DOS partition. DS information is restored at this point, using the data contained in SERVDATA.NDS. Unlike a traditional DS restore using SMS, TSANDS.NLM is not required for this. Once this is complete, DS is fully functional on the server, except that the partitions and replicas have not yet been re-established.

12.   You may also need to re-establish licensing information. For NetWare 4, you reinstall the license(s) using INSTALL.NLM.

13.   Prepare the restored directory for integration into the original tree by executing the following DSRepair commands in the order specified:

1.   DSREPAIR-SI (Repairs replica numbers on partition objects); option is not available for eDirectory 8.5 or below

2.   DSREPAIR-RD (Local database repair)

3.   DSREPAIR-RN (Repairs network addresses)

4.   DSREPAIR-SR (Requests local schema switch); command-line option is not available for eDirectory 8.5 or below but can instead use Advanced options menu, Global schema operations, Reset local schema.

     This is a cleanup process. It’s okay to see error messages displayed during the cleanup.

14.   Use DSTrace to verify that the schema has synchronized fully. From the server console, type

SET DSTRACE = ON (Activates the NDS transactions screen)
SET DSTRACE = +SCHEMA (Displays schema information)
SET DSTRACE = +IN (Monitors inbound synchronization
 traffic)

     Watch for the message “All processed = YES” on the trace status screen. Once the schema is synchronized, you are ready to re-establish replicas.

15.   With the information recorded in the DSMISC.LOG file, re-establish the original replicas using NDS Manager or ConsoleOne. We recommend you place the replicas on the new server before file system restore so that any external references that might result from file system trustee assignments are minimized.

16.   If the new server’s hardware configuration is not identical to that of the old server’s, you’ll need to change the restored AUTOEXEC.NCF and STARTUP.NCF files to match the new settings, using the backup copies you made in Step 8. After making the changes, restart the server to ensure the changes are okay.

17.   At this point, you can restore the file system from your most recent backup. You should be careful when restoring the SYS volume data to ensure that you don’t overwrite any new Support Pack files with older ones. If you’ve made modifications to your AUTOEXEC.NCF, make certain the older copy from your restore operation does not overwrite it.

REAL WORLD
Disk Space Problems

When restoring files to a volume that was nearly full before the backup, you may run into insufficient disk space issues during the operation. This is especially true when volume compression is used. Although SMS-compliant backup software can back up and restore compressed files in their compressed format, that’s not the default in most backup software. Because of this, chances are good that you’ll restore previously compressed files in an uncompressed format. Because compression is a background OS process, files are not compressed until the compression start time is reached.

You can, however, flag files as Immediate Compress, but that’s an extra manual step. Afterward, you must remember to unflag them or else they’ll always be compressed again immediately after access, causing unnecessary high server utilization.

Another volume-related issue that you can get caught with during a restore is that of suballocation. Again, because it is a background process, files are not suballocated as they are restored. Therefore, if you’re restoring many (small) files, you can run out of disk space before the restore is completely finished.

To work around these two problems, it is best to either maintain at least 15–20% free disk space on each volume, or make certain the replacement drive capacity is larger.

18.   After the file system restore is complete, restart the server one more time to ensure that the restore didn’t overwrite any important system files. Perform a spot-check on some of the restored directories and files for trustee assignments, file ownership, and so on. Also spot-check DS objects to ensure you don’t have any Unknowns. Bindery-based objects and any DS objects (such as Print Queues) that depend on object IDs should restore correctly because of the SSI information. In the event that Print Queue objects, for example, are not recovered correctly, you need to recreate them.

19.   Install, if necessary, any additional server-based add-on products.

This procedure should work with NetWare 4.10 but we have not tested it in that environment. Also, there’s a bug in TSA410.NLM for NetWare 4.10 wherein replica information is not recorded in the DSMISC.LOG file. A workaround is to use MakeSSI (discussed in the previous section) on NetWare 4.10 servers as MakeSSI creates a PARTINFO.LST file, which is equivalent to the DSMISC.LOG file, as far as recording replica information goes. Also, you need to use the most recent TSA410.NLM as older versions (before v4.14) don’t support SSI.

The information presented in this section explains how to restore eDirectory 8.5 or 8.6 (but not 8.7 or later) for a specific Windows server after you had a hardware failure that involves the disk hosting eDirectory. The procedure is not applicable when you are upgrading or replacing server hardware—instead, refer to the “Upgrading/Replacing Hardware on Windows NT/2000” section in your eDirectory 8.6.x documentation.

The steps to restore a crashed Windows server or a damaged disk hosting eDirectory in a multiserver tree where DS information is replicated are very similar to that for NetWare outlined in the previous section. Instead of repeating the same information, we point out the differences in the procedure where applicable:

When restoring file systems on the Windows server, ensure you do not overwrite the current eDirectory files with the older versions from your backup.

Due to some internal database structure changes in eDirectory 8.7, Server Specific Information backups created by file system TSAs or third-party backup tools are not supported for NetWare 5.1 and 6.0 servers running eDirectory 8.7 or 8.7.1. In eDirectory 8.7.3, SSI is now supported using the hot backup functionality. As in previous versions, file system TSA calls the DSBACKER.NLM to create the backup, but now DSBACKER.NLM also calls BACKUPCR.NLM to create a backup using the Backup eMtool functionality.

Table 8.2 lists recommendations for creating and restoring SSI data depending on the NetWare and eDirectory versions.

TABLE 8.2 Recommended Backup and Restore Methods for NetWare SSI Data

The main differences in SSI data created by NetWare 6.0 with eDirectory 8.7.1 and later are as follows:

TABLE 8.3 NetWare SSI Files for eDirectory 8.7.1 and Later

When you direct the Backup eMTool to begin the restore process, either through iManager or the eMBox Client, the following steps are taken by the Backup eMTool:

The restore verification process is backward compatible only with eDirectory 8.5 or later (due to the transitive vector requirement). If the server you are restoring participates in a replica ring with a server running a version of NDS earlier than eDirectory 8.5, the restore log will show a -666 error (incompatible DS version) for that replica. This does not indicate whether the replicas are out of sync; it merely indicates that the restore verification was unable to compare the transitive vectors because the version of eDirectory was earlier than 8.5. When this happens, the database will not open (by default) because the restore verification was not completely successful. If in your best judgment, however, it is safe to open the database, you can use the override restore option in the eMBox Client to make the restored DIB active. Refer to the later section “Recovering the DIB If Restore Verification Fails” on how to recover the server from a failed restore verification process.

A transitive vector is a time stamp for a replica. The vector consists of the number of seconds since midnight of January 1, 1970 (a common reference point used by all DS-related time functions), the replica number, and the current event number. Here’s an example of a transitive vector:

In the context of backup and restore, it’s important because the transitive vector is used to verify that the server restored is in sync with the replica rings it participates in.

Servers that hold replicas of the same partition communicate with each other to keep the replicas synchronized. Each time a server communicates with another server in the replica ring, it keeps a record of the transitive vector the other server had when they communicated. These transitive vectors allow the servers in a replica ring to know what information needs to be sent to each replica in the ring to keep all the replicas synchronized. When a server is unavailable, it stops communicating, and the other servers don’t send updates or change the transitive vector they have recorded for that server until the server starts communicating again.

When you restore eDirectory on a server, the restore verification process compares the transitive vector of the server being restored to the other servers in the replica ring. This is done to make sure the replicas being restored are in the same state the other servers expect.

If the transitive vector on the remote server is ahead of the local vector, then data is missing from the restore, and the verification fails. As an example, data might be missing because you did not turn on continuous roll-forward logging before the last full or incremental backup, you did not include the roll-forward logs in the restore, or the set of roll-forward logs you provided for the restore was not complete.

The eDirectory Backup eMTool provides hot continuous backup of the eDirectory database on an individual server. This feature allows you to back up eDirectory on your server without closing the database and still get a complete backup that is a snapshot of the moment when the backup began. This means you can create a backup at any time and eDirectory will remain accessible by your users and other clients throughout the process. Hot continuous backup is the default behavior.

The Backup eMTool also lets you turn on roll-forward logging to keep a record of transactions in the database since the last backup. This allows you to restore a server to the state it was in at the moment before it went down. In a single-server environment, roll-forward logging is not required for the restore verification process, but the log files enable you to restore eDirectory to the moment before it went down instead of just to the last backup. In a multiserver tree, however, you must turn on roll-forward logging for all servers that participate in a replica ring, so that you can restore a server to the synchronization state that the other servers expect. If you don’t, then when you try to restore from your backup files you will get errors and the database will not open. Roll-forward logging is off by default.

eDirectory automatically creates a record of transactions in a log file before committing them to the database. By default, the log file for these records is reused over and over (consuming only a small amount of disk space), and the history of changes to the eDirectory database is not saved. When you turn on continuous roll-forward logging, the history of changes is saved in a set of consecutive roll-forward log files. Roll-forward logging does not reduce server performance; it simply saves the log file entries that eDirectory is already creating.

When using the continuous roll-forward logging feature, you must be aware of the following issues:

Removal of eDirectory from a server also removes all the roll-forward logs. If you want to be able to use the logs for restoring in the future, copy the roll-forward logs to another location before removing eDirectory.

The roll-forward log feature is off by default. It is easiest to use iManager for this task. Follow these steps to enable roll-forward logging on a given server:

1.   Log into iManager as a user with Supervisor rights.

2.   Click the Roles and Tasks button.

3.   Click eDirectory Maintenance, Backup Configuration.

4.   Specify the server that you want to configure and click Next.

5.   If not already authenticated to the server, you will be prompted for a username and password. Enter the requested information and click Next.

6.   The Backup Configuration Wizard (see Figure 8.22) is displayed showing the current setting.

FIGURE 8.22 Configuring roll-forward logging.

7.   Change the status of Roll-forward logging to On.

8.   Specify a Roll-forward logs directory. For fault-tolerance purposes, this directory should be on a separate drive or volume than where eDirectory is installed.

9.   Set maximum and minimum file sizes as desired.

10.   Click Start to save the new settings.

11.   Document your settings.

You need to do this for every server that you want to use roll-forward logging on.

We strongly suggest that you periodically back up the log files and remove unused logs from the server to free up disk space. Use the following procedure to identify, back up, and remove roll-forward logs that are safe to remove:

1.   Make a note of the name of the last unused roll-forward log. You can find out the name of the last unused roll-forward log in the following ways:

   In iManager, click eDirectory Maintenance, Backup Configuration and read the filename displayed, as shown in Figure 8.23.

FIGURE 8.23 Determining the name of the last unused roll-forward log.

   In the eMBox Client, use the backup.getconfig command in the interactive mode. If using the GUI mode, backup, Retrieve backup configuation, Run.

     The last unused roll-forward log is the most recent roll-forward log the database has completed and is no longer using to record transactions. It’s called the last unused roll-forward log because the database has finished writing to it and has begun a new log file so it does not need to have this one open any more. The current roll-forward log in which the database is recording transactions is in use and is still needed by the database.

2.   Do a file system backup of the roll-forward logs to put them all safely on tape.

3.   Manually remove the roll-forward logs that are older than the last unused roll-forward log.

Although Backup eMTool is rather easy to use and more powerful than the former SSI option, there is quite a bit of manual maintenance work in regard to the roll-forward log files.

The eDirectory Backup eMTool can back up data from an eDirectory database to one or more files on the server where the backup is being performed. You can do a full or incremental backup. The backup files contain information necessary to restore eDirectory to the state it was in at the time of the backup. The results of the backup process are written to the log file you specify.

Backups performed using iManager are hot continuous backups, meaning that the eDirectory database is kept open and accessible during the process, and you still get a complete backup that is a snapshot of the moment when the backup began. To perform a cold backup (a backup with the database closed) or an unattended backup, you must use the eMBox Client.

The following steps illustrate how to back up a server using iManager:

1.   Log into iManager as a user with Supervisor rights.

2.   Click the Roles and Tasks button.

3.   Click eDirectory Maintenance, Backup.

4.   Specify the server that you want to backup and click Next.

5.   If not already authenticated to the server, you will be prompted for a username and password. Enter the requested information and click Next.

6.   Specify the backup file options, such as full, incremental and name and location of the backup file (see Figure 8.24), optionally a maximum file size for the backup data file, and then click Next.

FIGURE 8.24 Server backup options.

NOTE

When a maximum file size is specified, after the first file (whose name is what you specified) has reached the specified file size, subsequent files are created as filename.xxxxx, where xxxxx ranges from 00001 to FFFFF.

7.   Specify whether to include NICI files in the backup. Novell recommends that you always include NICI files.

8.   Specify whether to include stream files in the backup.

9.   Specify any additional files to back up via an include file. This include file is a text file that exists on the file system of the server you are backing up and contains a list of semicolon-separated files.

WARNING

The filenames must not have any spaces or hard returns between each entry and the last entry must have a semicolon after its name; embedded spaces within a filename is okay. For example, SYS:SYSTEMAUTOEXEC.NCF;SYS:PUBLICCUSTOM_APP.EXE;.

10.   Click Start.

The backup log file contains a list of files that were backed up, such as the NICI files and any files you specified using an include file. The log file looks similar to the following:

Make sure you do a file system backup shortly after the eDirectory backup is created, to put the eDirectory backup files (including the log file) safely on tape since the Backup eMTool only places them on the server.

To perform a cold backup (for the purpose of hardware upgrade, for example) or a scheduled unattended backup (via system batch files and scripts), you need to use the eMBox Client, and not iManager. Refer to the “eDirectory Management Toolbox” section in Chapter 7 for more information about using the eMBox Client.

The most important part of restoring the eDirectory database is making sure it is complete. Because of the file dependencies (having the correct roll-forward logs for the specific backup and so on), you must ensure the following prerequisites have been met before restoring an eDirectory database to a server:

During the restore process, the eDirectory Backup eMTool first restores the full backup. After this is complete, the Backup eMTool prompts you to enter the filenames of the incremental backup files. It provides you with the ID of the next file. After all incremental files are restored, the Backup eMTool moves on to the roll-forward logs.

After you have gathered all the necessary files and have placed them in the same directory, perform the restore using either iManager or the eMBox Client. The following outlines the server restore from backup files procedure using iManager:

1.   Ensure that the prerequisites listed at the beginning of this section are met.

2.   Log into iManager as a user with Supervisor rights.

3.   Click the Roles and Tasks button.

4.   Click eDirectory Maintenance, Restore.

5.   Specify the server that you want to restore and click Next.

6.   If not already authenticated to the server, you will be prompted for a username and password. Enter the requested information and click Next.

7.   Specify the name of the backup and log files you want to use (see Figure 8.25), then click Next.

FIGURE 8.25 Specifying the backup files for restore.

8.   Specify additional restore options (see Figure 8.26), then click Next. In most cases, the following check boxes should be selected for a proper restore:

   Restore database

   Activate the restored database after verification

   Open the database after completion of restore

   Restore security files (meaning NICI files)

   If you are restoring roll-forward logs, make sure you include the full path to the logs, including the directory that is automatically created by eDirectory, usually named nds.rfl.

   Activate the restored database after verification

FIGURE 8.26 Specifying additional restore options.

9.   Click Start to initiate the restore process.

10.   If the restore verification fails, refer to the later section “Recovering the DIB If Restore Verification Fails.”

11.   If you restored NICI security files, restart the server after the eDirectory restore is complete to reinitialize NICI.

12.   Verify that the server is re-introduced into the production tree correctly and check that all replicas on this server are properly synchronized.

You should perform a full backup soon after the server restore process is complete. The new full backup is necessary so that you are prepared for any failures that might occur before the next full backup is scheduled to take place.

To ensure data consistency, the Backup eMTool restore process includes a verification step, which compares transitive vectors in the eDirectory database on the server being restored against other servers in the replica ring. If the transitive vectors do not match, the verification fails. This usually indicates that data is missing from the files you used for the restore. Data might be missing for one of the following reasons:

Verification failure might be caused by one of the servers in the replica ring running a version of NDS earlier than eDirectory 8.5. By default the restored eDirectory database will not open after the restore if Backup eMTool determines it is inconsistent with the other replicas.

If you have all the backup files and roll-forward logs necessary for a complete restore but forget to provide all of them during the process, you can simply run the restore again with a complete set of files. If the restore is complete on a second try, the verification can succeed and the restored database will open.

If you do not have all the backup files and roll-forward logs necessary to make the restore complete so that verification will be successful, you must follow the instructions outlined later in this section to recover the server. Here is an outline of what information you can recover if verification fails:

If eDirectory Backup eMTool verification fails to recover the server’s identity, use the following procedure to recover and re-add it to the replica ring:

1.   Clean up the replica rings per the steps given in the “Replica Ring Inconsistency” section in Chapter 11.

2.   Change the replica information on the server to external references, so that the server does not consider it to be part of a replica ring. After you remove the replicas from the server in this way, you can unlock the database. To accomplish this step, you need to use the advanced restore mode in the eMBox Client—you cannot use iManager for this step—to override the default restore behavior:

   Launch the eMBox Client using the instructions presented in the “eDirectory Management Toolbox” section in Chapter 7. You can use either the interactive mode (-i) or the graphical mode (-g).

   If using the GUI mode, enable both the Show command line and Advanced mode options via the Settings menu.

   Log into the server you want to restore. If using the interactive mode, enter the following command:

           backup.restadv -v -l logfilename

     If using the GUI mode (see Figure 8.27), click Backup, Advanced restore options, mark Override restore, and click Run. This advanced restore option will rename the .RST database (the database that was restored but failed the verification) to .NDS, but keep the database locked.

FIGURE 8.27 Using the advanced restore option in eMBox Client.

   At the server console, run DSRepair with the -XK2 switch to change all replica information on the server to external references:

NetWare	DSREPAIR -XK2 -RD
Windows	From NDSCons, select dsrepair.dlm, enter –rd –xk2 in the Startup Parameters field, and click Start.
Unix	ndsrepair -R -Ad -xk2

DSREPAIR.NLM and dsrepair.dlm will not display their menu and will exit automatically after the repair is finished when the -rd switch is specified.

You can also use the DSRepair eMTool for this step (see Figure 8.28). Click dsrepair, Repair local database, uncheck all options, click Use temporary eDirectory database during repair?, click (xk2):Convert all replicas into external references, and click Run.

FIGURE 8.28 Using the advanced repair option to change all replica information on the server to external references.

   When the repair is finished, remove the lockout and open the database. If using the interactive mode, enter the following command:

          backup.restadv -o -k -l logfilename

     The -o opens the database and the -k removes the lockout.

     If using the GUI mode (see Figure 8.29), click backup, Advanced restore options, mark Open database when finished, mark Remove lockout on database, and click Run.

FIGURE 8.29 Unlock and open the database.

3.   You can now re-add the server into the replica rings using either ConsoleOne or iManager. When you have followed these steps and the replication process is complete, the server should function as it did before the failure (with the exception of any partitions that were not replicated and, therefore, can’t be recovered).

4.   If you restored NICI security files, after completing the restore and replication, restart the server to reinitialize NICI.

5.   If you want to use roll-forward logging on this server, you must re-create your configuration for roll-forward logging to make sure it is turned on and the logs are being saved in a fault-tolerant location. After turning on the roll-forward logs, you must also do a new full backup.

This last step is necessary because during a restore, the configuration for roll-forward logging is set back to the default, which means that roll-forward logging is turned off and the location is set back to the default. The new full backup is necessary so that you are prepared for any failures that might occur before the next full backup is scheduled to take place.

It is not uncommon to forget a password, especially one that’s considered to be a good, secure password. What can you do if the Admin password is lost, either due to human error or deliberate sabotage? If you have a backup Admin user that has Write rights to Admin’s Access Control List (ACL) attribute then you can simply use it to reset Admin’s password.

What if you don’t have a user that can reset Admin’s password? There are a few solutions that you can try.

The first technique is to make use of Bindery Services. If you have a server that holds a writable replica (Master or Read/Write) of the partition containing the Admin object, you can use one of the two following methods:

Because these NLMs require server console access, you should always take appropriate steps and care to secure your server console from both physical and remote (for example, RConsole) unauthorized access. Third-party utilities, such as DreamLAN Network Consulting’s SSLock for NDS and Protocom Development Systems’ SecureConsole can enhance your server console security. See Chapter 15 for additional information.

If you administered NetWare networks prior to NetWare 4.0, you know that the user Supervisor can’t be deleted (at least not by accident and not through standard management tools such as SYSCON). With NetWare 4 and higher, however, it is possible for you to (accidentally) remove the Admin user and leave yourself with an unmanageable NDS/eDirectory tree! Chapter 15 contains information on how to safeguard your administrative accounts so you’ll never have an unmanageable tree. In the unpleasant event that you’ve lost your Admin user, here are some solutions.

If it is a single-server test tree or a tree that can easily be recreated, you can use the following steps to re-create a new Admin user:

Another solution is to open an incident with Novell Technical Support. NTS can help you to create a user with Supervisor rights to [Root] and, thus, admin rights to your tree, via remote access.

Yet another option is to use the MakeSU (“Make SuperUser”) NLM from DreamLAN Networking Consulting. This can create a DS User object that has Supervisor rights to [Root]. Visit www.dreamlan.com/makesu.htm for more information.

Unlike the first option, the last two options will create an Admin user in a nondestructive manner.

Similar to NetWare file system’s Inherited Rights Filters (IRFs), DS administrators can apply IRFs to DS objects so they are not accessible by other users except those that have trustee assignments. The one main difference between file system IRFs and DS IRFs is that you can use IRF to block Supervisor access to DS objects while you can’t do this in file systems. Therefore, it is not uncommon for security-conscious DS administrators to protect administrative accounts, such as Admin and admin-equivalent user objects, using IRFs. For details on how to protect DS objects, especially Admin-type user objects, from tampering, see Chapter 15. The following section deals with what to do if you need access to IRF-blocked objects.

IRF-blocked objects can be categorized into three types: visible but unmanageable (you can’t delete or modify them), invisible but manageable, and invisible and unmanageable. The invisible objects are generally referred to as stealth objects. You can’t see stealth objects easily using the standard management utilities, such as ConsoleOne, because the IRF blocked the Browse right to the object. They can be detected, however, using certain techniques (if they leave a “footprint” via ACL assignments, for example) and using specialized utilities. You’ll find a discussion of one of the utilities, Hidden Object Locator, in Chapter 15.

Once the unmanageable object names are determined, you can regain access to them using one of the following methods:

Write Your Own Utility

Although there are a large number of utilities available to assist you in data recovery, every network is unique, and you may have specific requirements that the available utilities do not address. If you have some programming background or have access to a programmer, coding your own recovery utility is an option.

A wide variety of tools that interface with network services and NDS/eDirectory are available for your choosing. You’re not limited to using the C programming language, as was the case in the past when programming for NetWare and other operating systems. Novell and third-party vendors offer class libraries, JavaBeans, scripting languages (such as Visual Basic, JavaScript and Perl), and C/C++ APIs to support the widest range of developer participation and opportunity. Chapter 10 offers some examples on how you can “roll your own” data recovery utilities.