This is a practical reference for engineers who must understand, recover, operate, or retire a Novell NetWare environment. It is not a replacement for the manual matching the exact server version, support pack, hardware driver set, eDirectory build, and installed applications.

WORKING ASSUMPTION: The operational detail is centered on NetWare 4.x through 6.5, while NetWare 3.12 and Bindery behavior are called out where they differ. Commands marked as examples must be validated on the target server before use.

Scope and conventions Back to contents

Server-console commands appear in uppercase for readability; NetWare commands are generally not case-sensitive.
A path such as SYS:SYSTEM identifies a volume and directory. A path such as SERVER/SYS:PUBLIC also identifies the server.
NDS refers to Novell Directory Services; later documentation uses eDirectory. In this guide, NDS/eDirectory means the directory service family.
TFS means the NetWare Traditional File System. NSS means Novell Storage Services.
Source markers such as [S2] refer to the official source set in Appendix C.

Support and security status Back to contents

NetWare 6.5 SP8 is the terminal NetWare release line. It entered extended support in 2010, and the vendor’s later Premium Lifeline offering ended on 31 December 2016. It must therefore be treated as unsupported legacy infrastructure in 2026. [S1, S13]

SECURITY BOUNDARY: Do not expose NCP, SLP, IPX routing, Telnet, RConsoleJ, legacy web administration, LDAP, or old TLS endpoints directly to the Internet or to an untrusted enterprise segment. Place the server behind an allow-list firewall on an isolated VLAN and administer it through a controlled jump host or modern encrypted tunnel.

Use unique legacy credentials; do not reuse current privileged passwords.
Disable services and protocols that are not required, particularly Telnet, IPX, anonymous LDAP, and legacy web components.
Keep ALLOW UNENCRYPTED PASSWORDS set to OFF unless a documented, temporary compatibility exception exists. [S2]
Assume that old cryptographic implementations and browser-based interfaces do not meet modern security baselines.
Capture configuration and recovery media before every change because replacement drivers, patches, and vendor support are scarce.

Version families at a glance Back to contents

Version family summary

Family	Directory model	Network emphasis	Operational significance
2.x	Per-server Bindery	IPX/SPX	Dedicated 286-era file server; highly version- and hardware-specific.
3.x / 3.12	Per-server Bindery	IPX/SPX with SAP/RIP	32-bit 386 line; NLM model; mature departmental file and print platform.
4.x / intraNetWare	NDS tree plus Bindery emulation	IPX/SPX; IP add-ons	Introduced global directory, partitions, replicas, and directory-based administration.
5.0 / 5.1	NDS	Native IP plus optional IPX	NCP became transport-independent; SLP and NSS became central; multiprocessor and memory model advanced. [S14]
6.0	eDirectory	IP preferred; IPX optional	Expanded web access, iPrint/iFolder era services, and user-oriented licensing.
6.5 / SP8	eDirectory 8.7.3 or 8.8.x	IP preferred; IPX retained	Final mature NetWare line. New SP8 installs used eDirectory 8.8.4; updated systems could retain 8.7.3. [S1]
OES / Enterprise Server	eDirectory on Linux	IP	Successor platform providing NCP, NSS, trustee semantics, CIFS, iPrint, and migration paths without the NetWare kernel. [S12]

Compatibility questions to ask first Back to contents

What exact NetWare version, support pack, eDirectory version, JVM, and application build are installed?
Is the server Bindery-only, NDS/eDirectory-native, or serving legacy clients through Bindery emulation?
Are clients using IPX, native IP, or both? Which Ethernet frame types and SLP scopes are in use?
Are volumes Traditional or NSS? Which namespaces, trustee assignments, quotas, compression, encryption, and salvage policies exist?
Does the server hold directory partitions or replicas, and is it a Master replica, time source, SLP Directory Agent, Organizational CA host, licensing host, or cluster node?
Which third-party NLMs, backup agents, database engines, and hardware-specific .HAM, .CDM, .LAN, and .PSM drivers are required?
Are licenses, installation media, overlay media, support packs, driver disks, and keys preserved and legally usable?

Architecture and operating model Back to contents

The NetWare mental model Back to contents

NetWare is a network services operating system, not a general-purpose desktop Unix or Windows server. The kernel is optimized around file, print, directory, protocol, and application services. Administrators interact with a server console and loadable modules; users interact through NCP clients, mappings, login scripts, and directory objects.

Logical layers

Layer	Examples	Role
Clients	DOS requester, VLM, Client32, Novell Client, NetStorage	Authenticate, discover services, map paths, consume file/print services.
Directory	Bindery or NDS/eDirectory	Stores identities, groups, servers, volumes, policies, schema, and service objects.
Application/file service	NCP, queue print, NDPS/iPrint, GroupWise, Btrieve	Presents network resources and application services.
Discovery and transport	SAP/RIP over IPX; SLP over IP; TCP/UDP	Locates services and carries NCP or application traffic.
File system	Traditional volumes or NSS pools and volumes	Stores data, trustees, attributes, quotas, namespaces, and salvage metadata.
Runtime	SERVER.EXE, NLMs, protected address spaces	Executes kernel services, drivers, protocol stacks, and server applications.
Hardware interface	PSM, HAM, CDM, LAN drivers, NWPA	Connects processors, storage, and network adapters to the runtime.

KEY DISTINCTION: An eDirectory Volume object represents a volume in the directory, but file access is governed by trustee metadata stored in the file system. Directory rights and file-system rights are related administration domains, not interchangeable ACLs. [S8]

Bindery versus NDS and eDirectory Back to contents

Directory model comparison

Characteristic	Bindery	NDS/eDirectory
Scope	One database per server	Distributed tree spanning servers and sites
Naming	Flat object names on a selected server	Hierarchical distinguished names in containers
Administration	Repeat users/groups on each server	Create identities and policies once in the tree
Resilience	Server-local backup and recovery	Partitions and replicas provide distributed availability
Legacy support	Native to 2.x/3.x	4.x+ can expose selected containers as a Bindery context
Authentication target	Server	Tree and context, with a server used to reach a replica

Core services stack Back to contents

NCP provides file-service semantics, connection management, locking, trustee enforcement, and related client services.
NDS/eDirectory provides identities, objects, schema, authentication, partitions, and replication.
NSS provides a journaling file system, storage pools, volumes, trustee metadata, salvage, quotas, compression, and optional encryption.
IPX/SPX with SAP/RIP supplies legacy transport and discovery; TCP/IP with SLP supplies the later native-IP equivalent.
NLMs extend the kernel with drivers, protocol stacks, management tools, backup agents, and server applications.

Boot, configuration, and runtime Back to contents

Boot sequence Back to contents

The machine firmware starts the boot device and the small DOS boot environment used by classic NetWare installations.
AUTOEXEC.BAT normally changes to C:\NWSERVER and invokes SERVER.EXE.
SERVER.EXE reads STARTUP.NCF from the boot directory, applies pre-mount SET parameters, and loads platform and storage drivers.
The server discovers storage and mounts SYS. If SYS cannot mount, SYS:SYSTEM modules and AUTOEXEC.NCF are unavailable.
SYS:SYSTEM\AUTOEXEC.NCF executes, setting the server identity and loading LAN drivers, protocols, directory services, logging, and installed applications.
Additional service-specific NCF files are called in their configured order. Users and clients can then discover and connect to the server.

RECOVERY PRINCIPLE: Separate pre-SYS failures from post-SYS failures. STARTUP.NCF, platform support, and storage drivers dominate the first class. AUTOEXEC.NCF, network bindings, directory services, and application NLMs dominate the second.

NCF configuration files Back to contents

Important NCF files

File	Normal location	Purpose
STARTUP.NCF	C:\NWSERVER	Pre-SYS parameters plus platform and storage driver load order.
AUTOEXEC.NCF	SYS:SYSTEM	Server identity, network drivers/bindings, services, and application start order.
SHUTDOWN.NCF	SYS:SYSTEM	Optional orderly unload or stop commands run by DOWN or restart. [S2]
SECURE.NCF	Configured location	Optional commands executed through the secure-start mechanism.
Application .NCF	Usually SYS:SYSTEM or application path	Starts or stops a product-specific set of NLMs.

Use EDIT or NWCONFIG to change NCF files, and retain a dated known-good copy before editing.
Place CONLOG near the beginning of AUTOEXEC.NCF if early console messages are needed; the default log is SYS:ETC\CONSOLE.LOG. [S2]
Only persist a SET parameter after confirming whether it belongs in STARTUP.NCF or AUTOEXEC.NCF. The SET display identifies valid locations. [S2]
Do not reorder storage, directory, or application modules without documenting dependencies.

Safe boot and recovery switches Back to contents

SERVER and restart switches

Invocation	Effect	Use
SERVER -NS	Skips STARTUP.NCF	Diagnose a bad pre-mount parameter or driver line; storage may need loading manually.
SERVER -NA	Skips AUTOEXEC.NCF	Mount SYS but prevent post-mount services and applications from starting.
SERVER -S filename.NCF	Uses an alternate startup file	Boot a controlled known-good driver set. [S1, S2]
RESTART SERVER -NS	Restarts without STARTUP.NCF	Repeat controlled pre-mount diagnosis.
RESTART SERVER -NA	Restarts without AUTOEXEC.NCF	Repeat controlled post-mount diagnosis.

BEFORE REPAIR: Photograph or capture the console, preserve BOOT$LOG.ERR, CONSOLE.LOG, ABEND.LOG, STARTUP.NCF, AUTOEXEC.NCF, driver versions, and disk layout. Do not begin with VREPAIR, REBUILD, or DSREPAIR repair operations merely because the server failed to boot.

NLMs and protected address spaces Back to contents

LOAD links an NLM or driver into the operating system; UNLOAD releases it and returns resources. Many server utilities can be loaded when needed, while LAN, storage, directory, and protocol modules form persistent dependencies. MODULES lists loaded modules and their address spaces. [S2, S3]

Kernel address space provides maximum integration but a faulty NLM can abend the server.
Protected address spaces run suitable applications in ring 3. PROTECT filename.NCF loads the modules from an NCF into a named protected space.
PROTECTION lists protected spaces and can enable restart behavior. Drivers, SERVER.EXE, and some core modules cannot run protected.
Unload dependent modules in reverse order. Never force-kill an address space until the data-integrity and vendor implications are understood.

Networking and service discovery Back to contents

IPX and SPX environments Back to contents

Legacy IPX/SPX components

Component	Function	Diagnostic focus
IPX	Connectionless routed network protocol	Network numbers, frame types, bindings, routes
SPX	Connection-oriented transport over IPX	Sessions, sequence/retry behavior, compatible stack
SAP	Advertises server and service names	DISPLAY SERVERS; hop count; filtering
RIP/NLSP	Routes IPX networks	DISPLAY NETWORKS; duplicate network numbers; convergence
NCP/IPX	Carries NetWare file and service requests	NCPIPX.NLM, connection state, packet loss
ODI	Client LAN driver and protocol interface	LSL, NIC driver, frame type, IPXODI/VLM order

Common Ethernet frame types include ETHERNET_802.2, ETHERNET_II, ETHERNET_802.3, and ETHERNET_SNAP. A client and server can share the physical Ethernet while remaining logically invisible if frame type or external network numbers do not match.

IPX DISPLAY CAVEAT: DISPLAY SERVERS and DISPLAY NETWORKS show SAP/RIP information. They are not native-IP service-discovery commands; use SLP and TCP/IP tools for IP-only systems. [S2]

Native IP and SLP environments Back to contents

NetWare 5 made NCP transport-independent and introduced a practical pure-IP deployment model. NCP over TCP/UDP uses native IP, while Service Location Protocol (SLP) replaces much of the name-to-address discovery previously supplied by SAP. [S3, S14]

SLP User Agents issue queries, Server Agents register services, and Directory Agents provide a repository for registrations.
Named SLP scopes partition discovery information. A server or client that queries the wrong scope can appear unable to find an otherwise healthy service.
SLP uses TCP and UDP port 427. NCP over IP uses port 524. [S14]
SYS:ETC\SLP.CFG can define static Directory Agents with DA IPV4 entries; DHCP options 78 and 79 can also supply agents and scopes.
Directory replication can be affected when NDAP and Bindery service entries are absent from the scopes used by replica servers.

Core ports and flows Back to contents

Common TCP/UDP ports – verify against the installed service configuration

Port	Protocol/service	Operational note
524 TCP/UDP	NCP over IP / eDirectory service access	Primary Novell client and server service path.
427 TCP/UDP	SLP	Service queries, registrations, and Directory Agent traffic.
389 TCP	LDAP	Directory access; clear-text unless protected externally or upgraded to TLS.
636 TCP	LDAPS	Directory access over legacy TLS; validate certificate and cipher compatibility.
123 UDP	NTP	Time synchronization when XNTPD/NTP is selected.
53 TCP/UDP	DNS	Name service when DNS is hosted or consumed.
80/443 TCP	Apache, iManager, NetStorage, iPrint or application web services	Actual bindings vary by installed pattern and reverse proxy design.
8008/8009 TCP	Novell Remote Manager, commonly	Version/configuration dependent; never expose to an untrusted segment.
413 TCP	SMDR, commonly	Storage Management Services remote backup communication. [S3]
2034-2036 TCP	RConsoleJ agent/proxy variants	Historical remote console ports; firewall-only and version dependent. [S2]

FIREWALL RULE METHOD: Inventory listening modules and configured bindings on the actual server, capture a known-good traffic trace, then allow only required source/destination pairs. Do not use a generic ‘NetWare ports’ rule set as an exposure baseline.

Client-to-file-service flow Back to contents

The client obtains a server or tree target from a preferred server, preferred tree, explicit name, SLP, SAP, DNS, or cached configuration.
The client resolves the service to an IP or IPX address and opens an NCP connection.
The user authenticates to the Bindery server or to NDS/eDirectory through a server holding or locating the required replica.
Container, profile, and user login scripts execute and create drive/search mappings.
NCP evaluates trustee rights, IRFs, security equivalence, file attributes, locks, quotas, and namespace rules for each operation.

NDS and eDirectory administration Back to contents

Tree structure and naming Back to contents

Common eDirectory objects

Object	Purpose	Typical relationship
[Root]	Top of one directory tree	Contains top-level organizations and holds the root partition.
O / Organization	Top-level administrative container	Often represents the enterprise.
OU / Organizational Unit	Delegation and policy container	Often represents geography, function, or service domain.
User	Identity and login properties	Member of groups; may have home directory and login script.
Group	Security equivalence and shared assignment	Used for file trustees and application roles.
Server	Represents a server	Associated with volumes, addresses, services, and directory replicas.
Volume	Directory representation of a volume	Points users and tools to file storage; data rights remain in the file system.
Profile	Reusable login script	Assigned to users between container and user scripts.
Alias / Directory Map	Alternate object name or path abstraction	Reduces path coupling and supports user-friendly mappings.

Typed name: CN=PJONES.OU=ARCHITECTURE.O=ACME
Typeless name: PJONES.ARCHITECTURE.ACME
Absolute name: .PJONES.ARCHITECTURE.ACME
Relative name: PJONES (when the current context is ARCHITECTURE.ACME)

Dot notation is written from the leaf toward [Root]. LDAP notation normally reverses the order and separates components with commas, for example CN=PJONES,OU=ARCHITECTURE,O=ACME.

Partitions, replicas, and replica rings Back to contents

A partition is a contiguous subtree stored and replicated as a unit.
The Master replica coordinates partition operations. Read/Write replicas accept updates; Read-Only replicas serve reads; Subordinate Reference replicas preserve connectivity across partition boundaries.
All servers holding a replica of a partition form its replica ring. A healthy ring exchanges changes and agrees on partition and replica metadata.
Partitions improve scale and locality; replicas improve availability. Excessive partitioning or poorly placed replicas increase synchronization and WAN complexity.
The first servers in a new tree normally receive root-partition replicas; later placement should be planned around site availability and directory dependencies. [S7]

MASTER IS NOT PRIMARY: Ordinary object writes can occur on writable replicas. The Master is special for partition and replica operations; it is not a single writable directory server in the Active Directory PDC sense.

Bindery emulation Back to contents

NetWare 4.x and later can present selected NDS/eDirectory containers to Bindery-aware clients and applications. The BINDERY CONTEXT SET parameter identifies up to 16 containers, separated by semicolons, whose objects are exposed through Bindery services. [S2]

SET BINDERY CONTEXT = OU=SALES.O=ACME;OU=ACCOUNTING.O=ACME

The specified containers must be available on the server through local directory replicas or references.
Bindery-aware applications see a flat view and can encounter duplicate short names across contexts.
Changing the Bindery context is a compatibility change; test authentication, print, backup, and application dependencies.

Time synchronization and directory health Back to contents

Directory operations depend on coherent timestamps. Official health procedures call for time checks, replica synchronization checks, schema checks, and review of obituaries and directory versions. A dynamic tree should be checked about weekly; a static tree about monthly, and every tree before a major directory operation. [S10]

LOAD DSREPAIR
Time Synchronization
Report Synchronization Status

SET DSTRACE=ON
SET DSTRACE=NODEBUG
SET DSTRACE=+S
SET DSTRACE=*H
Expected healthy indicator: All Processed = Yes
SET DSTRACE=NODEBUG
SET DSTRACE=OFF

DO NOT REPAIR BY REFLEX: DSREPAIR is both a diagnostic and a repair tool. Start with time, version, replica, and synchronization reports. Preserve a supported directory backup and understand the replica ring before initiating destructive or topology-changing repair options.

Directory administration tools Back to contents

Directory tool map

Tool	Best use	Caution
NWAdmin	Classic Windows NDS object administration	Snap-ins and behavior are version specific.
ConsoleOne	Cross-platform objects, schema, rights, and product snap-ins	Java/runtime dependencies can be fragile.
iManager	Browser-based role and task administration	Old TLS and plug-ins require isolation and compatible browser/runtime.
iMonitor	Directory health, partitions, replicas, agents, traces	Diagnostic visibility can expose sensitive directory data.
DSREPAIR	Time, replica, database, and synchronization diagnostics/repair	Use health reports first; repairs can alter directory state.
DSTRACE	Live directory process and synchronization trace	Filters can be noisy; capture to file and disable when finished.

Rights and security model Back to contents

File system trustee rights Back to contents

File and directory trustee rights

Code	Right	Meaning
S	Supervisor	All file-system rights; cannot be blocked by an IRF.
R	Read	Open and read files.
W	Write	Modify file contents.
C	Create	Create files/subdirectories; supports salvage semantics where applicable.
E	Erase	Delete files and directories.
M	Modify	Rename items and change file or directory attributes.
F	File Scan	See and search names in the file-system structure.
A	Access Control	Add/remove trustees and change trustee rights and IRFs.

The workstation RIGHTS utility displays or changes assignments. ALL grants all rights except Supervisor. A plus adds rights, a minus removes rights, and a rights list without plus/minus replaces the assignment. [S2]

RIGHTS SYS:DATA R W C E M F /NAME=.TEAM_ARCHITECTURE.ACME
RIGHTS SYS:DATA /NAME=.PJONES.ARCHITECTURE.ACME /I
RIGHTS SYS:DATA /T
RIGHTS SYS:DATA REM /NAME=.OLDGROUP.ACME

eDirectory object and property rights Back to contents

eDirectory rights

Class	Right	Meaning
Object	Supervisor	All rights to the object and its properties.
Object	Browse	See the object; does not reveal its property values.
Object	Create	Create objects beneath a container; includes Browse.
Object	Delete	Delete the target object.
Object	Rename	Change the target object’s name.
Property	Supervisor	Complete control over the selected property.
Property	Compare	Test a value without reading it.
Property	Read	Read property values; includes Compare.
Property	Write	Create, change, or delete property values.
Property	Add Self	Add/remove the trustee itself in object-valued properties such as group membership.

SENSITIVE DELEGATION: Broad Read access to all User attributes can expose password-management attributes in some eDirectory configurations. Delegate only the object and property rights required for the task. [S8]

Effective rights and inherited rights filters Back to contents

Effective rights are the rights available at the moment of access after NetWare/eDirectory combines explicit trustee assignments, group membership, security equivalence, inherited assignments, and the applicable IRFs. [S8]

An IRF removes selected rights as they flow down a directory or file-system hierarchy.
A lower explicit trustee assignment can add required rights back at the target level.
File-system Supervisor cannot be filtered by a file-system IRF; assign it sparingly.
An apparent rights failure can instead be a visibility failure: File Scan is required to see names, and Read is required to open content.
Check the user’s direct assignment, group assignments, security equivalences, IRFs along the path, the target’s explicit assignment, and file attributes.

Practical rights patterns Back to contents

Common assignment patterns

Use case	Suggested trustee pattern	Notes
Home directory	User: R W C E M F; administrator group: S	Set at each home root or through automated provisioning; protect parent visibility.
Shared read-only data	Reader group: R F	Read alone is insufficient for useful browsing; File Scan exposes names.
Shared working area	Contributor group: R W C E M F	Exclude Access Control unless users must delegate rights.
Drop box	Purpose-built rights and visibility design	Test create, read-back, overwrite, rename, delete, and listing behavior separately.
Delegated folder owner	R W C E M F A	Access Control permits trustee/IRF changes; does not confer Supervisor.
Service account	Dedicated group with minimum path-specific rights	Avoid security equivalence to Admin or broad container-level Supervisor.

File and directory attributes Back to contents

Common attributes

Attribute	Effect / use
Read Only	Prevents file modification; older implementations may also imply rename/delete protection.
Archive	Marks a file as changed for archive-aware backup workflows.
Hidden / System	Controls client visibility and marks operating-system content.
Shareable	Permits compatible shared access semantics.
Transactional	Enables transaction tracking where supported.
Purge Immediate	Deletes without retaining a salvageable copy.
Rename Inhibit	Prevents renaming.
Delete Inhibit	Prevents deletion.
Copy Inhibit	Restricts copying where supported by the client/protocol path.

Attribute support varies between Traditional and NSS volumes and between access protocols. A change is effective only when the underlying file system and NCP path can enforce it. [S6]

Storage, volumes, and file systems Back to contents

Traditional file system versus NSS Back to contents

File-system comparison

Characteristic	Traditional file system	NSS
Structure	NetWare partition containing one or more volumes	Devices/partitions feed pools; pools contain logical volumes
Recovery	VREPAIR on an unmounted volume	VERIFY/REBUILD and NSS-specific tools; VREPAIR is not used
Mount behavior	Directory/FAT structures can make large-volume recovery slow	Journaling and modern metadata support faster activation
Capacity model	Fixed allocation within the NetWare partition	Volumes allocate pool space dynamically and can be overbooked
Namespaces	DOS plus added LONG/MAC/NFS namespaces	Multiple namespaces integrated into NSS semantics
Advanced features	Trustees, salvage, compression on supported versions	Trustees, quotas, salvage, compression, snapshots/DFS options, encryption
Migration	Requires metadata-aware copy and namespace planning	Designed for compatibility with OES NSS and NCP services

NSS storage hierarchy Back to contents

Physical disks, SAN LUNs, RAID devices, virtual disks, or multipath devices are presented as storage devices.
NSS partitions or segments allocate device space to one or more pools.
A pool aggregates space and can span devices. Its failure domain therefore includes every device contributing segments.
One or more NSS volumes allocate space from a pool only as needed. A volume belongs to one pool; a pool can contain multiple volumes.
NCP, CIFS, AFP, NetStorage, and application services expose the volume through their configured identity and trustee model.

NetWare 6.5 NSS supports dynamic volume growth within a pool and overbooking. The official guide describes volumes up to 8 TB and very large file counts, while individual devices presented to NetWare NSS are limited to 2 TB. Verify the exact build, device carving, and storage vendor limits before expansion. [S5]

POOL FAILURE DOMAIN: Spanning a pool across devices increases capacity but also couples availability. Hardware RAID, NSS mirroring, SAN protection, multipathing, and backup are different controls; document which layer actually protects each segment.

Namespaces and path compatibility Back to contents

A namespace records names and metadata for a client environment. Traditional volumes begin with DOS semantics and can add LONG for Windows/OS2, MAC for Macintosh, and NFS for Unix-style names. [S2]

LOAD LONG.NAM
ADD NAME SPACE LONG TO DATA

REM Equivalent choices exist for MAC and NFS where the modules are installed.

Do not remove a namespace until every file name and metadata dependency has been assessed.
Migration tools may require the NFS namespace on a Traditional source volume to preserve names and metadata correctly.
Case, forbidden characters, alternate data, Macintosh metadata, and long-name collisions must be tested against the destination protocol.

Salvage, purge, quotas, and capacity Back to contents

Salvage retains deleted files until they are restored, purged, or reclaimed according to policy. It is not a backup because it shares the same volume and failure domain.
Purge permanently removes salvageable files. PURGE IMMEDIATE bypasses recovery for selected files/directories.
NSS can enable salvage per volume; NSS console commands include NSS /SALVAGE=volume and NSS /NOSALVAGE=volume. [S2, S5]
User, directory, and volume quotas control consumption. Always check the pool as well as the logical volume: an overbooked pool can exhaust physical space before volume quotas appear full.
Keep SYS for operating-system and extension content where practical; place user data and applications on separate pools/volumes. [S5]

Repair boundaries Back to contents

Repair decision table

Target	Diagnostic / repair family	Boundary
Traditional volume	VOLUME/VOLUMES, MONITOR, VREPAIR	Dismount before VREPAIR; preserve logs and backup first.
NSS volume/pool	NSS /STATUS, NSSMU, VERIFY/REBUILD, iManager/NRM	Do not use VREPAIR; confirm pool/device state before metadata repair.
eDirectory	iMonitor, DSREPAIR, DSTRACE	Directory repair is separate from volume repair; start with health checks.
Hardware/storage path	NWPA/driver tools, vendor array, mirror/RAID status	File-system repair cannot correct a failing controller, path, or LUN.
Application data	Vendor consistency and recovery tools	A mounted volume does not prove a database or message store is consistent.

Clients, drive mappings, and login scripts Back to contents

Client families Back to contents

Client generations

Client	Typical environment	Key components / notes
NETX requester	Early DOS / Bindery	Small conventional-memory requester; server-centric login.
VLM client	DOS / NDS	LSL + ODI LAN driver + IPXODI + VLM modules; NDS-aware.
Client32	Windows 3.x/9x	32-bit client stack, NDS login, improved cache and transport support.
Novell Client	Windows NT through supported later Windows releases	NCP, eDirectory authentication, SLP, mappings, trustee extensions.
Novell Client for Linux	Linux workstations	NCP and eDirectory integration; some login-script commands differ.
NetStorage	Browser/WebDAV-style access	Interprets selected MAP and conditional login-script commands.
CIFS/AFP/NFS	Native OS access	Protocol-specific identity mapping and metadata semantics; not identical to NCP.

Path syntax and mappings Back to contents

Path examples

Form	Example	Meaning
Current server	SYS:PUBLIC	PUBLIC directory on SYS of the current/default server.
Server qualified	NW65LAB/SYS:PUBLIC	PUBLIC on SYS of server NW65LAB.
Object qualified	.DATA.NW65LAB.SERVERS.ACME:PROJECTS	Directory under a Volume object identified from [Root].
Drive mapping	MAP G:=NW65LAB/DATA:PROJECTS	Map G to the explicit server/volume path.
Home mapping	MAP H:=%HOME_DIRECTORY	Map from the user’s eDirectory Home Directory property.
Search drive	MAP INS S1:=SYS:PUBLIC	Insert a program search mapping without replacing existing search drives.
Fake root	MAP ROOT F:=SERVER/VOL:APP	Present APP as the apparent root for a legacy application.

Login script execution order Back to contents

The container login script runs first and establishes defaults for users in that O or OU.
The assigned Profile object’s login script runs next and adds role- or team-specific mappings.
The User object’s login script runs last and can override earlier mappings.
If the user has no user login script, the built-in default login script runs unless NO_DEFAULT was issued by a container or profile script. [S9]
Prefer reusable container and profile scripts; reserve user scripts for true exceptions.
Use IF MEMBER OF to drive group-based mappings, INCLUDE for shared text scripts, and MAP DISPLAY OFF/ON for clean output.
The last conflicting MAP wins. Diagnose the full chain rather than only the user script.

Login script example Back to contents

REM Container/Profile example – validate names and client behavior
MAP DISPLAY OFF
MAP ERRORS OFF
MAP INS S1:=NW65LAB/SYS:PUBLIC
MAP H:=%HOME_DIRECTORY

IF MEMBER OF “.TEAM_ARCHITECTURE.ACME” THEN
MAP G:=NW65LAB/DATA:ARCHITECTURE
END

IF MEMBER OF “.NETWARE_ADMINS.ACME” THEN
MAP M:=NW65LAB/SYS:SYSTEM
END

MAP ERRORS ON
MAP DISPLAY ON
MAP

TEST MATRIX: Test login scripts with each supported client family, transport, context, roaming site, and group combination. A script that works in the Windows Novell Client may be only partially implemented by the Linux client or NetStorage. [S9]

Administration quick reference Back to contents

Primary administration tools Back to contents

Administration tool map

Tool	Runs at	Primary job
System Console	Server	Core commands, screen switching, NLM control, boot and emergency operation.
MONITOR	Server console	Connections, CPU, memory, service processes, storage, LAN statistics, SET parameters.
NWCONFIG	Server console	Drivers, products, NCF editing, installation options, traditional volume tasks.
INETCFG / TCPCON	Server console	Protocol configuration and live TCP/IP status/statistics.
NSSMU	Server console	NSS devices, partitions, pools, volumes, RAID, and attributes.
Novell Remote Manager	Web browser	Health, console, modules, connections, volumes, parameters, logs, diagnostics. [S11]
iManager	Web browser	Role-based eDirectory, NSS, files, rights, certificates, and service administration.
ConsoleOne / NWAdmin	Workstation or server GUI	Directory objects, schema, rights, login scripts, and product snap-ins.

Console command quick reference Back to contents

Common server-console commands

Command	Purpose	Notes
HELP [command] / HELP ALL	Show console command help	Prefer local help because loaded modules register additional commands.
VERSION	Show NetWare, support pack, license, and eDirectory versions	Record before any change.
CONFIG	Show server, LAN, IPX, tree, and Bindery context information	Useful hardware/network baseline.
TIME	Show server time	Compare with directory time sources.
MODULES [prefix*]	List loaded modules and address spaces	Use before unload or abend analysis.
SEARCH	Show or modify NLM search paths	Unexpected paths can load the wrong module version.
MEMORY	Show installed/addressable memory	Use NRM for deeper attribution.
DISPLAY PROCESSORS	Show processor online/offline state	NetWare 5/6 multiprocessor environments.
DISPLAY ENVIRONMENT	Show search paths and SET parameters	DISPLAY MODIFIED ENVIRONMENT shows deviations only.
SET	Browse or change server parameters	Confirm valid range and persistence file.
MONITOR	Open live system monitor	Connections, resources, parameters, storage, LAN.
LOAD / UNLOAD	Link or unlink an NLM or driver	Respect dependencies and application shutdown procedure.
PROTECT file.NCF	Load an NCF into a protected address space	Only for compatible modules.
PROTECTION	List/configure protected spaces	Can enable restart behavior.
MOUNT volume / MOUNT ALL	Mount volumes	Use NSS tools for NSS-specific activation issues.
DISMOUNT volume	Make a volume unavailable	Close files and stop dependent applications first.
VOLUME / VOLUMES	List mounted volumes	Spelling varies by release/module registration.
NSS /STATUS / NSS /HELP	Show NSS state and help	NSS commands are version specific.
NSSMU	Open NSS management utility	Destructive functions can erase device metadata.
NWCONFIG	Open server configuration	Driver/product/NCF and traditional storage tasks.
INETCFG / TCPCON	Configure or monitor networking	Save before restart; distinguish configuration from live state.
PING / TPING	Test IP reachability	TPING syntax and implementation vary.
DISPLAY SERVERS	List SAP-advertised IPX services	Not an IP/SLP discovery test.
DISPLAY SLP …	Show SLP agents, services, addresses, or types	Exact subcommands depend on SLP.NLM build.
DSREPAIR	Directory diagnostics and repair	Start with time and sync reports.
SET DSTRACE=…	Control directory trace	Disable filters/logging when complete.
CONLOG	Capture console messages	Default SYS:ETC\CONSOLE.LOG; load early.
DISABLE LOGIN / ENABLE LOGIN	Control new logins	Existing connections remain until cleared or logged out.
SECURE CONSOLE	Restrict console operations	Load required nonstandard-path modules first. [S2]
DOWN	Orderly shutdown	Flushes caches, closes files, executes SHUTDOWN.NCF.
RESTART SERVER [-NA\|-NS]	Orderly NetWare restart	Use diagnostic switches deliberately.

Workstation utility quick reference Back to contents

Common client/workstation utilities

Utility	Purpose	Example
LOGIN	Authenticate and execute login scripts	LOGIN TREE/USER or LOGIN SERVER/USER
LOGOUT	Close authenticated connections	LOGOUT or client GUI equivalent
MAP	View/create/delete drive and search mappings	MAP G:=SERVER/VOL:PATH
CX	View/change eDirectory context	CX /T /A
RIGHTS	View/change file trustees, rights, IRF, and sources	RIGHTS path /NAME=user /I
FLAG	View/change file or directory attributes	Syntax varies; prefer client property page for safety
SALVAGE / PURGE	Restore or permanently remove deleted files	Use client GUI or matching release utility
CAPTURE / NPRINT	Legacy queue-based print redirection/submit	Version and client dependent

Core NLM quick reference Back to contents

Common modules – not exhaustive

Module	Role	Operational warning
DS.NLM	NDS/eDirectory engine	Directory-dependent services and authentication rely on it.
NCP.NLM / CONNMGR.NLM	Core NCP and connection services	Foundation for client file service.
NCPIP.NLM	NCP over TCP/UDP	Unloading removes IP NCP access. [S3]
NCPIPX.NLM	NCP over IPX	Legacy transport; not intended for casual unload after activation.
TCPIP.NLM	TCP/IP stack	Large dependency tree; use INETCFG/TCPCON.
IPXSPX.NLM	IPX/SPX stack	Required by legacy IPX clients/services.
SLP.NLM / SLPDA.NLM	IP service discovery / Directory Agent	Scopes and directory replicas affect availability.
NSS.NLM	Novell Storage Services	Do not unload with active NSS volumes or dependent services.
NWPA.NLM	Storage driver architecture	HAM/CDM storage access depends on it. [S3]
MONITOR.NLM	System monitoring	Can be loaded and unloaded as a utility.
NWCONFIG.NLM	Server configuration	Installation and driver operations can alter NCF files.
DSREPAIR.NLM	Directory diagnostics/repair	Repairs can change replicated state.
CONLOG.NLM	Console logging	Configure rotation; unlimited logs can consume SYS.
PORTAL.NLM / HTTPSTK.NLM	Remote Manager and HTTP stack	Legacy web/TLS exposure requires containment.
TIMESYNC.NLM / XNTPD.NLM	Time synchronization	Use one planned time model; eDirectory depends on stable time.
SMDR.NLM / TSAFS.NLM / SBCON.NLM	Storage Management Services backup	Coordinate application and directory-aware backup.
SNMP.NLM	Monitoring agent	Legacy community-based SNMP is not suitable across untrusted networks.

Illustrative NCF skeletons Back to contents

NOT PASTE-READY: Driver names, load order, bindings, addresses, and SET parameters must come from the target server’s known-good configuration and matching manuals. The skeletons show separation of concerns only.

REM C:\NWSERVER\STARTUP.NCF – schematic only
REM Pre-mount SET parameters validated for this exact release
SET <pre-mount parameter> = <validated value>
REM Platform, storage adapter, and device modules from known-good media
LOAD <platform>.PSM
LOAD <adapter>.HAM <validated parameters>
LOAD <device>.CDM

REM SYS:SYSTEM\AUTOEXEC.NCF – schematic only
FILE SERVER NAME <SERVERNAME>
LOAD CONLOG ARCHIVE=YES MAXIMUM=<validated-kilobytes>
REM Load/bind LAN and protocols or invoke generated network configuration
<known-good network configuration>
REM Start directory, discovery, storage, management, and applications
<service-specific NCF files>
MOUNT ALL

REM SYS:SYSTEM\SHUTDOWN.NCF – schematic only
REM Stop application services in reverse dependency order
<application stop commands>
REM Flush/close product-specific engines before DOWN completes

Operations runbook Back to contents

Daily, weekly, and monthly checks Back to contents

Operational cadence

Cadence	Checks	Evidence to retain
Daily	Server up time; health summary; ABEND.LOG; SYS/pool free space; mirror/RAID/path state; backup completion; time state; critical service availability	Alert record, console/health snapshot, backup result
Weekly	Directory sync for dynamic trees; CONSOLE.LOG and SYS$LOG.ERR review; NLM/application errors; packet buffers; LAN errors; salvage growth; sample restore	DSTRACE/DSREPAIR report, capacity trend, restore evidence
Monthly	Directory health for static trees; replica and partition inventory; DS versions; schema/obituary status; account review; recovery media and cold-image verification	Signed health report and configuration archive
Before major change	Full directory health check; application-consistent backup; boot/config export; driver/media check; rollback rehearsal; maintenance communications	Change record, hash/manifest, rollback decision point

Controlled maintenance shutdown Back to contents

Confirm a current usable backup and record the current VERSION, up time, active modules, volume/pool status, mirror/RAID state, time status, and directory health.
Notify users and application owners; quiesce or stop databases, message stores, print services, and backup jobs through their supported procedures.
Issue DISABLE LOGIN. Review MONITOR connections and open files; have users close data and log out rather than clearing active sessions blindly.
Dismount only the volumes required by the maintenance procedure. Confirm cluster or shared-storage ownership where applicable.
Issue DOWN for an orderly shutdown. DOWN flushes cache, closes files, updates file-system structures, and runs SHUTDOWN.NCF if present. [S2]
Wait for the completion message or return to DOS before powering off or rebooting hardware.
After startup, validate volumes, directory synchronization, SLP/SAP discovery, applications, clients, logging, and backups before re-enabling normal access.

Change preparation checklist Back to contents

Exact server, support pack, eDirectory, NLM, driver, and hardware/virtual hardware versions recorded.
STARTUP.NCF, AUTOEXEC.NCF, SHUTDOWN.NCF, SYS:ETC configuration, driver set, and application NCF files copied and hashed.
Storage map records devices, partitions, pools, volumes, namespaces, quotas, trustee metadata, cluster resources, and free space.
Directory map records tree, partitions, replicas, Master roles, time sources, SLP scopes/DAs, CA host, licensing, and schema extensions.
Application-consistent backup and a directory-aware backup completed; representative restore tested.
Rollback is time-bounded, resourced, and tested; the point beyond which rollback is unsafe is explicit.
Management access remains available if clients, SLP, DNS, or the normal AUTOEXEC.NCF path fails.

Troubleshooting playbooks Back to contents

Server will not start or SYS will not mount Back to contents

Capture the screen and preserve BOOT$LOG.ERR. Classify the failure as before STARTUP.NCF, during driver load, during storage discovery, during SYS mount, or after AUTOEXEC.NCF begins.
Boot with SERVER -NA when SYS can mount but post-mount services fail. Use SERVER -NS or a known-good alternate startup file only when prepared to load required storage support manually.
Compare STARTUP.NCF, platform support, HAM/CDM drivers, firmware, virtual hardware, and device presentation with the known-good baseline.
Confirm the controller/LUN/device is present and stable before attempting file-system repair. A missing or changing device is not a metadata-repair problem.
For a Traditional volume, use VREPAIR only while unmounted and after preserving evidence/backup. For NSS, use NSS status, NSSMU, and the appropriate VERIFY/REBUILD procedure; never VREPAIR an NSS volume.
Once SYS mounts, start AUTOEXEC.NCF services in controlled groups to isolate the failing module or binding.

Clients cannot find a server Back to contents

Discovery fault isolation

Check	IP/SLP environment	IPX/SAP environment
Basic reachability	PING/TPING, routing, VLAN/firewall, DNS	Frame type, external network number, router path
Service discovery	SLP scope, DA list, SYS:ETC\SLP.CFG, port 427	DISPLAY SERVERS, SAP filters, hop count
File service	NCPIP.NLM, TCP/UDP 524, server object address	NCPIPX.NLM, IPX binding/socket
Client settings	Preferred tree/server, SLP DA/scope, protocol order	Preferred server, frame type, network number
Directory dependency	Replica reachability, NDAP service registrations, time	Directory SAP service and route

Authentication or login script failure Back to contents

Separate authentication failure from post-authentication login-script failure. Test a minimal login without application mappings where possible.
Confirm user distinguished name, context, preferred tree/server, password status, account restrictions, and client date/time.
Check server time and DSREPAIR Time Synchronization; then verify the required partition replica is reachable and synchronized.
For legacy clients/applications, verify BINDERY CONTEXT and unique short names.
Trace the container, profile, user, and default login scripts in order. Enable MAP errors and remove conditionals temporarily in a test account, not in production for every user.
Verify that the user is a trustee of the Profile object and that mapped servers/volumes are reachable through the selected protocol. [S9]

Access denied or files are invisible Back to contents

Confirm the exact path, server, volume, namespace, protocol, and user identity. Alias and Directory Map objects can conceal the real target.
Use RIGHTS with /NAME and /I, or the client’s Current Effective Rights view, to identify direct, group, security-equivalent, and inherited rights.
Inspect IRFs at every level from the relevant parent to the target. Confirm that Read and File Scan exist for visibility and content access.
Inspect target file/directory attributes: Read Only, Hidden, Delete Inhibit, Rename Inhibit, Purge Immediate, and protocol-specific enforcement.
Check user/directory/volume quotas, free pool space, open-file and record locks, ownership, and application-level permissions.
Remember that rights on the eDirectory Volume object do not substitute for file-system trustee rights stored on the volume.

Slow response or high utilization Back to contents

Establish whether the delay is client-only, service-specific, server-wide, site-specific, or time-of-day dependent.
Use Novell Remote Manager or MONITOR for CPU, service processes, packet receive buffers, memory, connections, open files, LAN errors, and disk activity.
Check mirror/RAID state, controller errors, LUN latency, low SYS/pool space, salvage backlog, and concurrent backup/antivirus/application jobs.
Review SLP timeouts and DA availability for slow logins; review directory replica placement and time for slow authentication.
Record DISPLAY MODIFIED ENVIRONMENT. NetWare defaults were tuned as a balanced system; do not copy old tuning folklore without evidence. [S4]
If No ECB Available Count grows, investigate dropped packets, driver/TSM compatibility, and packet receive buffers; more buffers consume memory. [S4]

Volume or pool is full Back to contents

Identify whether the constraint is a user quota, directory quota, logical volume quota, physical NSS pool, Traditional partition, SYS, or underlying storage device.
Stop the process generating data before deleting evidence or expanding storage.
Review salvageable files and purge only under an approved retention decision. Salvage is shared-capacity recovery, not free space.
For NSS, check every volume in the pool and account for overbooking. Extend the pool only after validating device size, RAID/path protection, backups, and vendor limits.
For SYS, remove or rotate logs and temporary/support-pack content only when ownership is known. Do not delete hidden directory or product files by pattern.
After remediation, restore alert thresholds, logging rotation, quota controls, and capacity trend monitoring.

Abend or repeated restart Back to contents

Preserve the abend screen, ABEND.LOG, CONSOLE.LOG, core dump if configured, MODULES list, application logs, and the exact preceding change/workload.
Prevent an uncontrolled restart loop. Automatic restart can hide recurring abends; check ABEND.LOG and server up time routinely. [S2, S4]
Identify the faulting NLM, address space, thread, and dependency chain. Determine whether it ran in the kernel or a protected space.
Reproduce only in an isolated clone with matching data and versions. Do not swap NLMs across support packs merely because file names match.
If a protected application space faults, review restart/no-restart policy and product recovery semantics before reloading it.
Treat resulting file-system or application inconsistency separately; a recovered kernel does not prove data consistency.

eDirectory synchronization errors Back to contents

Run the directory health sequence: versions, time synchronization, replica synchronization, schema synchronization, obituaries, and external references.
Verify IP/IPX reachability, NCP/NDAP service addresses, SLP/SAP discovery, DNS, firewall rules, and the replica ring’s server objects.
Use DSREPAIR Report Synchronization Status and DSTRACE filters to collect the error and affected partition; seek All Processed = Yes for healthy rings. [S10]
Resolve time, connectivity, name/address, disk-space, and version defects before repairing the directory database.
Back up directory state and record replica roles before partition, replica, or obituary repairs. Coordinate changes across every server in the ring.

Backup and disaster recovery Back to contents

What a usable backup must preserve Back to contents

Recovery asset inventory

Asset	Preserve	Why
Boot environment	DOS partition/image, SERVER.EXE, STARTUP.NCF, AUTOEXEC.BAT, drivers	Needed before SYS and network services are available.
SYS configuration	AUTOEXEC.NCF, SHUTDOWN.NCF, SYS:ETC, NLM/application config, logs	Reconstructs service identity and load order.
Directory	Supported NDS/eDirectory backup, schema, partitions/replicas, certificates	A file copy of the live DIB is not a supported directory backup.
File data	Files plus trustees, IRFs, ownership, attributes, namespaces, quotas, links	A generic SMB copy can lose NetWare metadata and security.
Applications	Vendor-consistent database/message-store backup and transaction logs	Volume-level consistency does not ensure application consistency.
Storage map	Controller/LUN/RAID, devices, partitions, pools, volumes, cluster resources	Required to present the same data in the same ownership model.
Software entitlement	Install/overlay media, support packs, patches, drivers, licenses, keys	Downloads and activation services may no longer be obtainable.
Operational evidence	Runbooks, credentials escrow, dependencies, test results, hashes	Turns backup media into a repeatable recovery.

BACKUP SEMANTICS: Use Storage Management Services or another NetWare-aware product for trustee and namespace fidelity, plus an application-aware method for databases and directory services. Test the exact restore path; a successful backup job is not evidence of recoverability.

Recovery rehearsal Back to contents

Create an isolated recovery network with no route to production and a controlled time/DNS/SLP design.
Recover the boot environment and virtual/physical hardware drivers, then start with normal NCF files suppressed if necessary.
Present storage consistently and recover SYS before application/data volumes. Validate TFS/NSS type before any repair action.
Restore the directory using its supported method and intended replica topology. Avoid creating duplicate server or tree identities on a connected network.
Restore file data with trustees, IRFs, ownership, attributes, quotas, and namespaces, then application data with vendor consistency checks.
Test representative authentication, login scripts, rights, mappings, locks, salvage, print, backup, and application transactions.
Record recovery time, manual decisions, missing assets, and new hashes. Update the runbook and repeat until another engineer can execute it.

Printing and ancillary services Back to contents

Printing generations Back to contents

NetWare printing models

Model	Core objects/services	Client experience
Queue-based printing	Print Queue, Printer, Print Server; PSERVER; CAPTURE/NPRINT	LPT redirection or queue submission; common in 3.x/4.x.
NDPS	Broker, Manager, Printer Agent; NDPSM	Directory-discovered printers, driver distribution, status and notification.
iPrint	IPP-based print services and web installation	Browser/client printer installation and IP transport; mature in 6.x/OES.

Inventory printer agents, gateways, drivers, queues, ports, DNS names, and application dependencies before migration.
A user can authenticate and map drives successfully while printing fails through an independent Broker/Manager/gateway path.
Legacy printer drivers are executable code. Preserve them for recovery but do not deploy them to unsupported modern clients without containment and testing.

Service	Typical role	Migration/containment note
DNS/DHCP	Directory-integrated network services	Export zones, subnets, options, and service-object dependencies.
NetStorage	Web access to NCP/CIFS-backed files	Isolate old web/TLS; login-script support is partial.
iFolder	User file synchronization	Inventory clients, stores, policies, and conflict behavior.
Apache/Tomcat/MySQL/PHP	Web/application platform on 6.5	Version-specific security/consistency; migrate rather than expose.
GroupWise	Messaging and collaboration	Use product-specific domain, post-office, and agent migration.
Btrieve/Pervasive	Transactional database engine	Coordinate shutdown, logs, locks, and version compatibility.
Cluster Services	Failover for volumes and services	Preserve virtual NCP identity, scripts, preferred nodes, and shared storage.
SMS backup	TSA/SMDR/SBCON backup framework	Record agent, media, catalog, encryption, and restore dependencies.

Containment, preservation, and migration Back to contents

Minimum containment pattern Back to contents

Place NetWare and any dependent legacy clients on a dedicated VLAN or virtual switch with no direct Internet route.
Default-deny at the firewall. Permit NCP, SLP, DNS, NTP, backup, directory, print, and application flows only between documented endpoints.
Use a hardened jump host with the compatible Novell Client and management tools. Reach the jump host through modern MFA and encrypted remote access.
Send logs and monitoring outward through a controlled relay or poll from a collector; do not install untested modern agents into the NetWare kernel.
Keep offline, immutable copies of installation media, patches, drivers, configuration, license artifacts, system images, and data backups.
Set an explicit retirement date and risk owner. Containment reduces exposure; it does not make unsupported code supportable.

Migration sequence Back to contents

Staged migration

Stage	Activities	Exit criterion
Discover	Inventory services, directory roles, applications, volumes, trustees, clients, print, protocols, and dependencies	Authoritative dependency and data map approved
Stabilize	Patch to the approved terminal level, fix time/replication/storage errors, test backup and restore	Healthy, repeatable source baseline
Design	Select supported OES/Enterprise Server, Windows/Linux, SaaS, or application-specific destinations; map identity and rights	Target architecture and rollback signed off
Pilot	Migrate representative users/data/printers/apps with metadata-aware tools	Functional, security, performance, and recovery tests pass
Coexist	Introduce target services, NCP/CIFS/client changes, DNS/SLP updates, and staged data synchronization	Users operate on target with measured exceptions
Cut over	Quiesce source, final sync, redirect mappings/services, validate rights and applications	Business acceptance and rollback decision closed
Retire	Remove applications, replicas, service objects, licenses, routes, and storage in supported order	No hidden dependency; evidence and retention complete

METADATA-AWARE COPY: Use the supported migration/consolidation tool or an NSS/NCP-aware process when trustee assignments, IRFs, ownership, namespaces, Macintosh metadata, quotas, or application attributes matter. Generic drag-and-drop or SMB copies are not equivalent. [S12, S15]

Virtualization and historical preservation Back to contents

NetWare 6.5 SP8 documented VMware and Xen guest deployments, but compatibility depends on virtual CPU, storage, network adapter, and driver choices. [S1]
Preserve the original disk images before converting formats. Work on a verified copy and record hashes before and after transformation.
Keep the virtual NIC disconnected during the first boot of a clone to prevent duplicate server names, internal network numbers, tree identities, or replica activity.
Match old virtual hardware where possible. A newer hypervisor’s default controller or NIC may have no NetWare driver.
Capture console video/screens, configuration, volumes, application behavior, and client workflow as part of preservation, not only a bootable VM.
If the goal is evidence or data extraction rather than continued service, prefer an offline, read-only recovery workflow over production resurrection.

Appendix A – Common paths and files Back to contents

Locations commonly encountered on NetWare 4.x-6.5

Location	Contents / use
C:\NWSERVER\SERVER.EXE	NetWare server loader/kernel image.
C:\NWSERVER\STARTUP.NCF	Pre-SYS SET parameters and platform/storage drivers.
C:\NWSERVER\BOOT$LOG.ERR	Boot messages/errors according to logging configuration.
C:\ABEND.LOG then SYS:SYSTEM\ABEND.LOG	Abend record before and after restart/copy.
SYS:SYSTEM	Core NLMs, AUTOEXEC.NCF, SHUTDOWN.NCF, utilities, application start files.
SYS:PUBLIC	Client utilities and management program files.
SYS:LOGIN	Files accessible during login and pre-authentication workflows.
SYS:ETC	Network/service configuration and logs, including SLP.CFG and CONSOLE.LOG.
SYS:ETC\CONSOLE.LOG	Default CONLOG output.
SYS:SYSTEM\DSTRACE.DBG	Directory trace output when trace-to-file is enabled.
SYS:_NETWARE	Hidden/system directory containing directory database and security data; never treat as ordinary file content.
SYS:SYSTEM\SYS$LOG.ERR	Common system error log location on many releases.
volume-root\VOL$LOG.ERR	Traditional volume error/repair log commonly found at a volume root.

VERSION VARIANCE: Paths can be redirected, clustered, or changed by products and support packs. Treat this appendix as a discovery list, then confirm with CONFIG, SEARCH, module parameters, NCF files, and the matching manual.

Appendix B – Glossary Back to contents

Glossary

Term	Definition
Abend	Abnormal end: a NetWare fault or exception that can suspend a thread, fault an address space, or stop/restart the server.
Bindery	Per-server flat database of users, groups, properties, and services used primarily by NetWare 2.x/3.x.
Bindery context	One or more eDirectory containers exposed as a flat Bindery view for legacy clients/applications.
CDM	Custom Device Module in the NetWare Peripheral Architecture storage stack.
DIB	Directory Information Base: the local NDS/eDirectory database.
Directory Map	eDirectory object that represents a path and reduces hard-coded mapping dependencies.
Distinguished name	An object’s unique hierarchical name in the eDirectory tree.
eDirectory	Later name and evolution of Novell Directory Services (NDS).
HAM	Host Adapter Module: storage adapter driver in NWPA.
IRF	Inherited Rights Filter: blocks selected rights inherited through a hierarchy.
IPX/SPX	Legacy Novell routed network and connection-oriented transport protocol suite.
NCP	NetWare Core Protocol: client/server file and network service protocol.
NCF	NetWare Command File: a server-side batch/configuration file.
NDS	Novell Directory Services: distributed directory introduced with NetWare 4.
NDPS	Novell Distributed Print Services, the directory-based successor to queue printing.
Namespace	File-name and metadata representation for DOS, LONG/Windows, Macintosh, NFS, or other clients.
NLM	NetWare Loadable Module: executable server component linked into the runtime.
NSS	Novell Storage Services: journaling file system and storage-pool/volume architecture.
NWPA	NetWare Peripheral Architecture for HAM/CDM-based storage drivers.
ODI	Open Data-Link Interface used by classic Novell client LAN/protocol stacks.
OES	Open Enterprise Server, the Linux-based successor platform for eDirectory, NCP, NSS, iPrint, and related services.
Partition	Contiguous subtree replicated as a unit in NDS/eDirectory.
PSM	Platform Support Module for processor/chipset/platform integration.
Replica	Copy of a directory partition held by a server; types include Master, Read/Write, Read-Only, and Subordinate Reference.
Replica ring	Set of servers holding replicas of the same partition.
SAP	Service Advertising Protocol used to advertise services in IPX networks.
Salvage	Recovery of files retained after deletion but before purge/reclamation.
SLP	Service Location Protocol used for IP service discovery and registration.
SMS	Storage Management Services: NetWare backup architecture using agents such as TSA and SMDR.
TFS	Traditional NetWare File System, distinct from NSS.
Trustee	User, group, or object assigned rights to a target directory, file, or directory object.
VLM	Virtual Loadable Module client architecture used by DOS NDS-aware clients.
Volume	Named NetWare file-system container such as SYS or DATA, exposed through NCP and represented by an eDirectory object in NDS-era systems.

Appendix C – Official source set Back to contents

Sources were selected from surviving Novell, Micro Focus, NetIQ, and OpenText documentation. They were accessed on 8 August 2026. Product pages and document hosts can move; retain local archival copies where licensing permits.

[S1] NW 6.5 SP8 Installation Guide. Open official source

[S2] NW 6.5 SP8 Utilities Reference. Open official source

[S3] NW 6.5 SP8 NLM Reference. Open official source

[S4] NW 6.5 SP8 Server Operating System Administration – Troubleshooting. Open official source

[S5] NW 6.5 SP8 NSS File System Administration Guide. Open official source

[S6] NW 6.5 SP8 File Systems Management Guide – attributes and trustees. Open official source

[S7] NW 6.5 SP8 Planning and Implementation Guide. Open official source

[S8] NetIQ eDirectory 8.8 SP8 Administration Guide – eDirectory Rights. Open official source

[S9] Novell Login Scripts Guide. Open official source

[S10] NDS/eDirectory Health Check Procedures – Cross Platform. Open official source

[S11] NW 6.5 SP8 Novell Remote Manager Administration Guide. Open official source

[S12] Open Enterprise Server – Coexistence and Migration of File Services. Open official source

[S13] OpenText Product Support Lifecycle. Open official source

[S14] SLP Design and Implementation Guidelines. Open official source

[S15] Novell Server Consolidation and Migration Toolkit. Open official source

EDITION NOTE: This reference deliberately avoids prescribing hardware-specific driver lines, destructive repair options, or a current migration destination without an environment inventory. Those decisions must be made against the exact server state and the current support/interoperability matrix.

Tag: NDS/eDirectory