NetWare 5.1 Upgrade Consulting Guide - ITwelzel.biz

NOVELL PARTNER CONSULTING SERVICE OFFERINGS 

NOVELL PARTNERNET CONFIDENTIAL 

® 

NetWare 5.1 Upgrade 

CONSULTANT GUIDE

Table of Contents 

NetWare 5.1 Upgrade Consulting Guide .................................................................................... 4 

Target Audience...........................................................................Error! Bookmark not defined. 

Terminology......................................................................................................................... 4 

Skill Set............................................................................................................................... 4 

Purpose ............................................................................................................................... 5 

Acknowledgements.......................................................................Error! Bookmark not defined. 

NetWare 5.1 Training Curriculum ............................................................................................ 6 

Curriculum for NetWare 5.1 .................................................................................................... 6 

Curriculum for NetWare 5 CNE ............................................................................................... 6 

Reference Material ...............................................................................................................10 

Books .............................................................................................................................10 

AppNotes ........................................................................................................................10 

NetWare Connection Articles ..............................................................................................11 

Technical Information Documents (TIDs)..............................................................................11 

NetWare 5.1 Upgrade Solution Development.............................................................................12 

Subprocess 1—Start the Project...............................................................................................13 

Task 1—Conduct Initial Engagement Meeting........................................................................14 

Task 2—Prepare Preliminary Report.....................................................................................15 

Task 3—Review and Deliver Preliminary Report ....................................................................15 

Subprocess 2—Perform a Technical Assessment and Impact Study................................................16 

Task 1—Analyze Customer’s Current Environment.................................................................16 

Task 2—Prepare Technical Assessment/Impact Study Report....................................................47 

Task 3—Review and Deliver Technical Assessment and Impact Study Report..............................47 

Subprocess 3—Develop Solution Design ..................................................................................48 

Task 1—Determine Appropriate Solution Design for the NetWare 5.1 Upgrade ............................49 

Task 2—Prepare Solution Design Report...............................................................................68 

Task 3—Review and Deliver Solution Design Report ..............................................................68 

Subprocess 4—Test Solution Design in the Lab .........................................................................69 

Task 1—Plan Prototype......................................................................................................70 

Task 2—Build Prototype ....................................................................................................71 

Task 3—Test Prototype......................................................................................................72 

Task 4—Modify and Retest Prototype as Required ..................................................................96 

Task 5—Document Solution Design .....................................................................................96 

Task 6—Review and Deliver Solution Design Report to Customer .............................................97 

Task 7—(Conditional) Negotiate Pilot WOA..........................................................................97 

Subprocess 5—Perform the Pilot .............................................................................................98 

Task 1—Identify Pilot Sites ................................................................................................98 

Task 2—Prepare Pilot Implementation Plan ...........................................................................99 

Task 3—Prepare Pilot Test Plan...........................................................................................99 

Task 4—Perform the Pilot ..................................................................................................99 

Task 5—Modify Implementation Plan (if appropriate)..............................................................99 

Task 6—Document Final Solution Design .............................................................................99 

Task 7—Create the Closing Report.......................................................................................99 

Task 8—Review and Deliver Final Solution Design and Closing Reports to Customer ...................99 

Deploying Novell Distributed Print Services (NDPS) ................................................................101 

Subprocess 1—Designing and Implementing NDPS..................................................................106 

Page 2 of 317 Novell PartnerNet Confidential 07/24/00 

Copyright © 2000 by Novell, Inc.

Task 1—NDPS Design.....................................................................................................106 

Task 2—NDPS Deployment..............................................................................................109 

Subprocess 2—Implementing Internet Printing Protocol (IPP).....................................................114 

Subprocess 3—Implementing Line Printer/Line Printer Daemon (LPR/LPD).................................117 

Subprocess 4—QMS to NDPS Migration................................................................................119 

Subprocess 5—Troubleshooting / Real World Issues.................................................................119 

Subprocess 6—Create the NDPS Report .................................................................................119 

Subprocess 7—Review and Deliver NDPS Report to Customer...................................................119 

Integrating Office 2000 with NetWare 5.1 ...............................................................................121 

Subprocess 1—How to Integrate NetWare 5.1 and Office 2000 ...................................................123 

Subprocess 2—Creating Web Folders.....................................................................................124 

Subprocess 3—Accessing Documents and Web Folders.............................................................129 

Subprocess 4—WebDAV and Home Directory (~homedir) ........................................................129 

Subprocess 5—Using NDSDAV ...........................................................................................131 

Subprocess 6—Create the WebDAV Report ............................................................................137 

Subprocess 7—Review and Deliver WebDAV Report to Customer..............................................138 

Appendix A—IPX-Dependent Applications Worksheet ............................................................139 

Appendix B—CMD Essentials ...............................................................................................140 

Appendix C—ACU Client Deployment ...................................................................................167 

Appendix D—SLP................................................................................................................181 

Appendix E—Double-Byte Compatibility Issues ......................................................................252 

Appendix F—NDS HealthCheck “Lite” ..................................................................................254 

Appendix G—NetWare 5.1 Rapid Deployment and Standardization Strategies ...........................255 

Appendix H—SAP Types ......................................................................................................266 

Appendix I—Steps for Transitioning to Pure IP.......................................................................289 

Appendix J—Lab Requirements for NetWare 5.1 Upgrade Testing............................................295 

Appendix K—What’s New (Included) in NetWare 5.1 ..............................................................297 

Appendix L—Time Sync.......................................................................................................299 

Appendix M—NetWare/IP....................................................................................................309 

Appendix N—NetWare Management Portal............................................................................310 

Appendix O—Template Preliminary Report ...........................................................................314 

Appendix P—Template Technical Assessment and Impact Study Report....................................317 



NetWare 5.1 Upgrade Consulting Guide 

This NetWare 5.1 Upgrade Consulting Guide includes: 

• NetWare 3.x to NetWare 5.1 upgrades 

• NetWare 4.x to NetWare 5.1 upgrades 

• NetWare 5.0 to NetWare 5.1 upgrades 

• NDS eDirectory (NDS 8) versus NDS 7 considerations 

• NetWare Deployment Manager 

• Designing and implementing Novell Distributed Print Services (NDPS) 

• Office 2000 Integration (WebDAV) with NetWare 5.1 

• NetWare Portal Manager 

Although a sample reports package has not been developed yet, there is sample text included throughout 

each section which can be copied into the appropriate report (as noted throughout this consultant guide). 

Additionally, some sample reports have been included in the appendices (and are also noted throughout this 

consultant guide). This consultant guide assumes four reports are deliverable to the customer: 

Terminology 

Skill Set 

• Preliminary Report 

• Technical Assessment / Impact Study Report 

• Design Report 

• Closing (Final) Report 

• Consulting Project Lead = CPL, i.e., the lead consultant for this engagement (if appropriate) 

• Lead consultant = technical lead on site with the other consultant(s) assigned to the project 

• NDS 8 is now referred to as NDS eDirectory, shipping with NetWare 5.1. 

• NetWare 3.x = NetWare 3.12 and NetWare 3.2; NetWare 3.11 and earlier is not assumed unless 

specifically referenced 

• NetWare 4.x = NetWare 4.10+; NetWare 4.02 and earlier is not assumed unless specifically 

referenced 

• NetWare 5.x = NetWare 5.0 or NetWare 5.1 

This NetWare 5.1 upgrade consultant guide assumes that you have experience with installing and 

administering NetWare 5.x and NDS. If you are not yet familiar with NetWare 5.x, you must have a solid 

understanding of NetWare 4.x and NDS in addition to having lab time with NetWare 5.x. Specifically, you 

must have a thorough understanding of: 

• NDS and NetWare 5.x 

• NDS design 

• Time synchronization design 

• Licensing (NLS) 



• NetWare 3.x, if upgrading from this operating system 

• NetWare 4.x, if upgrading from this operating system 

• IPX to IP migrations, including SLP and CMD 

The following skill sets would be very beneficial: 

Purpose 

• Standard NetWare 5 CNE Curriculum 

• Protocols 

• IPX 

• TCP/IP 

• DNS/DCHP 

• Packet Filtering 

• NDPS 

• LPR/Unix print services 

• WebDAV 

• Routing (CISCO, MPR Certification, Bay Networks, etc.) 

• Routing protocols 

• RIP/SAP 

• NLSP 

• WAN topology/technology 

• NetWare/IP 

• Project management 

This consultant guide is intended to assist you with: 

• Upgrading NetWare 3.x, 4.x, and 5.0 to NetWare 5.1 

• Designing and implementing Novell Distributed Print Services (NDPS) 

• Setting up Office 2000 Integration (via WebDAV) with NetWare 5.1 

This consultant guide not designed to “do all,” “train all” or “teach all,” nor does it replace any Novell 

product documentation. References may be given to other documents to help you understand certain 

concepts or to help you implement certain steps. 

This guide is a living document that will be refined as new knowledge and experience is obtained, and as 

underlying technology changes. In general, this guide is designed to help you be successful the first time 

with a NetWare 5.1 upgrade, designing and installing NDPS, and Office 2000 Integration with NetWare 

5.1. 



NetWare 5.1 Training Curriculum 

Curriculum for NetWare 5.1 

The following Novell Education Courses provide the fundamental knowledge of NetWare 5.x and Novell 

Directory Services required to implement the NetWare 5.1 methodology. Please check out 

http://education.novell.com for the latest courses available. 

Novell Course 529: NetWare 4.11 to NetWare 5.1 Update 

This five-day course brings participants up to date on the latest in NetWare 5.1. The course provides 

information on upgrading from NetWare 4.11 and adds a critical introduction to IP. Additional new topics 

include: 

• Building a TCP/IP network with NetWare 5.1 

• Building an Internet infrastructure with NetWare 5.1 (using the Novell Web and FTP servers as 

well as multiple other new servers) 

• Managing TCP/IP public and private key security 

• Migrating to IP from IPX 

• Managing NDS with ConsoleOne 

• Increasing network scalability with NDS eDirectory and LDAP 

• Synchronizing Time over TCP/IP (critical for multiprotocol, multiplatform environments) 

• Managing NetWare servers through a Web browser with the NetWare Management Portal 

• Optimizing the NetWare platform 

Curriculum for NetWare 5 CNE 

Novell Course 529: NetWare 4.11 to NetWare 5 Update (or courses 560 and 

570) 

This course focuses on introducing, explaining, and comparing significant changes, updates, and new 

features found in NetWare 5. The course assumes the student has prior experience with NetWare 3, 

NetWare 4, or IntranetWare. Literacy, and the ability to anticipate, design, and use the new feature set of 

NetWare 5 are central goals to the course. The course materials are designed to provide a continuous 

reference that will be useful at the student's worksite. 

Skills 

• Know the technical relevance of NetWare 5's key new features 

• Upgrade an existing NetWare network to NetWare 5 

• Use Java and ConsoleOne services on a NetWare 5 server 

• Configure and use DNS and DHCP services 



• Configure and use the Netscape FastTrack Web Server for NetWare 

• Implement and use Novell Distributed Print Services (NDPS) 

• Manage workstations using ZENworks 

• Create and manage NSS volumes on a NetWare 5 server 

Course Topics 

• Upgrading to NetWare 5 

• Using Java Console Services 

• Using DNS/DHCP Services 

• Using the Netscape FastTrack Server for NetWare 

• Implementing Novell Distributed Print Services (NDPS) 

• Managing Workstations with ZENworks 

Novell Course 560: NetWare 5 Administration 

In this course you will learn how to accomplish fundamental network management tasks on a NetWare 5 

network. 

Skills 

• NetWare 5 and role of NDS 

• How to use a workstation 

• Network access for users 

• Novell Distributed Print Services 

• Network file system 

• File system security 

• Login scripts for NDS objects 

• NDS security 

• Network applications with ZENworks 

• Workstations in an NDS environment 

• Basic network services in a multicontext environment 

• Manage and install NetWare user licenses 

Course Topics 

• Introduction to NetWare 5 and NDS 

• Using a Workstation 

• Setting Up and Managing Network Access for Users 

• Printing with Novell Distributed Print Services 

• Managing the File System 

• Managing File System Security 

• Creating and Managing Login Scripts 

• Managing NDS Security 



• Distributing and Managing Network Applications with ZENworks 

• Managing Workstation in an NDS Environment with ZENworks 

• Managing Resources in a multicontext environment 

• Installing NetWare 5 

Novell Course 570: NetWare 5 Advanced Administration 

This course provides students with the knowledge and skills they need to design, configure and administer 

a complex NetWare 5 network. Skills learned include upgrading from a NetWare 3 environment, migrating 

to NetWare Distributed Print Services, executing Java-based utilities, network backup and configuring 

NetWare 5 for remote access. 

Skills 

• Upgrade NetWare 3.1x to NetWare 5 

• Upgrade queue-based printing to NetWare Distributed Print Services 

• Perform a custom install of NetWare 5 

• Access the server from a remote console 

• Execute Java-based utilities 

• Optimize through server statistics and utilities 

• Provide appropriate TCP/IP functionality for workstations 

• Backup/restore NDS and file system information 

• Install/configure a FastTrack Web server 

• Plan NDS security 

• Configure for remote and mobile access 

Course Topics 

• Upgrading to NetWare 5 

• Server console 

• Queue-based network printing 

• Network file system 

• Optimizing the network and server 

• Backing up servers and workstations 

• DNS/DHCP services 

• Installing a Web server and an FTP server 

• Securing the NDS tree 

• Novell Directory Services 

• Server remote access and mobile clients 

• Integrating other Novell services 



Novell Course 570: NDS Design and Implementation 

This course teaches network administrators, network designers, and networking consultants the skills 

needed to create an NDS design and implementation strategy. Students will complete an NDS design 

strategy and implementation schedule using templates that they can re-use to create a design for their 

workplaces. Students will then use these strategies and schedules to complete a NetWare implementation in 

a hands-on environment. The processes taught in this course for creating a solid NetWare design have been 

proven in use with Novell Services. 

Skills 

• Identify critical factors and expectations for designing a NetWare network. 

• Document current network configurations. 

• Determine pre-optimization and clean-up strategies for implementation. 

• Determine directory tree structure and object placement. 

• Create a time synchronization strategy. 

• Determine a strategy for login scripts, groups, and security needs. 

• Create an implementation strategy. 

• Using schedules and plans, implement a NetWare network. 

Course Topics 

• Preparing for NDS design 

• Designing an NDS tree 

• Partition and replica strategy 

• Planning a time synchronization strategy 

• Planning the user environment 

• Implementing an NDS design 

Novell Course 991: Advanced NDS Tools and Diagnostics 

This course raises the level of NDS expertise among networking professionals so they can maintain and 

troubleshoot some of the most common NDS issues. Someone who takes this course should not need to call 

Novell technical support regarding an NDS issue except to report an NDS bug or to request help on issues 

requiring DSDUMP. 

Skills 

• List tasks needed to proactively maintain an NDS tree 

• Properly perform NDS operations 

• Describe NDS tools used to identify and resolve NDS issues 

• Maintain a server in an NDS environment 

• Resolve NDS issues 

Course Topics 

• Proactively maintaining NDS 



• Performing NDS operations 

• NDS tools 

• Server maintenance 

• Resolving NDS issues 

Reference Material 

Books 

AppNotes 

• NetWare 5 and TCP/IP. This is a good reference for installing and configuring Novell’s 

DNS/DHCP. 

• “DNS and BIND”, Paul Albitz & Cricket Liu (O’Reilly & Associates, Inc.). This is an excellent 

book for generic information on DNS and BIND. 

AppNotes are on-line at http://developer.novell.com. 

NetWare 5.1 

• “What’s New in NetWare 5.1: The Complete Solution for Web-Based Networking,” January 2000 

• “Rolling Out NetWare 5.1 with the NetWare Deployment Manager,” January 2000 

• “Upgrading Novell Client Software Across the Network Using ACU.EXE,” January 2000 

• “An Overview of NetWare 5.1’s Management Portal Utility,” January 2000 

NetWare 5.0 

• “Removing IPX from WAN Segments During an Upgrade to NetWare 5: A Case Study,” 

September 1999 

• “Using Novell Upgrade Wizard 3.0,” August 1999 

• “Understanding SCMD Mechanics and Processes,” August 1999 

• “More About Automating the NetWare 5 Installation with a Response File,” February 1999 

• “Automating the NetWare 5 Installation with a Response File,” December 1998 

• “Compatibility Mode Installation and Configuration,” September 1998 

• “Migrating to pure IP with NetWare 5,” September 1998 

• “Maintaining IPX Compatibility During a Migration to TCP/IP on NetWare Network,” March 

1998 

• “NetWare Over TCP/IP: Integrating NetWare Services into the TCP/IP Environment,” March 

1997 

NDPS 

• “Printing in NetWare 5 with NDPS 2.0,” September 1998 

• “An Introduction to Novell Distributed Print Services (NDPS),” April 1998 



NetWare Connection Articles 

NDPS 

• http://www.nwconnection.com/dec.99/nepsd9/index.html “NetWare Enterprise Print Services” 

• “NDPS: Good-bye, Queue World!,” NetWare Connection, Oct. 1997, pp. 6-22. You can download 

this article from http://www.nwconnection.com/past. ) 

Technical Information Documents (TIDs) 

TIDs are constantly being created and updated. Review http://support.novell.com for the latest information. 

• Understanding NetWare 5 Licensing, TID 2943750 

• Installing MLA License Certificates, TID 10013067 

• NW5 Installing MLA License Certificates, TID 2944797 

• Installing 5.0 Servers into Mixed 4.10/4.11, TID 2943193 

• NW5 OS Installation Issues, TID 2942539 

• NW5 Minimum Requirements for NetWare5 Install, TID 2941199 

• 4.x or 5.x Migration / DSMaint Procedure, TID 2934033 

• TimeSync Frequently Asked Questions, TID 2949745 

• SLP Terms and Configuration Reference, TID 2951567 

• Configuring SLP for a NetWare Client, TID 2951560 

• Configuring SLP for a NetWare Server, TID 2951564 

• Configuring a LAN/WAN Infrastructure for SLP, TID 2951566 

• Search for keyword “NetWare 5.1” to get up-to-date information. 

• Search for keyword “NDPS” to get up-to-date information. 

• Search for keyword “WebDAV” to get up-to-date information. 



NetWare 5.1 Upgrade Solution Development 

Before you begin developing a solution for a NetWare 5.1 upgrade, you should make sure that your project 

manager has completed the requirements analysis for this engagement. The requirements analysis should 

have resulted in two documents: 

• Problem analysis report 

• Feasibility study 

Get a copy of these two completed documents from the project manager before proceeding with this 

process. 

These two documents were not given to the customer; rather, this information was gathered to assist the 

project manager in defining the scope of this engagement and to assist you in the solution development 

process. 

In the solution development process, you will be performing five major subprocesses (as denoted below in 

Figure 1 as SP1-SP5). The following subsections provide further details on the specific tasks within each 

subprocess. Reports will be the output or deliverable to the customer for each subprocess below: 

P3 

Solution 

Development 

SP1 

Initiate 

Engagement 

(Project leader) 

Conduct initial 

engagement meeting 

with customer 

(Consultant) Prepare 

preliminary report 

(Consultant) Deliver 

preliminary report 

to customer 

SP2 

Perform a 

Technical 

Assessment and 

Impact Study 

Perform technical 

assessment and 

impact study 

Develop technical 

assessment and 

impact study report 

Deliver 

technical assessment 

and impact study 

report to customer 

SP3 

Develop 

Solution 

Design 

Develop and 

document detailed 

solution designs 

Develop and 

document test and 

acceptance plans 

Deliver designs and 

plans to customer 

Figure 1. Solution Development 

SP4 

Validate 

and Test 

System Design 

Instruct customer 

to assemble test 

environment 

Build prototype 

Test prototype 

Modify and retest 

prototype 

Document final 

system design 

Prepare and present 

revised designs and 

validation results 

(Conditional) 

CBM prepares and 

negotiates WOA for 

pilot implementation 

SP5 

Implement 

and Test 

Pilot Systems 

Prepare draft 

deployment plan 

Identify pilot sites 

Develop system 

implementation plans 

Implement and test 

pilot systems 

Modify and retest 

pilot systems 

Prepare and deliver 

final design and 

validation results 

Validated System 

Design and 

Deployment Plan 



Subprocess 1—Start the Project 

Either you or the lead consultant (if one has been assigned) will conduct the preliminary meeting. This 

preliminary meeting is appropriate to ensuring that the engagement starts off on the right track. 

Deliverable: Sample prelimimary report is included in Appendix O. 

Key Inputs 

Personnel 

• Lead consultant (if one has been assigned) 

• All consulting team members 

• Customer contacts 

• Your project manager (optional) 

Resources / Tools 

Data / Reports 

• Signed statement of work 

• Completed preflight checklist 

• Summary of problem analysis 

• Summary of feasibility study 

NetWare 5.1 Upgrade—Solution Development 

Subprocess 1—Start the Project 

Task Summary 

Key Outputs 

Personnel 

• Lead consultant 

Outputs / Deliverables 

• Preliminary report 



• Weekly status reports 

Customer Sign-Off 

• Project manager 


• Fax Copy to project manager 

1. Lead consultant conducts a meeting with the customer to accomplish the following: 

• Review and set customer expectations. 

• Review approach. 

• Verify that the required preflight checklist and other requested information is on hand and complete. 

• Identify the customer's interfaces and contacts. 

• Clearly identify the roles and responsibilities. 

2. Prepare preliminary report. 

3. Review and deliver preliminary report to customer. 

The statement of work and purchase order are signed, in place, and the engagement is ready to start. The 

lead consultant calls the customer to set up this first meeting and schedules at least a four-hour block of 



time in which to meet with the customer’s appropriate personnel (for example, their project manager, their 

technical engineers, and so forth). All consulting team members should be at this meeting. The lead 

consultant conducts this meeting. 

The purpose of this meeting is to: 

• Ensure that the statement of work has been properly scoped for this project; if not, discuss the 

scope with the project manager after the meeting. 

• Obtain the information needed to start preparing the technical assessment and impact study reports 

(subprocess 2) and the overall solution design (subprocess 3) that will be used to test the upgrade 

to NetWare 5.1 in the lab (subprocess 4). 

Before this meeting, you should: 

• Be familiar with the statement of work. Bring a hard copy (preferably signed) to this meeting. 

• Be familiar with the problem analysis and feasibility study output from the requirements analysis 

(process 2). This documentation is available from the project manager. Bring a hard copy of these 

documents to the meeting. 

• Be very familiar with the NetWare 5.1 Upgrade consultant guide (this document). Bring either a 

hard or soft copy to this meeting for reference. 

• Be prepared to “chalk-talk” or provide a slide show presentation on the products and solution(s) 

you suggest. 

You should ensure that the following information is available at this initial engagement meeting: 

• LAN/WAN diagrams. If this information is not available, determine when you can get it. This 

information is necessary to design and/or review NDS partitions and replicas. The LAN/WAN 

diagrams are also necessary if you are going to design an IP/CMD, an IP/MA with/without CMD, 

and/or an SLP infrastructure solution for the customer. It is important to note that if pure IP or 

IP/CMD is in use in the customer network or if the customer intends to prefer the IP protocol on 

their clients or NetWare 5.1 servers, an SLP design is a requirement. 

• TCP/IP infrastructure (DNS, DHCP). If this information is not available, determine when you can 

get it. You need to determine if the customer’s TCP/IP infrastructure is already in place or if it will 

need to be set up (assuming the customer will be implementing IP with NetWare 5.1). 

• NDS design documents. 

Task 1—Conduct Initial Engagement Meeting 

You need to cover and document the following bulleted list at this initial engagement meeting. This 

information will become part of the preliminary report: 

• Introduce the team members and their roles. 

• Introduce the customer’s team members and their roles—for example, their project manager, their 

NDS “expert,” their client “expert,” and so forth. 

• Determine what the expectations are for you (in essence you are just verifying that the statement 

of work was properly scoped). 

• Gather the following documents from the customer (from above, the ones you should have asked 

be at this meeting): 

• Completed Pre-flight Checklist (PFC) 



• LAN/WAN Diagrams 

• TCP/IP Infrastructure Diagrams (DNS, DHCP) 

• NDS Design Documents 

Note which documents are missing, who is responsible for gathering these documents, and when 

they will be available. 

• Discuss the necessary lab requirements (see Appendix J). 

• Determine critical success factors for this project. 

• Find out what additional NetWare 5.1 products need to be installed on the NetWare 5.1 servers (if 

any). For example, NDPS, NetWare Enterprise Web Server (for Office 2000/WebDAV 

Integration), DNS/DHCP. For a complete listing of products that ship with NetWare 5.1, see 

Appendix K. 

• Find out if the customer will be implementing NDS eDirectory (NDS 8) or Legacy NDS (NDS 7). 

Note: The NDS eDirectory methodology is not yet written; however, you need to determine if 

NDS eDirectory (or “legacy” NDS) will be used. 

• Find out if the customer is MLA or non-MLA. This determines the NetWare 5.1 licensing design 

scheme that will be used. Options: CLA, VLA, SLA, MLA, Red Box. 

• Determine the customer’s timeframe for upgrading to NetWare 5.1. This may help determine the 

upgrade method used (in subprocess 3). 

Task 2—Prepare Preliminary Report 

The preliminary report is based upon the findings in the initial engagement meeting. A template 

Preliminary Report is included in Appendix O. 

While writing this report, ask yourself these questions (but DO NOT cover this in the Preliminary Report): 

• Is the product or solution valid for the customer’s perceived problem? If not, was the incorrect 

Novell product or solution sold to the customer? 

• Can a customized consulting solution be developed? 

• Are there other products or solutions from Novell that might help the customer meet their business 

objectives? 

Task 3—Review and Deliver Preliminary Report 

Activity 1—Project Manager Review 

The project manager should review your preliminary report and make any recommendations or 

suggestions. 

Activity 2—Deliver Report 

Deliver the preliminary report to the customer. 



Subprocess 2—Perform a Technical Assessment and 

Impact Study 

Deliverable: A sample technical assessment and impact study report is included in Appendix P. 

Key Inputs 

Personnel 


• Consulting team members 

• Customer contacts/interfaces 




• Problem analysis 

• Feasibility study 


NetWare 5.1 Upgrade— Solution Development 

Subprocess 2—Perform a Technical Assessment and Impact Study 

Task Summary 

Key Outputs 

Personnel 



• Technical assessment and impact study report 



• Technical assessment and impact study report 

1. Perform a technical assessment and impact study of the customer's supporting environment. 

2. Prepare technical assessment and impact study report. 

3. Deliver technical assessment and impact study report to customer. 

Many customer projects have suffered limited success or even failure as a result of their not properly 

assessing the current environment prior to embarking on an upgrade. Post-upgrade problems can be 

minimized greatly by careful review of the current environment. To minimize the risk of post-upgrade 

problems, a technical assessment and impact study of the customer’s current environment to determine if it 

is capable of sustaining the upgrade to NetWare 5.1, should take place. 

Task 1—Analyze Customer’s Current Environment 

1. Compare the NetWare 5.1 prerequisites (listed under the corresponding activities below) with the 

LAN/WAN diagrams, and TCP/IP infrastructure diagrams. This task has been organized so that 

Activity 1 corresponds with PFC Table 1. 



2. Determine whether the analyzed component in each activity meets the Novell recommendations. Be 

aware that requirements can vary widely depending upon the customer’s computing environment, upon 

applications existing on the current and future servers, and upon the customer’s future requirements 

(for example, server consolidations). Some aspects of your technical assessment may need to be stress 

tested in the lab environment. 

3. Document the “deficiencies” between #1 and #2. 

Note: Some information requested in the PFC will not be analyzed here. 



Activity 1—Review Workstation Operating Systems 

Compare client workstations and operating systems from PFC table 1 with the following NetWare 5.1 

requirements: 

OS Minimum Version or 

Patch Level 

Comments 

DOS This OS is difficult to make Y2K compliant. 

Windows (16 bit) V3.1 or higher This OS is difficult to make Y2K compliant. 

Win95 Service Pack 1 or 

higher 

Recommend minimum of 16MB RAM. 

Win98 Base product Recommend minimum of 16MB RAM. 

WinNT 3.51 OS Patch 3 or higher Recommend minimum of 24MB RAM. 

WinNT 4 Service Pack 3 or 

higher 

Windows 2000 Base product 

Recommend minimum of 24MB RAM. 

MacOS Check with Prosoft Current support and development for Macintosh connectivity to 

NetWare is performed by Prosoft. Their web site is 

http://www.prosofteng.com. 

Unix NFS The recommended solution for Unix connectivity is through NFS. 

More information on NFS can be found at 

http://www.novell.com/documentation/ 

Linux 

OS/2 V2.1 or higher Additional patches may be required if using Warp 3. 



Activity 2a—Assess Client Software 

Note: Please see Appendix C “ACU Client Deployment” if the customer’s client software needs to be 

upgraded. 

Compare client software and versions from PFC table 2 with the following NetWare 5.1 requirements: 

OS Client Functionality Comments 

NDS Pure IP 

DOS/Win3.x NETx N/A N/A Discontinued. 

Must use bindery support on 

servers. 

DOS/Win3.x VLM Limited N/A Discontinued. 

Not tested with NetWare 5.1. 

ZEN2, NDPS, not supported. 

DOS/Win3.x 32-bit 

v2.71 

X Limited No support for Pure IP 

functionality; IP functionality not 

tested. 

Final release: v2.71 

Win95/Win98 MS Client N/A N/A Must use bindery support on 

server. 

Win95/Win98 MS Client Limited N/A Multi-tree support missing. 

w/NDS 

ZEN2, NDPS, not supported. 

Win95/Win98 V3.2 X X 

WinNT 3.51 V4.11b X N/A Final release: v4.11b 

WinNT 4 V4.7 X X 

Windows 2000 V4.7 X X The WinNT 4.7 client is the W2K 

client. A Client Support Pack will 

be released after the official 

release of W2K to solve any kind of 

issues encountered in between. 

MacOS Prosoft Prosoft Prosoft Check http://www.prosofteng.com 

for details. 

Unix (non-NFS) N/A 

Linux A Linux distribution from Caldera 

(NetWare for Linux) has NetWare 

Client support; the base is Red Hat 

Linux and Caldera has added its 

Network Desktop products. The 

client gives you full access to 

NetWare servers and it includes 

features such as support for NDS 

and RSA encryption. You can get 

more information and details from 

Calder’a web site at 

www.caldera.com. 

OS/2 V2.12 X N/A Final release: v2.12 

Note: If your customer has a client version that supports NetWare 5.0 (which you can determine from the 

Client Release Roadmap URL below) you will be fine as far as NetWare 5.1 functionality. 



To find the current shipping version of a particular client, try one of the following URLs: 

• 

• 

• 

http://support.novell.com – minimum patch list 

http://www.novell.com/download 

http://support.novell.com/Ftp/Updates/nw/nwclients/Date0.html 

Note: Just because a client has certain functionality does not mean that it is the most appropriate client to 

use. Novell is continually improving the clients for current operating systems. Consequently, it is a good 

idea to plan to bring the client versions up to date even if they initially appear to work with NetWare 5.1. 

The following table lists some of the common issues that arise when the current clients are not installed. 

Some options for how to address these issues are also offered. 

Possible Issues Possible Results or Impacts Options 

• Novell client software is not at 

the latest level. 

• Microsoft Client for NetWare 

Networks is being used. 

• OS/2 workstations connected 

to NetWare servers. 

• UNIX (non-NFS) workstations 

connect to NetWare servers. 

• Macintosh workstations and 

servers run AppleTalk and 

connect to NetWare servers. 

• Cannot work with pure IP. 

• Cannot take full advantage of 

NDS (multi-tree, ZEN, NDPS, 

etc.). 

• May not be able to connect to 

server (if upgrading). 

• Upgrade to latest client 

version. 

• Continue using same version 

(and sacrifice NDS and/or 

pure IP functionality). 

• Bindery support only. • Upgrade to Novell Client 

software. 

• Run NetWare 5.1 with Bindery 

Services for Microsoft client 

workstations. 

• OS/2 workstations will not 

connect to pure IP 

NetWare 5.1 servers. 

• UNIX workstations will not 

connect to pure IP 

NetWare 5.1 servers. 

• Macintosh computers cannot 

connect to the network 

(NetWare 5.1 does not include 

Mac client). 

• Macintosh computers cannot 

see the NetWare volumes 

(NetWare 5.1does not include 

Mac file system). 

Activity 2b—Assess Client Internet Browsers 

• Maintain IPX on NetWare 

servers that require OS/2 

connectivity. 

• Maintain IPX on servers that 

require UNIX connectivity. 

• Run NFS 5 on NetWare 5.1 

servers, and NFS on UNIX 

workstations. 

• Obtain current client/file 

system from Prosoft 

(www.prosofteng.com). 

• Leave AppleTalk clients 

connected to current server 

and version. 

Compare client Internet browsers and versions from PFC table 2 with the following Office 2000 

(WebDAV) Integration with NetWare 5.1 requirements: 

• Internet Explorer 5.0 running on workstations 



Note: Internet Explorer 4.0 and Netscape’s browsers have limited functionality with the 

WebDAV protocol and they do not support Web Folders. 



Activity 3—Assess NetWare Server Information 

Compare NetWare server information from PFC table 3 with the following NetWare 5.1 requirements: 

Step 1—Assess NetWare Operating System Version and Installed Support Packs 

• For an in-place upgrade to NetWare 5.1, the following requirements must be met: 

• NetWare 3.12+ with the latest support pack 


• NetWare 5.0 with the latest support pack 

• For an across-the-wire upgrade (using the Upgrade Wizard 3.0) to NetWare 5.1, the following 

requirements must be met: 

• NetWare 3.12+ with the latest support pack (Upgrade Wizard 3.0+ provides this capability) 

• NetWare 4.10+ with the latest support pack (Upgrade Wizard 3.0+ provides this capability) 

• For an accelerated upgrade: 



• NetWare 5.0 with the latest support pack 

Note: NetWare 5.0 uses an upgrade script to do the upgrade; NetWare 5.1 uses a Java client which 

executes upgrade script commands. 

See http://support.novell.com for current minimum patch listings as the above may change. 

If support packs are installed for other applications (NLMs) on this server, determine if a different support 

pack or revision level needs to be installed for the NetWare 5.1 version of the NLM. 


• Patches are not at most 

current levels. 

Step 2—Assess CLIB Patch Level 

• No guaranteed stability. 

• Cannot take advantage of 

certain functionality and 

enhancements. 

• Inability to leverage technical 

support (problem resolution). 

• Apply latest patches (this is 

recommended). 

• Do nothing (and sacrifice 

functionality). 

The latest CLIB fixes many “LOADER CANNOT FIND PUBLIC SYMBOL” error messages. It is 

generally necessary with newer versions of LAN drivers. 

Step 3—Assess DS Version 

The latest DS.NLM should be installed on all NetWare 4 and NetWare 5 servers to ensure DS 

interoperability with NetWare 5.1 and, more importantly, NetWare 5.1 products which may extend the 

schema. The latest DS may or may not be part of the latest support pack. 



Step 4—Assess Server Make (Manufacturer) and Model 

You should ensure that the server hardware is “Yes, Tested and Approved” at 

http://developer.novell.com/prodcert/ 

Step 5—Assess CPU 

Ensure the server is a server-class PC with a Pentium or higher processor; 200 MHz+ is recommended. 


• The server does not meet 

recommended CPU 

requirements. 

Step 6—Assess Server Operating System RAM 

• Cannot upgrade this particular 

server to next OS version. 

• Upgrade the CPU to 

recommended level. 

• Obtain a new server. 

• Consider consolidation of this 

server with other servers. 

• Leave the server at its current 

NetWare version. 

NetWare 5.1 requires a base minimum of 128MB, which includes RAM for the standard NetWare 

products. 


• Server does not have the 

minimum 128MB of RAM. 

Step 7—Assess Other RAM Requirements 

• Server may not run 

NetWare 5.1. 

• Cannot upgrade this particular 

server due to RAM limitations. 

• Purchase more RAM for 

selected server (if capable). 

• Consider consolidation of this 

server with another one. 

• Get a new server. 

• Leave server at the current 

NetWare version. 

In addition to the base 128MB of RAM, you must factor in RAM requirements for additional applications 

(NLMs) running on the server, additional NetWare 5.1 components, and total disk space on the server for 

proper cache allocation and plan your disk space use accordingly. DSMASTER servers and servers running 

other software (e.g., GroupWise, Java applications, etc.), may need more than the minimum of 128MB 

RAM. For example: 

• The NetWare 5.1 GUI utilities need approximately 30MB to 50MB of free memory. 

• ConsoleOne requires 50MB of free memory after all processes are loaded. 

• WebSphere Application Server for NetWare—256 MB (512 MB recommended) in addition to 

Standard NetWare products 

• Oracle8i with WebDB—128 MB (256 MB recommended) in addition to Standard NetWare 

products 




• Server does not meet RAM 

requirements for applications 

that will be running on it. 

• Server is going to be a 

dedicated DS replica server. 

Step 8—Assess CD-ROM 

The following CD-ROM requirements must be met: 

• Server may not run specific 

application. 

• May not complete NDS 

synchronization within the 

recommended 30-minute 

period. 

• Purchase more RAM for 

server. 

• Move application to another 

server. 

• Get a new server. 

• Consider consolidation with 

another server that has 

enough RAM. 

• Upgrade to at least 128 MB of 

RAM (recommended for a 

dedicated DS replica server. 

• The CD-ROM drive must be able to read ISO 9660-formatted CD-ROM disks. 

• Computers with bootable CD-ROM drives must fully support the El Torito specification. 

Options: 

• Client connection to the network to perform the installation. 

• If the server is being upgraded “across-the-wire,” a CD-ROM is not required. 

Step 9—Assess Server Video 

The NetWare 5.1 operating system requires the following: 

• A VGA monitor for ConsoleOne support (SVGA recommended). 

• A VGA monitor for the GUI install (SVGA recommended). 


• Server does not have a VGA 

monitor. 

Step 10—Assess Server Mouse 

NetWare 5.1 requires the following: 

• Mouse support for ConsoleOne 

• Mouse support for the GUI installation. 

You may use either a serial or PS/2 mouse. 

• Cannot use GUI install. 

• Cannot use ConsoleOne. 

• Use another NetWare 5.1 

installation method besides 

the GUI installation. 

• Do all NetWare management 

from a workstation. 

• Get a VGA monitor. 



Note: The Microsoft Serial Mouse has been known to cause the Netware 5.1 GUI to hang. 

Note: A separate mouse may be needed if using certain switch boxes. 


• Server does not have mouse 

capability (IRQ or port 

availability). 

• Cannot use GUI install 

efficiently. 

• Potential delay in upgrading 

this particular server to 


Step 11— NetWare 5 DOS Partition setup suggestions: 

• Free up the IRQ (reconfigure 

other device to another IRQ if 

available). 

• Obtain a mouse for this server 

(use a COM port or mouse 

port as applicable). 

After the file server is set up, check the AUTOEXEC.BAT file. It should only contain the following 

entries: 

@echo off 

C: 

CD \NWSERVER 

SERVER 

After the file server is set up, check the CONFIG.SYS file. It should only contain the following entries: 

FILES=30 

BUFFERS=30 

It is very important that LASTDRIVE=Z is removed from CONFIG.SYS if it had been used previously to 

log into a remote file server during the installation. It is also very important to remove any DOS CD-ROM 

drivers and configurations from CONFIG.SYS. 

You may want to create a DOS menu using DR DOS that will do such things as: 

• Boot with DOS CD-ROM support 

• Launch the DOS 32-bit Client 

• Wait 10 seconds and launch NetWare 



Listed below is the syntax for DR DOS menus: 

CONFIG.SYS AUTOEXEC.BAT 

TIMEOUT = 10 

Echo = 1) NetWare Server 

Echo = 2) Plain DOS 

Echo = 3) DOS Workstation Client 

Echo = 4) DOS Workstation CD 

Echo = Please select option 1, 2, 3, or 

4? 

Switch NWSERVER, DOS, CLIENT, CD 

Exit 

:NWSERVER 

set config=NWSERVER 

Files=30 

Buffers=30 

Return 

:DOS 

Set config=DOS 

Files=30 

Buffers=30 

Return 

:CLIENT 

set config=CLIENT 

Files=50 

Buffers=30 

Return 

:CD 

set config=CD 

Files=50 

Buffers=30 

Device=C:\CDROM\CDROM.SYS /D:MSCD0001 

Return 

@echo off 

prompt $p$g 

goto %config% 

goto end 

:NWSERVER 

CD\NWSERVER 

SERVER 

Goto end 

:CLIENT 

CD\NOVELL\CLIENT32 

STARTNET 

Goto end 

:CD 

C:\DOS\MSCDEX /D:MSCD0001 /L:D 


Copyright © 2000 by Novell, Inc. 

:DOS 

:END

Activity 4—Assess Server Network Interface Cards 

Step 1—Assess Server LAN Adapters (ODI Spec) 

LAN drivers must be written to the ODI 3.30 or ODI 3.31 HSM assembler specification or 1.1 HSM C 

specification. 

With the implementation of the Virtual Memory feature in NetWare 5.0, LAN drivers that assume that 

logical addresses are equal to physical addresses can cause intermittent data corruption. This problem is 

most likely to manifest itself in DMA adapters certified before 11/1/97. We recommend that you run 

certified NetWare 5.1 LAN drivers delivered with the software. 

Essentially, the same drivers that work with NetWare 4.11+ SP6 will work with NetWare 5.1. You need to 

ensure that any NetWare 3 LAN drivers are compliant with NetWare 5.1. Sometimes, the 3.30 specification 

does not work properly with NetWare 5.1; in these cases, see if there is a 3.31/1.11 LAN driver available. 

The latest operating system (support pack) and CLIB patches must be applied before the latest LAN drivers 

can be deployed. 


• LAN Driver is not capable of 

ODI spec 3.30. 

• Can’t upgrade to NetWare 5.1. 

• Could cause corrupted 

packets as other servers get 

upgraded. 

• Project delays. 

Step 2—Assess Server LAN Adapter (Address Setting) 

Network interface cards should not be set at memory address A000. 

• Upgrade LAN driver for NIC to 

appropriate ODI specification. 

• Replace network interface 

card. 


• Server NIC address set to 

A000. 

• This address will conflict with 

NetWare 5.1’s graphical 

interface. 

• Cannot upgrade this server to 


Step 3—Assess Server LAN Adapter (Frame Types) 

All servers must be running the same frame format to communicate. 

• Modify NIC settings. 

• Replace NIC. 

• Do not upgrade this server to 



• NIC is running 802.3 (potential 

issue with older Cisco IOS 

versions). 

Step 4—Assess NetWare TCP/IP Stack 

An IP stack is needed in the following situations: 

• Cisco IOS version could cause 

NDS corruption. 

• Standardize on 802.2. 

• Upgrade Cisco IOS. 



• To get to a pure IP environment. 

• To use the accelerated upgrade. 


• No IP stack. • Cannot use accelerated 

upgrade. 

• Cannot get to pure IP. 

• Implement IP stack on 

servers. 

• Do without IP. 



Activity 5—Assess Drive Array Controllers 

Step 1—Assess Server Disk Drivers 

The following disk driver requirements must be met: 

• The latest HAM and CDM drivers must be used with NetWare 5.1. NetWare 5.1 will not run with 

DSK drivers. 

• The drive type (especially SCSI) must be supported with NetWare 5.1. 

• A good place to check for compatibility is the following “Yes Testeded and Approved” web site: 

http://developer.novell.com/prodcert/ 


• HAM and CDM drivers are not 

available for the hard drive or 

array controllers. 

• Cannot upgrade to 


• Update controllers. 



Activity 6—Assess Server Volume Structure 

Step 1—Assess Server Volumes (Free Space) 

• Novell recommends at least 2 GB of free space on SYS to allow for future implementation of 

NDS-enabled applications such as ZENworks, NDS for NT, NDS eDirectory, and so forth. 

• Non-SYS volumes should have as much additional disk space as possible for file and application 

storage. 

• Required available disk space on SYS: 

• Standard NetWare products—750 MB 

• Standard NetWare products and WebSphere Application Server for NetWare—1.3 GB 


• SYS volume does not have at 

least 750 MB of free space. 

• NDS relies on the SYS volume 

for storage of the NDS 

database. Limited capacity will 

restrict NDS. 

• Backup SYS and other 

volumes. Reallocate more 

space to the SYS volume. 

• Purchase an additional hard 

disk to support the SYS 

volume. 

Step 2—Assess Server Volumes (Block Size) 

• Recommended for non-NSS (“legacy”) volumes: 

• 64K block size with suballocation enabled 

• SYS must be legacy file system 

• Compression is a useful option on legacy volumes but must be used wisely; consider the 

following: 

• Databases (Oracle, etc.) – Don’t use compression = bad thing. 

• Web Servers -- Files not around long enough to be compressed. 

• GroupWise – It’s a database, no need for disk quota or compression - done in 

GroupWise. 

• Recommended for NSS volumes: 

• 4K block size only (not configurable) 

• No file compression; no suballocation 

• SYS cannot be NSS 




• Volumes are at less than 64 

KB block size, and 

suballocation is, or will be, 

enabled. (A 64 KB block size 

is not an issue if the volume 

will support NSS.) 

Step 3—Assess DOS Partition Size 

• File system is not performing 

at enhanced level. 

• Backup volume, delete 

volume, recreate volume, and 

restore volume. 

• Do nothing. 

• Back up the volume and use 

Consulting Services 

RESIZE.NLM. 

DOS partitions are necessary for the initial loading of the NetWare 5.1 operating system. Drivers are also 

loaded here. It is important to verify that enough space exists on both the SYS volume and the DOS 

partition to facilitate the upgrade. Without the necessary available space, copying files to these areas will be 

limited, and an upgrade will be incomplete. 

An in-place upgrade requires a 50MB DOS partition with 35 MB of free space. Recommended total DOS 

space in the past has been 1 GB to accommodate a core dump to be saved to the DOS partition (although 

this depends upon the amount of RAM installed in the server). Now, however, there is a tool to core dump 

to another machine (DBNET5.NLM in NetWare 5 Support Pack 3), so 1 GB may be excessive. In these 

cases, our recommendation is 50 MB (with 35 MB free) plus total amount of RAM in the server (for core 

dumps).. This is also our recommendation for new server hardware. 


• DOS partition has less than 35 

MB of free space. 

Step 4—Assess Additional Name Space Modules 

• Unable to perform an in-place 

upgrade. 

• Run out of space during inplace 

upgrade and cause 

problems. 

• Recovery of a failed in-place 

upgrade is very difficult. 

• Leverage Partition 

Magic/Server Magic (TID 

2926225). 

• Get a new server (across-thewire 

upgrade). 

Long name space allows long file names and additional file attributes to be stored on a NetWare 5.1 

volume. The long space NLMs are somewhat specific to the file system desired. The following NLMs are 

available: 

• LONG.NAM (extending the 8.3 naming convention for PC machines and 32-bit desktop operating 

systems). 

Note: For NetWare 3, ensure that there are less than 1 million directory entry tables (DETs) on the server 

before loading LONG.NAM. 

• NFS.NAM (UNIX file system support) 

• MAC.NAM (support for the Macintosh file system to include resource forks) 




• No additional name space 

modules are loaded. 

• Cannot use GroupWise 

WebAccess. 

• Cannot use accelerated 

upgrade. 

• No long filename support. 

Step 5—Assess Unnecessary Name Space Modules 

• Load appropriate name space 

modules. 

• Live without name space. 

Name space modules should only be loaded for the required file system support. As an example, if NFS 

support is not needed, then the name space modules should be removed since the directory entry table 

(DET) contains an entry for each file for each name space which in turn increases the server’s memory 

requirements. 


• Unnecessary name space 

modules are loaded. 

• DET is larger than necessary. 

• Slower volume mounts. 

• Increased RAM requirements. 

• Unload unnecessary name 

space modules and remove 

name space with VREPAIR. 

• Live with unnecessary name 

space. 



Activity 7—Assess Router Configuration and SAP Usage 


• SAP is being filtered. • NDS cannot synchronize. 

• Time cannot synchronize. 

• RCONSOLE cannot function. 

• Disable SAP filtering. 

• Do not filter SAP types: 

• 0x004 (file server). 

• 0x278 (directory services). 

• Depending upon time sync 

scheme, do not filter 0x26B 

(time sync). 

• Consider how remote 

management of servers will be 

handled and, if appropriate, do 

not filter 0x107 (Rconsole). 

Service advertising protocols are used by IPX-based devices and/or services to advertise themselves as 

available for use. Due to the nature of SAP (which can be “chatty”), most routers have been configured to 

filter (or not forward) specific SAP types. In an NDS environment that has IPX requirements, it is 

necessary to verify that the required SAPs are available. (See Appendix H for a list of SAP types.) 



Activity 8—Assess NT Server Information 

• Might be an opportunity to sell NDS for NT 



Activity 9—Assess Non-NetWare Server Operating System Platforms 

• Might be an opportunity to sell the appropriate “NDS for xxx” product. 



Activity 10—Assess Server Applications (NLMs) 

Analysis Possible Results or Impacts Options 

• Third-party or other NLMs are 

not NetWare 5.1 certified. 

• Server abends and/or other 

difficulties. 

• Server upgrade delays. 

• Update to a certified version. 

• Find an alternate solution. 

• Isolate the NLM. 

Most servers run additional applications. These programs must be NetWare 5.1 compatible and should 

ideally be IP-enabled. Without the appropriate upgrade path or availability of an upgraded version, 

compatibility mode will need to be enabled for the segments of servers that host these applications. 

NetWare 5.1 and IP certification can be obtained from Novell Labs. Visithttp://developer.novell.com/prodcert/ 



Activity 11—Assess NDS Partition Replica Matrix 

• Take note of the server that holds the replicas of [Root], especially the Master. 

• Use this table to determine if a NDS redesign is necessary. 



Activity 12—Assess WAN Architecture 

Multicast is a type of broadcast for the IP protocol. Without multicast, browsing capabilities are not 

available. Based upon customer requirements, multicast can be utilized or a valid SLP infrastructure design 

can be utilized for optimal performance. SLP directory agents should be utilized for all but very small 

environments for performance and scalability reasons. SLP directory agents can still make use of multicast 

if it is available. 


• Slow/congested WAN links • Poor time sync 

• Poor NDS sync 

• Won’t accept additional traffic 

• Application/connection 

timeouts 

• Inadequate resources on 

routers to handle SAP 

increases 

• Lack of reliability/fault 

tolerance 

• Router failures 

• RIP/SAP corruption 

• Multicast is turned off on WAN • You must manually design an 

SLP infrastructure deployment 

plan. 

• Enable compression 

• Upgrade link speed 

• Design solutions around the 

links 

• Add memory/resources to 

existing hardware 

• Upgrade hardware/firmware 

• Service interruptions • Encourage fault tolerance 

• Limit service dependencies on 

WAN links 

• Provide fail-over mechanism 

for service dependencies 

• Design SLP appropriately 

• Turn on multicast on the WAN 

(not recommended) 



Activity 13—Assess TCP/IP Infrastructure 

Using the customer’s documentation, assess their TCP/IP infrastructure. 


• Misconfigured TCP/IP 

infrastructure. For example, 

incorrect default gateways, 

incorrect subnet masks, or 

duplicate addressing 

schemes. 

• Non-existent TCP/IP 

infrastructure. 

• Unreliable TCP/IP 


• Lack of formal DNS 

infrastructure for name 

resolution. 

• Lack of formal DHCP 


• Deficient formal DHCP 


• TCP/IP routing protocols 

incompatible with 


• Not all clients and servers will 

be able to successfully 

communicate with other hosts. 

• No TCP/IP based networking 

possible. 

• Not all clients and servers will 

be able to successfully 

communicate with other hosts. 

• A global mechanism of name 

resolution for NetWare 5.1 

clients is not available, which 

limits name resolution options. 

• A TCP/IP-based deployment 

of NetWare 5.1 becomes more 

difficult and less fault tolerant. 

• Inability to dynamically deliver 

client configuration options. 

• Inability to dynamically deliver 

client configuration options. 

• Servers participating in the 

routing infrastructure will not 

send or receive routing 

updates. 

• Insufficient IP addresses. • Cannot upgrade all 

clients/servers to TCP/IP. 

• Reconfigure TCP/IP 


• Propose NetWare 5.1 

installation using IPX only. 

• Discuss extension of scope of 

work with client to design 

TCP/IP infrastructure. Notify 

project manager. 

• Identify points of failure and 

recommend strategy to 

address issues. 

• Design around lack of formal 

DNS infrastructure. 

• Propose formal DNS 

infrastructure for name 

resolution. 

• Propose formal DHCP 

infrastructure preferably using 

NetWare 5.1 DHCP. 

• Static configuration of TCP/IP 

environment. 

• Determine if current DHCP 

environment is extensible to 

support DHCP options. –or- 

• Propose formal DHCP 

infrastructure based upon 

NetWare 5.1 DHCP. –or- 

• Augment existing DHCP 

environment with NetWare 5.1 

DHCP delivering only SLP and 

CMD options. 

• Required static configuration 

of TCP/IP on NetWare 5.1 

servers. 

• Create private addressing 

scheme with NAT for Internet 

access. 

• Look at TCP/IP subnetting 

strategies. 

• Acquire more public 

addresses. 



Activity 14—Assess NetWare/IP Infrastructure 

There are some issues that need to be addressed with NetWare/IP before any progress can be made in a 

NetWare 5.1 upgrade (see Appendix M). NetWare 5.1 is often viewed as a solution to migrate away from 

an existing, ailing NetWare/IP infrastructure. Document the following possible deficiencies, impacts, and 

options: 

Possible Deficiencies Possible Results or Impacts Options 

• The existing NWIP 

environment is unhealthy. 

• Exacerbating the problem you 

are trying to solve. The 

upgrade to NetWare 5.1 is 

often considered a 

solution/remedy for the NWIP 

environment. 

• The NWIP environment must 

be stabilized. –or- 

• A migration strategy needs to 

be carefully planned one 

NWIP site at a time. 

An existing NetWare/IP infrastructure will impact IPX to IP migration strategies. It is critical to have an 

understanding of how the client’s current NetWare/IP infrastructure functions. Remember that DSS servers 

are pivotal to the NWIP environment and are the last servers to be decommissioned when that environment 

is dismantled. 

NWIP Functionality Deployed Results or Impacts Potential Migration Options 

• Only forwarding gateways 

deployed. 

• NWIP deployed to servers and 

clients 

• Encapsulated IPX on WAN 

links. 

• IPX on LAN wire. 

• Encapsulated IPX on LAN and 

WAN. 

• No IPX on any wire 

• Use dual-stack approach with 

existing NWIP infrastructure. 

Follow dual-stack design 

strategy. –or- 

• Replace NWIP infrastructure 

with Migration Agents in 

Backbone Support mode. 

Follow the IP/CMD migration 

strategy. 

• Create coexistent CMD 

infrastructure and convert 

NWIP servers and clients to 

CMD. Follow the IP/CMD 

migration strategy. 



Activity 15—Assess DSS Filtering 



Activity 16—Assess Printer Infrastructure 

Step 1—Determine Print Server Capabilities 

Using the data from PFC table 16, see if the print servers work with IPX, IP, or NDS. 


• Print servers do not have an 

IP stack. 

• Print servers do not work with 

NDS. 

Step 2—Determine Action Plan 

• This forces IPX to be used on 

the LAN. 

• The implementation of pure IP 

(SLP design, use of dual 

stacks, etc.) will be affected. 

• This forces NetWare 5.1 

servers to do bindery 

emulation. 

• Design SLP appropriately for 

CMD support. 

• Implement dual stacks on 

NetWare servers associated 

with the IPX print servers. 

• Upgrade print servers 

firmware or replace with newer 

technology. 

• If print servers support IP, use 

LPR/LPD or IPP. 

• Maintain bindery emulation on 

appropriate NetWare 5.1 

servers. This will require IPX 

and corresponding changes to 

SLP/pure IP design. 

There are several different ways to print from a workstation to a networked printer. The following table 

shows three of the most popular methods and relates those methods to the needed capabilities for the print 

servers. 

Print Method Print Server Supports Notes 

Legacy NetWare Printing 

through bindery print queues 

Legacy NetWare Printing 

through NDS 

• IPX • IPX support should be a given, if the print server 

is already being used in a NetWare 3.x or 

NetWare 4.x environment. 

• Adversely affects SLP/pure IP design. 

• IPX 

• NDS 

• Adversely affects SLP/pure IP design. 

LPR/LPD • IP • Any system that can submit jobs via the LPR/LPD 

standard can print directly to a NDPS 2.1.1 

printer. 

• Requires an SLP infrastructure. 

IPP • IP • Send print jobs to printers on intranets or on the 

Internet in the same way you send print jobs to a 

printer on your desk. 

NDPS 2.1.1 • IP • IP solution that provides enhanced management 

and print driver distribution capabilities. 

• Requires SLP to be configured. 



Activity 17—Print Queues 

Using the information from PFC table 17, assess the print queues. 



Activity 18—Assess SET Parameters 

Using information from the PFC (no table), assess the SET parameters. 


• Certain SET parameters are 

not at optimal setting. 

• Could cause memory 

corruption. 

• Could cause abends. 

• Performance is degraded. 

• NDS corruption occurs. 

• File system corruption occurs. 

• Inconsistent time 

synchronization occurs. 

• Restore default settings. 

• Once the server has optimally 

tuned its own settings over a 

period of time, compare the 

server’s dynamic settings to 

the Novell recommended 

settings. 

• Thoroughly analyze each SET 

parameter for the 

environment. 

Server SET parameters are a set of tuning parameters to optimize NetWare performance based on how the 

server is used. NetWare primarily tunes itself to optimal settings over a period of time. These settings are 

dynamic, in that, if not specifically “set” in the appropriate manner, the default values will be utilized upon 

server restart. 



Activity 19—Determine IPX-Dependent NLMs 

Note: You do not need to do this task if IPX will remain on NetWare 5.1 servers. 

Input: IPX-Dependent Applications Worksheet (see Appendix A). 

Output: Completed worksheet will become part of the technical assessment and impact study report. 

Network applications may be affected by network protocol changes. IPX-dependent applications, 

for example, will “break” when run on pure IP networks. The information recorded in this table 

helps to determine whether existing network applications will run over IP. 


• A particular application is IPX 

dependent. 

Step 1—Analyze Network SAP Information 

• Cannot move to a pure IP 

environment. 

• Upgrade the application to an 

IP-based version. 

• Remove the application from 

the network. 

• Provide support for the 

application through SCMD 

(compatibility mode). 

Using the information gathered, analyze the SAP types present on the network. (See Appendix H for a list 

of SAP types.) 

The SAP tables can help identify approximately 90% of the IPX-dependent applications. Utilities such as 

IPXCON.NLM and SAPMON.EXE (a consulting-developed tool) can be used. If there is no SAP for an 

application, then it is NCP-based (vs. IPX-based). With NetWare 5.1, NCP-based applications are 

redirected over IP. You will need to discuss with the customer (or work in the lab environment) to 

determine the remaining 10% of IPX-dependent applications not discovered when looking at the SAP 

tables. 

Step 2—Document IPX-Dependent Applications 

These will be the applications discovered in step 1. Fill in the first three columns of the table in Appendix 

A. 

Step 3—Determine Availability of IP Applications 

For each IPX-dependent application listed in the table in Appendix A, determine if the application is any of 

the following: 

• Mission critical (enter this in column 4 of table 1) 

• An IP version is or will be available (enter this in column 5) 

• The date the IP version will be available (enter this in column 5) 

• If the customer plans to upgrade to the IP version (enter this in column 5) 

Step 4—Plan Future of IPX-Only Applications 

Determine what to do with IPX-only applications. 



Decisions regarding whether to provide network support for IPX-dependent applications are based upon 

business and network objectives, and upon how critical these applications are to the success of the 

company. The customer must decide to either provide network support for IPX-dependent applications, or 

not provide network support (making the IPX-dependent applications obsolete in an IP-only network 

environment). 

• If the customer will support an application on IPX, enter this in column 6 of the table in Appendix 

A. 

• With this solution, you will need to continue to run CMD on the servers that house these IPXdependent 

applications. You can still have pure IP “on the wire” but CMD and a migration 

gateway will be required as long as there are IPX-dependent applications in the environment. 

Clients can be pure IP and still access this IPX-dependent application as long as a migration 

gateway is accessible to them. 

• If the customer will not support an application on IPX, enter this in column 6 of the table in 

Appendix A. 

• This solution means that the server will not run IPX and that the customer will lose the 

functionality of this NLM. This is a quick and easy way to get to pure IP. There will be no IPX or 

CMD anywhere. 



Task 2—Prepare Technical Assessment/Impact Study Report 

Note: A template technical assessment and impact study report is included in Appendix P. 

The technical assessment and impact study report is a very important document for ensuring that the 

prerequisites are addressed and met before the NetWare 5.1 upgrade pilot. The following things must be 

done to complete the report: 

• Document the issues from task 1 above. 

• Document the solutions for resolving these issues. You can use the options listed in the tables 

above, your own experience, or even note that further testing needs to be done in the lab. 

• Document the possible impacts if these issues are not resolved before the upgrade—again using 

the information in the tables above, your own experience, or even noting that further testing needs 

to be done in the lab. 

• Include the completed table from Appendix A (IPX-Dependent Applications Worksheet) as part of 

this report. 

Task 3—Review and Deliver Technical Assessment and Impact Study 

Report 


The project manager should review your technical assessment and impact study report and make any 

recommendations or suggestions. 

Activity 2—Deliver report 

Deliver technical assessment and impact study report to the customer. 



Subprocess 3—Develop Solution Design 

Key Inputs 

Personnel 







• Summary of problem analysis 

• Summary of feasibility study 

• Completed preliminary report 

• Completed technical assessment and impact study 

• Conceptual solution design 

• Critical success factors 

1. Prepare a solution design for the NetWare 5.1 upgrade. 


Subprocess 3—Develop Solution Design 

Task Summary 

Key Outputs 

Personnel 



• Test and acceptance plan 



• Design report 

2. Develop and document test and acceptance plans from success factors and customer requirements. 

3. Deliver solution design to customer. 

In this subprocess, you create a design report for the customer documenting the overall process (approach) 

that we recommend for upgrading to NetWare 5.1. 

Note: This subprocess assumes the customer is at or will be at a baseline system* before upgrading to 

NetWare 5,1; therefore, this report does not have to contain anything that should have been discussed in the 

report generated in subprocess 3. The design report should state that a baseline system is assumed. 

*A baseline system is one that has been prepared for the upgrade process. It meets the requirements set 

forth in the report from the previous subprocess. This may include hardware and software upgrades, 

consolidation of equipment, and further work prior to the upgrade process. 



Task 1—Determine Appropriate Solution Design for the NetWare 5.1 

Upgrade 

These activities need to be completed when upgrading to NetWare 5.1—and generally in the following 

recommended order. 

Activity 1—Develop and Document NDS Design 

The following flowchart illustrates the steps one should take when devising and documenting the proposed 

NDS structure: 

Start 

Does NDS 

tree exist? 

NO 

NDS design 

NDS design 

report 

Yes 

Activity 1—NDS Design or Review 

NetWare 3.x to NetWare 5.1: NDS Design 

NDS 

HealthCheck 

NDS review/ 

re-design 

For detailed information, see the NDS Design Consulting guide (not included here, available on 

http://partnerweb.novell.com ). 



The first thing that should be done for a NetWare 3.x to NetWare 5.1 upgrade is an NDS design (including 

naming standards, partitioning and replication, time synchronization, and so forth). Other activities rely 

upon an NDS design being in place, such as setting up the appropriate NAME CONTEXT statements for 

users and setting the appropriate BINDERY CONTEXT on NetWare 5.1 servers (where appropriate). 

Additionally, the lab environment (subprocess 5) should be set up to mimic the customer’s production NDS 

design. 

Deliverable: A completed NDS design document including time sync. See the NDS Design Consulting 

guide (not included here) for complete information on doing an NDS design and time sync design. For 

your convenience, a brief section on what’s new with time sync in NetWare 5.1 is included here in 

Appendix L. 

NetWare 4.x and NetWare 5.0 to NetWare 5.1: NDS Review/Re-design 

The first thing that should be done for a NetWare 4.x or NetWare 5.0 to NetWare 5.1 upgrade is an NDS 

HealthCheck. The NDS tree must be healthy prior to any upgrades or implementations to ensure success. 

See Appendix F, “NDS HealthCheck Lite” for more information. 

The next thing to be done for a NetWare 4.x or NetWare 5.0 to NetWare 5.1 upgrade is an NDS 

Review/Redesign (including naming standards, partitioning/replication, time synchronization, etc.). Other 

steps rely upon an NDS design being in place, such as setting up the appropriate NAME CONTEXT 

statement for users and setting the appropriate BINDERY CONTEXT on NetWare 5.1 servers (where 

appropriate). 

Deliverable: A completed NDS design document. For your convenience, a brief section on what’s new 

with time sync in NetWare 5.1 is included here in Appendix L. 



Activity 2—Update Novell Client Software 

Start 

Latest client? 

No 

Select client version 

ZENworks? 

No 

NAL? 

No 

Manual update 

Client design 

report 

Yes 

Yes 

Yes 

Activity 2—Update Novell Client Software 



Deliverable: 

The report should include: 

• When client software will be updated (before or after upgrading to NetWare 5.1, including the 

rationale for this decision). Sample text follows: 

We recommend installing the latest NetWare 5.1 client software on the NetWare client 

workstations before upgrading to NetWare 5.1 for the following reasons: 

• The current shipping client is tested and proven to work in a NetWare 5.1 environment. By 

upgrading the current client before proceeding with NetWare 5.1 installations, you reduce the 

number of potential support calls you receive from upset users. 

• Only the most recent clients support a pure IP environment. If you don’t upgrade the clients 

before upgrading the servers, you will increase the complexity of the SLP design. Network 

performance could be degraded until the clients are upgraded to pure IP functionality. 

• NETx forces you to maintain a bindery emulation environment on the servers. Although this 

may be an advantage for old legacy program compatibility, there are many disadvantages 

associated with continuing bindery emulation. When considering the importance of 

maintaining bindery support for old technology, there are questions to ask yourself: 

Is this legacy client software Y2K compliant? 

Chances are the answer is “no.” Chances are also likely that the replacement technology will 

work with NDS. If you want NDS support, you’ll need to upgrade the NETx clients. 

• NAME CONTEXT statements 

• Preferred server statements 

• Preferred tree statements 

• Protocol preferences 

• Client settings needing customization 

• Completed tables from Appendix C 

Using the Automatic Client Update (ACU) Utility 

See Appendix C. 

Distribution through ZENworks 

If the clients are already of a high enough version to work with the Network Application Launcher (NAL), 

then this is another method for automatically “pushing” the update to the workstations without needing user 

interaction. 

It is not in the scope for this methodology to address the details of using ZENworks. For details, check the 

ZENworks documentation or the ZENworks Consuling methodology available on 

http://partnerweb.novell.com . 



Activity 3—Analyze the Transition Path to IP 

Start 

Dual stack? 

Yes 

Design dual stack 

implementation 

strategy 

Design plan for 

migrating existing 

IPX-dependent 

applications to IP 



IPX-dependent 

devices to IP 



IPX-dependent 

routers to IP 

Dual stack design 

report 

Yes 

No 

Application 

IPX to IP 

migration 

report 

Design print 

services using 

NDPS or other 

Router IPX to IP 

migration 

report 

Design SLP 

infrastructure 

Design MA-MA 

protocol 


IP on WAN, 

limited IPX on 

LAN 

Full CMD 

implementation 

method; 

Design CMD/MA 

island 

Device IPX to IP 

migration 

report 

Activity 3—Analyze the Transition Path to IP 

SLP design report 

MA-MA protocol 

design report 

CMD/MA island 

report 



No

Note: Before proceeding with this section, we strongly recommend that you read both Appendix D, SLP 

Design and Appendix B, CMD Essentials. 

Deliverable: 


• The method the customer will use to transition to Pure IP and why this method was chosen (you 

can use the verbiage supplied in this section) 

• The steps that will be used to transition to pure IP (you can use the steps given in Appendix I) 

The ultimate goal of a migration to pure IP is to remove all IPX dependencies. This is true of all client and 

server-based applications, as well as Novell and non-Novell devices and technologies. With this goal in 

mind, you should take care to not introduce any new IPX dependencies throughout the migration process. 

Note: In the following descriptions, pure IP means no IPX anywhere on the network and, therefore, no 

capability for running IPX-dependent applications, printing services, and so forth. The assumption is that 

pure IP is the ultimate goal. When referring to other Novell documentation, keep in mind that not all Novell 

documentation defines pure IP this way. 

Determine Which Migration Strategy to Use 

Two main migration strategies are presented here: 

• Transitioning to IP Using a Dual Stack Strategy 

• Transitioning to IP Using CMD 

The intention is not to imply that these are the only options available for protocol migration. This is 

especially true when using CMD. Many hybrid solutions can be developed, depending on the customer’s 

priorities and limitations. 

• Transitioning to IP Using a Dual Stack Strategy 

Using the dual stack migration strategy is the upgrade method recommended by Novell because 

there is no need to set up and maintain a CMD infrastructure, which significantly increases the 

time, complexity, and planning required to migrate to pure IP. At first it may seem that using 

CMD will allow you to achieve the goal of pure IP more quickly than using the dual stack 

approach; however, this is not necessarily true. Using a dual stack approach provides a “seamless” 

migration that provides the simplest way to transition to a pure IP environment. This approach 

allows the use of the IPX protocol to simply and automatically fade away. 

The dual stack migration strategy provides a simple strategy that leverages an existing IPX 

infrastructure to migrate to pure IP. As a result it also has the least impact on the existing 

enterprise and IT resources. Servers and clients can be upgraded in no special order since each 

server/client that is upgraded has both IP and IPX communication capabilities to NetWare 5.1 

servers. 

See Appendix I for specific steps on implementing this strategy. 

The dual stack migration strategy has the following advantages and disadvantages: 

Dual Stack Approach 

Advantages Disadvantages 



Not using CMD avoids the following issues: 

• Planning and implementation of a CMD 

environment. 

• Training time and costs associated with 

implementing a CMD environment 

• Possible increased server hardware 

requirement to support a CMD 


• NDS and SLP considerations for CMD 

• Servers and clients can be upgraded in a 

less controlled way without impacting the 

enterprise. 

• Servers and workstations do not have to be 

upgraded at the same time or in a specific 

order if a NetWare 5.1 supported client is 

being used. 

• IPX-dependent applications can continue to 

run without problems. As IPX 

dependencies are eliminated, the system 

can evolve into a pure IP environment. 

• Leverages a mature, stable, and well 

known IPX infrastructure. 

• There is a reduced risk of service 

interruption because the wire will carry both 

the IP and IPX protocols. 

Note: Both servers and clients will, by 

default, “prefer” to use IP for all NCP-based 

communications. 

• You must continue to manage two 

protocols on the network until migration is 

complete. 

• The advantages of a single protocol are 

realized only as quickly as IPX 

dependencies can be removed. 

• At least some IPX broadcast traffic will 

continue to exist in the network until the 

migration is complete and IPX is unbound 

from servers and routers. 

• Transitioning to IP Using CMD 

The SCMD NLM is a multi-faceted solution to protocol migration. IP with CMD (IP/CMD) 

means that IPX is off the wire, but servers and clients maintain CMD for IPX-dependent 

applications. Novell strongly recommends that if CMD must be used it should be eliminated from 

the environment as soon as possible. It is important to keep in mind that CMD is not a solution but 

a migration mechanism only. This technology has the potential to place severe overhead on SLP 

and NDS and should be used only as an intermediary step between IPX and pure IP networking. 

Removal of CMD will require the elimination of all IPX dependent applications. 

There are two options presented for performing the transition: 



1. Pure IP via the MA to MA Protocol of CMD 

Migrate the backbone (WAN) to IP first, using the MA to MA protocol feature of CMD; 

then migrate to pure IP on the LAN segments using dual stacks. 

One of the most compelling reasons to move to pure IP is to prevent IPX SAP/RIP from 

traversing WAN links. This method concentrates on removing all native IPX packets 

from the WAN as quickly as possible. The MA to MA protocol feature of CMD is used 

to encapsulate IPX packets into IP packets between each MA in a given CMD network. 

This will effectively replace the existing IPX routing infrastructure between sites. 

Once this new “MA backbone” is in place, IPX is eliminated from the WAN “wire,” and 

now the LAN segments can be migrated at a more leisurely pace (if desired). Each LAN 

will use IP and IPX (dual stacks); once the IPX dependencies are eliminated, IPX can be 

removed from the LAN. 


The Pure IP via the MA to MA Protocol of CMD strategy has the following advantages and disadvantages: 


• Accommodates IPX dependencies without 

the need for IPX traffic across WAN links. 

• Addresses the major consequences of IPX 

SAP/RIP more quickly than dual stacks – at 

least on the WAN. 

• Provides more time to replace or eliminate 

IPX dependencies. 

• This option addresses the administrative 

costs of maintaining IPX over the WAN at 

the start of the transition instead of the end. 

• IPX communication will still exist but will be 

hidden by the MA to MA protocol. 

• Requires a comprehensive understanding of 

the existing IPX environment. 

• Depending on the environment, server 

hardware requirements may be significant. 

• High Design Complexity. Disperse network 

environments will require a very complex MA 

to MA design in order to avoid bandwidth 

consumption equal to that of SAP/RIP levels. 

• Higher Risk—If implementation mistakes are 

made they can result in network-wide 

outages. 

• As with any CMD-based solution, it is 

temporary. 

• IPX will be used at the LAN level until all IPX 

dependencies can be removed. 



2. Full CMD Implementation Method (using IP/CMD “islands” and the MA to MA 

Protocol). 

This method uses both the MA to MA feature of CMD as well and the IP/CMD aspect on 

all servers and clients in an attempt to remove all IPX on the wire. The MA provides the 

IPX connectivity to and from the rest of the NDS servers (and other IPX dependent 

devices) during migration. NetWare 5.1 IP/CMD servers and clients will use the CMD 

protocol to “talk” to these legacy devices through the MA. IP/CMD clients can use IPX 

dependent applications on NetWare 5.1 servers via the CMD protocol without the use of 

an MA. 

Complete removal of IPX on the LAN and WAN will only be possible if all NetWare 

servers, clients, and IPX devices support CMD or the only IPX dependencies are 

applications running on the NetWare 5.1 servers. If all IPX dependent devices cannot be 

eliminated, then at least one IPX segment must exist on the LAN segment where the MA 

resides. On that segment must reside all the IPX dependent devices at the site. Note that 

any NetWare 3.x or 4.x server is an IPX dependent device. Now any communication to 

such a device must communicate through the MA. 

A full IP/CMD migration plan is most useful when the only IPX dependencies are 

applications running on NetWare 5.1 servers. IPX dependency analysis is crucial when 

evaluating this approach. 

CMD is a temporary technology to allow backward compatibility to IPX-dependent 

applications. A CMD implementation will require a significant amount of planning and 

training, all to support a temporary solution. Since most IT staffs are not familiar with 

CMD, a steep learning curve introduces a risk factor that also must be considered. 

CMD implementations can also put a considerable burden on NDS and SLP. 


The Full CMD Implementation Method (using IP/CMD “islands” and the MA to MA Protocol) strategy has 

the following advantages and disadvantages: 

Advantages Disadvantage 

• Can accommodate IPX dependencies 

without the need for IPX traffic across WAN 

links. 

• May address the major consequences of 

IPX SAP/RIP more quickly than dual stack. 

• May remove IPX protocol from the LAN most 

quickly. 

• This option allows the network administrator 

to focus IPX traffic removal efforts on 

specific sites/network LAN segments first. 

• IPX communication will still exist but will be 

hidden by CMD and the MA to MA protocols. 

• Requires a comprehensive understanding of 

the existing IPX environment. 

• Depending on the environment, server 

hardware requirements may be significant. 

• Higher Risk -- If implementation mistakes are 

made they can result in network-wide 

outages. 

• As with any CMD based solution, it is 

temporary. 

• Requires three configurations of clients before 

pure IP is fully realized. 

• The advantages of a single protocol are 

realized only as quickly as IPX dependent 

devices can be removed. 

• High Design Complexity. Disperse network 

environments will require a very complex MA 

to MA design in order to avoid bandwidth 

consumption equal to that of SAP/RIP levels. 



Using IP with CMD primarily focuses on hiding IPX from the wire. The disadvantage is that you must set 

up and maintain a CMD environment. This significantly increases planning time, design time, migration 

time, implementation costs, and migration costs. This increased cost is further exacerbated by the fact that 

CMD technology is a temporary, “throw-away” solution that is abandoned once the migration process is 

complete and IPX dependencies are eliminated. For these reasons, Novell strongly recommends the dual 

stack migration strategy. 

Notes: 

• Ultimately the customer must decide which method to use. However, as a Novell partner, you 

should encourage them to adopt the dual stacks option, citing the various reasons given above. 

• Performing the migration to pure IP at the same time as upgrades to NetWare 5.1 will significantly 

increase the cost and complexity of both the migration and the protocol transition process. For this 

reason, we strongly recommends that the protocol transition to pure IP occur after the NetWare 5.1 

upgrade process has been successfully completed and we has determined that an IP infrastructure 

capable of supporting the transition to pure IP is in place. 

• We strongly recommends that if CMD must be used it should be eliminated from the environment 

as soon as possible. It is important to keep in mind that CMD is not a solution but a migration 

mechanism only. This technology has the potential to place severe overhead on SLP and NDS and 

should be used only as an intermediary step between IPX and pure IP networking. Removal of 

CMD will require the elimination of all IPX dependent applications. 



Activity 4—Determine Licensing Scheme 

Deliverable: 


• The licensing scheme that the customer will use and why (you can use the verbiage supplied in 

this section) 

• Each server must run NLSLSP.NLM. 

• Each server must have an NLS_LSP_servername object in NDS. 

• Each server must have one base server license, which must be unique throughout the tree. Install 

the base server license in the same container as the server. 

• If a connection license is installed in each container, servers in that container will “share” the 

connection license. In this case, you should not make any server assignments to these connection 

licenses. On the other hand, if you want a specific connection license to apply to a specific server, 

install the connection license in the same container as the server and make a server assignment to 

this connection license. 

• Each certificate must have an owner who is the only person able to manage the certificate. 

• The server object must be in the same container as, or lower, than the certificate. 

Terminology used in licensing: 

• A certificate is a license. 

• An envelope is a file with one or more certificates in it. 

• A base server license is a required license for the server (a.k.a. server base license). 

• A connection license is a required license for a user to log in to the server. 

• A license server provider is a server running NLSLSP.NLM. 

In NetWare 5.1 as with NetWare 4.x, licensing is server-centric—a user consumes a license for each server 

to which they map a drive. However, in NetWare 5.1, the license certificate is stored in NDS instead of on 

the hard drive of the server as in NetWare 4.x. Additionally, NetWare 5.1 uses a server-centric licensing 

mode, which means that the license search starts in the server context. 

Additionally, while Novell Licensing Services (NLS) is available in NetWare 4.x to track application usage 

(for example, BorderManager), NetWare 4.x does not ship with a utility to track NetWare 4 server 

licenses—as it does with NetWare 5.1. 

• The server-side NLS component is NLSLSP.NLM. 

• The client-side NLS components are LSAPI.NLM and NLSAPI.NLM. 

There are three NLS objects: 

1. NLS license server provider (LSP) represented as a leaf object named 

NLS_LSP_servername. An LSP is licensing software that is contained in the NLSLSP.NLM 

that provides the actual licensing service and maintains the license certificates. By default, 

LSP objects are created in the same container as the server running NLSLSP.NLM. Every 

NetWare 5.1 server installed must have its own NLS_LSP_servername object in order to 

determine where to look for licensing and to provide the licensing on each server. 



2. NLS product containers (2). These are NDS container-class objects that hold license 

certificates. The two NLS product containers are 

• Novell+NetWare5Server+500, which holds installed base server licenses. 

• Novell+NetWare5ConnSLC+500, which holds installed user connection 

licenses (where 500 refers to the version of NetWare, not the number of 

connections). 

These NLS product containers must be in the same container as the 

NetWare server object or in a container above the one which contains the 

NetWare server object. 

3. NLS license certificates (2): 

• Base server license, installed into Novell+NetWare5Server+500 NLS 

product container (from above). 

• User connection licenses, installed into Novell+NetWare5ConnSLC+500 

NLS product container (from above). 

The NetWare 5.1 license file comes in one of two formats: 

• Certificate envelope (*.NLF) 

An envelope is a method that enables multiple license certificates (for 

example, the base server license and the connection license) to be 

distributed as a single file. An envelope is simply an *.NLF file that 

contains one or more license certificates. 

MLA licenses are distributed as envelopes. Non-MLA licenses are 

distributed either as envelopes or as separate license certificates. 

• Connection licenses 

Base server license (*.NLS) and connection license (*.CLS) 

There are two types of license certificates: manufactured and metered. A manufactured license has an 

enforcement model provided by the manufacturer. A manufactured license certificate usually has digital 

security and is tied to a specific product. NetWare 5.1 has a manufactured license. 

When a customer purchases NetWare 5.1, they get license certificates from Novell that are required to run 

the product. End users cannot create their own NetWare 5.1 licenses because they do not have the ability to 

create one with the Novell secret digital signature. 

NetWare 5.1 allows two grace login connections without any license installed before error messages are 

displayed on the file server console. 

See the January 1999 AppNote “A Closer Look at Novell Licensing Services in NetWare 5” for more 

information on NLS. Visit - http://shop.novell.com/shopnovell/GroupDisplay.jsp?group=74840 



Activity 5—Determine Upgrade Method to Use 

Start 

First NetWare 

5 server in 

tree? 

No 

Replace 

hardware? 

No 

Start NetWare 

3.x ? 

No 

Custom 

large #s 

standardization 

No 

In-place upgrade 

Yes 

Yes 

Yes 

Yes 


of R/W replica of 

root server 

Upgrade (ATW) 

Wizard 


Accelerated 

upgrade 

Activity 5—Determine Upgrade Method to Use 



Deliverable: 


• The upgrade method(s) that the customer will use and why (you can use the verbiage supplied in 

this section) 

Note: See Appendix G “NetWare 5.1 Rapid Deployment and Standardization Strategies” for options for 

customizing NetWare 5.1 upgrades and installations. 

Prerequisites . Before installing NetWare 5.1, read the README!! Here are some things you should be 

aware of: 

• Packet Receive Buffers: IP communication uses a lot of packet receive buffers. If you use IP 

products, increase your minimum and maximum packet receive buffers. You can modify the 

packet receive buffers through Monitor or Portal. Portal is recommended. 

• Never set the Maximum Physical Receive Buffer Size value lower than the default minimum (4K). 

Several widely used LAN adapters need to have this minimum buffer size to operate. 

• Connectivity to a Shared Medium: Remove all connectivity to a shared medium, for example from 

the SAN/CLUSTER, during installation of the server or patches. You can disconnect by removing 

the FibreChannel or shared SCSI connector. 

• Before installing the server, set FILES=30 in the CONFIG.SYS file. 

• Licensing Services: You must use the supplied NetWare 5.1 licenses to run the NetWare 5.1 

server. The NetWare 5.1 Licensing Service, however, does interoperate with the NetWare 5.0 

Licensing Services. 

• You can install a NetWare 5.1 server into a NetWare 5 tree. 

• If you are installing NetWare 5.1 into a NetWare 4.x tree, run SETUPNLS.EXE from a Windows 

client. SETUPNLS.EXE will install NLS onto appropriate NetWare 4.x and 5.1 servers. 

• Installing from a Bootable CD-ROM: If your server supports bootable CD-ROM and you want to 

boot to the Operating System CD, you need to ensure that the machine boot order specifies that 

the CD boots before the hard drive. This ensures that the CD is available for booting and 

formatting the hard disk. 

• To boot to the NetWare 5.1 Operating System CD, the server must have a ROM BIOS that fully 

supports the El Torito specification---including a hard disk image. Booting on a machine where 

the specification is not supported may result in hangs after starting Caldera DR DOS or messages 

such as “No operating system found.” If your computer or storage adapter is not working, contact 

the vendor for updated BIOS. 

• Read the README!! 

NetWare 3.x and NetWare 4.x to NetWare 5.1 Methods(s) – three of them are 

documented here: 

(1) In-Place Upgrade 

Note: An in-place upgrade means that the customer will use their existing NetWare “box” for NetWare 

5.1. In this case, you must ensure that this box meets the NetWare 5.1 specifications. Refer back to 

Subprocess 2 “Perform a Technical Assessment and Impact Study.” 

In-Place Upgrade 




Retains all trustee assignments. The in-place upgrade is more “risky” in that if 

something goes wrong, the NetWare server must 

be reinstalled from backup media and the upgrade 

started again. If the upgrade needs to be completed 

overnight (and the users up and running on 

NetWare 5.1 in the morning) there may not be time 

to “recover” from any problems with this method. 

Retains passwords. Disk allocation block (DAB) size cannot be 

changed. NetWare 3.x servers will usually have a 

default DAB of 4 KB; Netware 4.x servers may have 

been set to 64 KB. If you use suballocation with 

NetWare 5.1, you should use a DAB of 64 KB. If 

appropriate, the NetWare 3.x server can be 

completely backed up, reinstalled with 64 KB, then 

restored from backup before doing an in-place 

upgrade. 

Note: The DAB is not an issue with NSS, as NSS 

will “create” a new 4 KB DAB on the NSS volumes. 

If the DOS partition does not have enough free 

space (35-50 MB is the minimum recommended), 

the in-place upgrade cannot be used. The goal is to 

have enough free DOS partition space so that the 

C:\ directory and its files can be left in 

place, for backup purposes. The DOS partition can 

be resized using Partition Magic; however, there 

must be free space available. It is not 

recommended to resize the NetWare partition to get 

this free space. 

Note: TID 2926225, “Increasing the Size of a DOS 

Partition,” discusses this issue. 

(2) NetWare 5.1 Upgrade Wizard Version 3.0 (Across-the-Wire [ATW] method) 

Note: An ATW method means that the customer has purchased a new “box” for NetWare 5.1 and the old 

data and bindery/NDS database from the old version of NetWare will be transferred over. NetWare 5.1 

gets installed on the new box first. 

NetWare 5.1 Upgrade Wizard Version 3.0 (ATW method) 


Retains all trustee assignments. Slower, because a workstation (which is the 

“bottleneck”) is involved in this upgrade process. 

How fast the file copy process goes depends on a 

number of factors, such as file size and workstation 

speed. It is not uncommon to see this file copy 

process be 40% slower that a server-to-server file 

copy. 

Retains passwords. 

If something happens during the upgrade process, 

the original NetWare server is still in place and is 

unchanged. 

Note: The source server would need DSMAINT, 

menu option “Recover Directory Services after a 

Hardware Upgrade.” It would recover the “source 

code” (backup of NDS). You would then need to 

restart the server. 



DAB can be set to 64 KB on the freshly-installed 

NetWare 5.1 server. 

DOS partition size is not an issue since it can be set 

appropriately on the freshly-installed NetWare 5.1 

server. 

(3) Manual Upgrade 

Note: The process discussed here is for NetWare 3.x to NetWare 5.1. Also, this process is generally used 

because sometimes the Upgrade Wizard does not copy over all files/trustee assignments (i.e., it “bombs 

out” during this process). 

The overall process is essentially the same as with the upgrade wizard except the NetWare 3.x bindery is 

manually “imported” into the freshly-installed NetWare 5.1 server and the copying of files is done with 

tape backup server-to-server copy (ArcServe has a server-to-server copy option which preserves trustee 

assignments). 3 GB of data an hour can be copied on a 100 MB channel between the NetWare 3.x and 

NetWare 5.1 servers. Both the NetWare 3.x and NetWare 5.1 servers should be placed on a 100 MB 

channel, if possible, to speed up the copy process. Additionally, with ArcServe, 70 MB of data per minute 

has been reported on 100 MB Ethernet on large (graphic-size) files. 

Note: Further testing needs to be done to determine if this method will support Asian double-byte 

characters. See Appendix E, Double-Byte Compatibility Issues, for more information. 

Across-the-Wire Upgrade (Manual) 


Advantage of this versus copying files with the 

Upgrade Wizard is speed (i.e., with the Upgrade 

Wizard the “bottleneck” will be the workstation that is 

involved and necessary). With the manual upgrade 

there is no such bottleneck, especially if the 

NetWare 3.x and NetWare 5.1 servers are on a 

100MB channel link. 

Retains all trustee assignments (assuming the 

backup software is capable of this). 

Retains passwords. 

If something happens during the upgrade, the 

original NetWare server is still in place and is 

unchanged. 

File copy is faster than the upgrade wizard; 

therefore, this may be the appropriate solution if the 

upgrade time window is tight. 

DAB can be set to 64 KB on the newly-installed 

NetWare 5.1 server. 

DOS partition size is not an issue since it can be set 

appropriately on the newly-installed NetWare 5.1 

server. 

No GUI-based utility; manual process. May not be 

appropriate for inexperienced installers. 

NetWare 5.0 to NetWare 5.1 Methods(s) – two of them are documented here 

Note: Before you upgrade from NetWare 5.0 to NetWare 5.1, apply the latest support pack for NetWare 

5.0. 



(1) In-Place Upgrade 

Generally speaking, a NetWare 5.0 to NetWare 5.1 upgrade will be done in place; this is simply because 

the customer probably already purchased new hardware for NetWare 5.0. Down the server, install the CD, 

and you’re on your way! 

(2) NetWare 5.1 Upgrade Wizard Version 3.0 (Across-the-Wire [ATW] method) 

Note: Same as documented above for NetWare 3.x/4.x to NetWare 5.1. 

• If you plan to install NetWare 5.1 across the wire, you must use IPX. 

Installing a NetWare 5.1 Server into a NetWare 4.11 Environment 

Before installing a NetWare 5.1 server into a NetWare 4.11 environment 

• Install NLS (Novell Licensing Services) for NetWare 5.1 on at least one NetWare 4.11 server in 

every partition of the NDS tree. You could, of course, upgrade one NetWare 4.11 server in each 

partition of the NDS tree to NetWare 5.1 which accomplishes the same result. The key is you 

want NetWare 5.1 license schema extensions in the NetWare 4.11 tree. 

1. Select a NetWare 4.11 server that has a read/write replica. 

2. Follow instructions at http:www.novell.com/documentation/lg/nw5 in NetWare 5 

Overview and Installation. 

3. (Optional) Run setupnls.nlm 

• You can install a NetWare 5.1 server directly into an NDS tree that has NetWare 4.11 servers if: 

• The NetWare 5.1 server will automatically receive a read/write replica upon insertion into the 

tree. 

• The read/write replica is in the NDS partition where the read/write activity will take place. 

Important: Only experienced network administrators should use this option. If the NDS tree already has a 

master replica and two read/write replicas, you won’t be able to use this option. This is because the fourth 

server installed into the tree does not automatically receive a read/write replica. 

• The following table shows the specific DSREPAIR versions that need to be run on existing servers 

before the first NetWare 5.1 server is installed in the tree: 

The server is running…. NetWare Version & # NDS Version DSRepair from NW5.1 CD 

4.11 NLM 4.68 Any /patches/netware/nw4x/DSREPAIR.NLM 

5.0 NLM 5.21 Pres-NDS8 /patches/netware/nw5x/DSREPAIR.NLM 

5.0 NLM 6.32 NDS 8 /patches/netware/nnds8/DSREPAIR.NLM 

5.0 NLM 7.16 NDS 8 NW 

Update 

/netware/sys/system/DSREPAIR.NLM 

Comparison of NetWare 5.0 and NetWare 5.1 Upgrade and Installation Processes 

Installing and/or upgrading to NetWare 5.0 is very similar to installing and/or upgrading to NetWare 5.1. 

Being a newer product, NetWare 5.1 does offer some differences. These differences are outlined below. 

• NetWare 5.1 comes with Deployment Manager, which is a client utility that checks (among other 

things) the state of the existing servers in the tree. 



NetWare Deployment Manager is a client-based executable file that automatically runs when the 

CD is inserted into a client workstation. This Java-based, GUI program will run and pop up with a 

dialog box of steps and comments that will assist you in preparing the NDS tree for NetWare 5.1. 

Deployment Manager updates and installs NLS code to version 5.02 ; this is critical, and this step 

cannot be missed . The Deployment Manager will not upgrade a NetWare 4.10 server or tree for 

NDS eDirectory; you must have NetWare 4.11 or higher. 

Note: Deployment Manager is hard-coded to look for a server with a R/W replica of [Root], 

which will not work, therefore, in a single-server tree or in a tree where a R/W replica of [Root] 

cannot be contacted. 

Deployment Manager will suggest that you use NDS 8 (NDS eDirectory), which is the default 

NDS version installed with NetWare 5.1. The advantages of going to NDS eDirectory are: 

• More objects per container/partition 

• Better database engine (FLAIM) 

• LDAP v3.3 now supports NDS eDirectory 

Note: NDS eDirectory is NDS 8 on Solaris, NT, NetWare; Linux should be available in the 1H00. 

NDS Corporate Edition is NDS eDirectory plus the OS integration technology commonly referred 

to as redirection. NDS Corporate Edition replaces what used to be known as NDS for NT, NDS 

for Solaris, and so on. If your customer purchases NDS Corporate Edition, they get all of the 

platforms Novell supports in one package for one price. 

• DNS Server Install. The NetWare 5.1 install routine will test to see if you have a DNS server up 

and running. It is highly recommended that a DNS server be in place before installing NetWare 

5.1, as NetWare will attempt to verify the host name. 

• NetWare 5.1 has added the feature in the “Protocols and IPX Compatibility Tab” to load the 

Migration Agent (MA) from the GUI install. You can, if you do not see this tab, install the MA 

NLM later. 

• NetWare 5.1 does not include the Unix Print Services; but, you can call Novell Technical Services 

to get this product. However, Novell recommends the use of NDPS instead. 

• The NetWare 5.1 Java install routine provides a “Components” dialog box. If a product requires a 

supporting product, the check box will automatically be checked (you will see it checked and 

greyed out meaning those options cannot be deselected). Default selected greyed checks are 

Novell Certificate Server, LDAP services, NetWare Management Portal, Storage Management 

Services, NetWare Web Manager. Along with the greyed, checked applications there are some 

“default” checked applications; they are NDPS, NetWare Enterprise Web Server, and NetWare 

FTP Server. Those options can be deselected. All others listed can be selected and installed at 

this time. If no other applications are installed at this time, they can be installed later. 

• Novell Certificate Server 2.0 (PKIS) objects. If more than one server is being installed at the same 

time, the first server to complete the installation process will host the Certificate Authority. 

Novell Certificate Server is automatically installed during the product installation. If you uncheck 

the creation of server certificates for this server, applications which rely on the existence of these 

certificates (e.g., LDAP, NetWare Portal Manager, and Web Server) will not be set up properly at 

install time and will need to be manually configured later. 

If you are installing a new tree, the server upon which the Organizational CA is created (normally 

the first server, if defaults are taken) needs to go the through the “Restart Server” process before 

other servers are added into the tree. Otherwise, a -1230 error is generated when a second or 

subsequent server attempts to create the Organizational CA object. 

The Organizational CA server must have, as a minimum, a read/write replica of the partition 

which holds the Security container. If this is not done, -601 and -603 errors may occur when 

creating server certificates. 



eDirectory (NDS 8) versus NDS 7 Considerations 

Two versions of NDS are included with NetWare 5.1: 

• NDS 7 

• NDS eDirectory (NDS 8), Novell's highly scalable, native LDAP, and cross-platform directory 

service 

The NetWare 5.1 default installation installs NDS eDirectory. Once installed, you should use 

ConsoleOne to administer NDS eDirectory. If you would prefer to use NDS 7, choose the Custom 

installation option and deselect NDS eDirectory. 

If you are using NDS version 7.33, use NetWare Administrator to administer it. The LDAP snapin required 

for version 7.33 is not installed for ConsoleOne. You also need to give trustee rights to [Public] for the 

container that you want users to browse. 

EDirectory is more scaleable, more reliable. It is the building block of Novell’s E-commerce strategy, like 

I-chain, DirXML, e-Directory, cross platform. Installing eDirectory will update the schema and a server 

holding a R/W replica. If you choose eDirectory as the database foundation (which is Novell’s 

recommendation), the entire tree has to be updated. To update the NDS tree, you must run Deployment 

Manager. 

Merging NetWare 4.1x and NetWare 5 Trees with NetWare 5 for NDS 7 

You must use the DSMERGE.NLM that ships with NetWare 5.1 when merging NetWare 5.1 trees. This 

version of DSMERGE.NLM must be loaded on the source tree on the NetWare 5.1 server that contains the 

master replica of the root partition. This means that to successfully merge, the server in the source tree that 

contains the master replica of the root partition must be NetWare 5.1. The remaining servers can be 

NetWare 4.1x or NetWare 5.0/5.1 servers. 

Merge Scenarios: 

• NetWare 5.1 installed on both target and source trees. 

To merge a NetWare 5.1 tree into another NetWare 5.1 tree, run DSMERGE on the source tree 

server that contains the master replica of the root partition. 

Note: If DSMERGE is loaded on a server that does not hold the master replica, it will report back 

the name of the correct server from which to run. 

• NetWare 4.1x installed on the target tree and NetWare 5.1 installed on the source tree. 

Run DSMERGE on the source tree on the server that contains the master replica of the root 

partition. 

• NetWare 5.1 installed on the target tree and NetWare 4.1x installed on the source tree. 

You must first upgrade to NetWare 5.1. Only the server in the 4.1x source tree that contains the 

master replica of the root partition needs to be upgraded. Then run DSMERGE on that server. 

Note: If the server holding the master cannot be upgraded, you can select another server to be the 

master, as long as it is running NetWare 5.1 at the time of the merge. 



Task 2—Prepare Solution Design Report 

In this report, document the process for upgrading to NetWare 5.1, incorporating the above information. 

The information in this report will then be set up and tested in the lab (in subprocess 5). 

It is possible that more than one upgrade method will be used for different servers, as determined in the 

relevant sections from above. 

Task 3—Review and Deliver Solution Design Report 


The project manager should review your solution design report and make any recommendations or 

suggestions. 

Activity 2—Deliver report 

Deliver solution design report to the customer. 



Subprocess 4—Test Solution Design in the Lab 

Key Inputs 

Personnel 






• Recommended solution design 

• Impact study report 

• Preflight checklist information 

• Critical success factors 


Subprocess 4—Test Solution Design in the Lab 

Task Summary 

Key Outputs 

Personnel 



• Prototype system 

• Prototype system documentation 



• Test and acceptance results report 

1. Build the prototype in the customer’s lab, using the solution design document from subprocess 3. 

2. Test the prototype solution in the customer's lab environment. 

3. Modify and retest the prototype solution as required, updating documentation as needed. 

4. Document the final solution design in a prototype test report, including test results. 

5. Review and deliver the prototype test report to the customer. 

6. (Conditional) CBM prepares and negotiates a work order agreement for pilot implementation. 

A prototype will be created and used to test the appropriate solution design(s) from subprocess 3. 

A prototype is a subset of the production environment containing representative key components. This 

prototype should mirror the production environment as closely as possible. It should be isolated from the 

corporate network to prevent intrusion or downtime on the production network. The prototype is needed to 

ensure successful pilot and implementation phases. 

The consultant will work with the customer to prepare the prototype test environment and will compile a 

prototype test proposal. The consultant and customer then test the prototype using the solution design 

recommendations, resolve any problems that may exist, and revise the test procedures—preparing for the 

subsequent pilot test. The results of the prototype test, along with any suggested design modifications, are 

then incorporated into the proposal to create a final prototype test report. 



Task 1—Plan Prototype 

Activity 1—Develop Prototype Design and Specifications 

The consultant should develop a design for the prototype test, which will be conducted in a lab. This design 

should include specifications for hardware, software, applications, network, upgrade methods, and so forth. 

A NetWare 3.x, NetWare 4.x, or NetWare 5.0 environment must include the following items to be a 

successful prototype: 

Hardware 

• The production client workstations must be duplicated in the prototype environment to 

appropriately test access to all resources. Identical hardware must be used to prevent unforeseen 

consequences. If identical hardware is not available, use similar hardware. 

• The production server hardware must be duplicated in the prototype environment so that 

applications (NLMs) can be tested appropriately. Identical hardware must be used to prevent 

unforeseen consequences. If identical hardware is not available, use similar hardware. 

Software 

• It is assumed that an approved Novell NDS tree has been designed and will be implemented as 

part of the prototype. This includes locations of replicas, time synchronization, and naming 

standards. 

• Simulate the existing NetWare production printing environment so that printing environment 

migration can be tested. You may determine from the prototype test that creating new print queues 

may be easier than migrating bindery print queues. 

• A complete installation of the current NetWare operating system and third-party NLMs running in 

the production environment must be transferred to the prototype to ensure compatibility with 

NetWare 5.1. You can use a backup/restore utility to back up existing production NetWare servers 

and to restore the backup to the customer’s existing NetWare lab server (including the bindery for 

NetWare 3.x or NDS database for NetWare 4.x/NetWare 5.0). 

• For NetWare 3.x: If you only want the bindery and not the complete file system, follow these 

steps: 

1. Execute BINDFIX.EXE twice. 

2. Copy the *.OLD files from the production to the prototype server’s 

SYS:SYSTEM directory. 

3. Execute the BINDREST.EXE utility to fully populate the bindery files 

identical to the production environment. 

• For NetWare 4.x or NetWare 5.0: You can create a tree design in the prototype that is identical 

to the production environment by using the oexport utility to export the entire tree to a *.dat file. 

You can use the oimport utility in the prototype tree to import the *.dat file from the production 

environment. Having the exact environment duplicated in the prototype will help assess any 

obstacles affecting the engagement. 

Applications 

• Test the compatibility of existing applications with users who are connected to the server with a 

connection number greater than 250. 



• A major difference between NetWare 3.x and NetWare 5.1 is the ability for NetWare 5.1 to 

support more than 250 connections (users). This is achieved by using a double-byte field (more 

than 256) for the connection number. Some older applications may not be able to handle the 

double-byte connection ID correctly. 

Network 

• The cabling system used to test the upgrade in the lab should be the same as cabling used in 

production. This enables the upgrade time to be estimated. 

• Duplicate as closely as possible the bandwidth in the production environment. This includes 

simulated WAN links, asynchronous connectivity, and any other routes of communication. The 

prototype bandwidth should be identical to that of the production network; this helps determine if 

line upgrades are needed before implementing the new version of NetWare. 

The prototype design and specifications should be included in the prototype test proposal (see activity 3 

below). 

Activity 2—Develop Prototype Test Plan 

The prototype test plan should specify how the prototype tests will be conducted, and the order in which the 

tests will be conducted—based on solution designs from subprocess 3. The consultant should document the 

sequence of events and specify and document the steps to make the prototype test successful. 

The test plan must include test criteria that verify that the implementation is complete, and that the desired 

goals have been met. Use the sample test criteria (documented below) and add additional test criteria as 

necessary. 

The test plan should be included in the prototype test proposal (see activity 3 below). 

Activity 3—Compile Prototype Test Proposal 

The prototype test proposal should include the prototype test design and specifications, and the prototype 

test plan. The proposal should contain information about required resources, information about the 

sequence of events, and information about what to measure to ensure that the prototype test was successful. 

This proposal will be the basis of the prototype system test, which will be carried out in the customer’s lab 

environment. 

After the prototype system is built (task 2) and tested (task 3), take careful notes about variances in design 

setup, test implementation methods, test results, and so forth. This information will be added to the 

prototype test proposal. The combined documents will be used to create the prototype test report that will 

be delivered to the customer (task 5). 

Task 2—Build Prototype 

Using the solution design specifications from task 1, build the prototype in the customer’s lab environment. 



Activity 1—Organize Test Teams 

Your test team should include people who have the skills and understanding necessary to thoroughly test 

the NetWare 5.1 upgrade in the prototype environment: 

• Choose team members to prepare the test hardware. 

• Organize the NetWare 5.1 software so that it is readily available with applicable patches provided. 

• Organize the application software and provide current patches. 

• Choose team members whose expertise matches the tasks to be completed during the test. 

• Assign tasks to be completed by each team member. 

• Where appropriate, assign members of the customer staff to consulting teams to incorporate 

training and knowledge transfer. 

Activity 2—Set Up Prototype Test Environment 

Set up the lab environment so that the solution design (from subprocess 3) can be tested and validated 

before the pilot (subprocess 5). 

Task 3—Test Prototype 

Activity 1—Test Procedures 

Test the procedures used to upgrade the client software. 

Note: See Appendix C. 

Activity 2—Test Steps 

Test the steps that will be used to upgrade to NetWare 5.1 using one or more of the following methods: 

• In-place upgrade (NetWare 3.x, 4.x, or 5.0 to NetWare 5.1) 

• Upgrade using Upgrade Wizard (NetWare 3.x or 4.x to NetWare 5.1) 

• Manual upgrade (NetWare 3.x or 4.x to NetWare 5.1) 

• Accelerated upgrade (NetWare 4.x to NetWare 5.1) 

• DSMAINT upgrade (NetWare 4.x to NetWare 5.1) 

In-Place Upgrade 

You can use an in-place upgrade to upgrade either a NetWare 3.x, 4.x, of 5.0 server to NetWare 5.1. 

Note: The steps (and dialog) are to be tested and verified in the lab environment. Make the necessary 

changes (as appropriate), after which the completed process can be given to the customer as part of their 

implementation plan to be used in the pilot (subprocess 5). 



Assess Server Status 

Ensure that the customer’s existing NetWare server meets the NetWare 5.1 prerequisites. Refer back to the 

technical assessment and impact study process and report. 

The following bulleted items are some of the bigger “gotchas.” The entire list of prerequisites is not 

reiterated here since those prerequisites should have been completed during the technical assessment and 

impact study phase. Do not attempt the in-place upgrade in a production environment until all NetWare 5.1 

prerequisites are met and, ideally, the in-place upgrade has been tested in a lab environment with the 

appropriate “back-out” measures defined. 

The major prerequisites include the following: 

• A minimum of 35-50 MB of free space remaining on the DOS partition to support the 

NetWare 5.1 files that will be copied there during the upgrade. Lack of sufficient DOS space is 

the number one reason for in-place upgrade failures. 

• Current NetWare 5.1 disk drivers for the existing NetWare server being upgraded, including a 

written list of driver names, interrupt settings, and so forth 

Note: NetWare 5.1 no longer supports the DSK hard disk controller files, and the upgrade will not continue 

until HAM drivers are installed. Ensure that the latest HAM files for the controller hardware are on the 

NetWare 5.1 CD; if not, download them from either http://support.novell.com or from the hardware 

manufacturer’s web site. 

• Current NetWare 5.1 LAN drivers for the existing NetWare server being upgraded, including a 

written list of driver names, interrupt settings, and so forth. 

Note: Verify that the latest LAN drivers are on the NetWare 5.1 CD; if not, download them from either 

http://support.novell.com or from the hardware manufacturer’s web site. Although some of the older 

NetWare LAN drivers will work with NetWare 5.1, you should upgrade to the NetWare 5.1 LAN drivers 

before performing the upgrade. This eliminates one troubleshooting variable to handle after the upgrade to 


For NetWare 3.x servers: The latest NetWare 5.1 LAN drivers can be loaded on NetWare 3.x servers after 

the latest support pack and CLIB are installed. The following coding should work in AUTOEXEC.NCF: 

LOAD NBI31x 

LOAD MSM31x 

LOAD ETHERTSM 

LOAD *.LAN 

Prepare NetWare 3.x Servers 

The following steps should be done the day before the actual upgrade to ensure there will be no significant 

changes to the bindery and file system: 

1. Delete old and unused bindery information such as users, groups, print servers, and print 

queues. 

2. Run SYS:SYSTEM\BINDFIX to remove obsolete MAIL directories and trustee 

assignments, and to compress the bindery files. 

3. Run BINDFIX a second time to obtain a set of “clean” bindery files. 



4. Save the files NET$VAL.OLD, NET$PROP.OLD, and NET$OBJ.OLD to a safe 

location (diskette would be appropriate). 

5. Run VREPAIR to correct any file system errors. Begin the upgrade only after VREPAIR 

completes with no errors. 

6. Create two complete backups of the “cleaned up” (after steps 2 and 3 above are done) 

NetWare 3.x server. Ensure that these backups can be restored. 

7. Print out the system login script (NET$LOG.DAT). This information is useful if you 

later need to update the container login script. 

8. Make sure the DOS-based CD-ROM drivers are installed (and working) on the 

NetWare 3.x server being upgraded. 

Completed Information Needed During the Upgrade Process 

The following items and information need to be on-hand during the upgrade: 

• NetWare 5.1 license disks 

• Latest HAM drivers (as discussed above) 

• Latest LAN drivers (as discussed above) 

• Protocols to install on the server (such as IPX, IP, IP/CMD) 

• Completed NDS design document from the PFC. This includes: 

• Where the server will be placed in the tree (tree name and context) 

• The appropriate time zone information for the server 

• The type of time server (reference, single reference, primary, secondary) 

• What replicas will be stored on the server 

• Bindery context needed for the server 

• Admin context and password (if NDS tree exists already) 

• Additional NetWare 5.1 components to install from Novell product CDs and/or third-party 

CDs. 

• Licensing scheme. 

• SLP design. 

Perform the In-Place Upgrade 

An in-place upgrade installs NetWare 5.1 directly on top of the existing NetWare operating system. On a 

NetWare 3.x server, all objects in the server’s bindery become part of the NDS container that the server 

object is placed into. On a NetWare 4.x and NetWare 5.0 server, this kind of upgrade is relatively stable 

and experiences few problems with the existing NDS tree. 

Do the following steps to perform an in-place upgrade: 

1. Log out all users from the NetWare server. 

2. Down the NetWare server and return to a DOS prompt. 

The DOS-based CD-ROM drivers must be loaded to properly detect the CD-ROM drive. 

3. Load the NetWare 5.1 installation CD; then, at the DOS prompt for the CD-ROM drive, 

type INSTALL and press Enter. 



4. Review the NetWare 5.1 license agreement that appears, then press F10 to accept it. 

Note: At any point during the upgrade, press F1 on the install screens for help. 

At this point a new screen appears asking if you are installing a new server or performing 

an upgrade. 

5. Since this is an upgrade, select Modify and change the prompt to read “Upgrade from 3.x 

or 4.x.” 

For NetWare 3.x Servers: If you have the space in the DOS partition, leave the startup 

directory as C:\NWSERVER so that your existing NetWare 3.x drivers are not 

overwritten by the upgrade. You can delete the old 3.x subdirectory after the upgrade 

completes successfully. 

6. Select Continue to proceed. 

A new screen asks you to specify the mouse and video. The mouse is necessary to use 

the NetWare 5.1 ConsoleOne graphical server console. 

7. Choose the correct port (PS/2 or COM1). 

Note: If you accidentally select the wrong mouse or video type, you can redetect either 

mode after the operating system is completely installed. 

8. Type “vesa_rsp” at the system console prompt. 

NetWare 5.1 proceeds to copy files to the DOS partition of the server. 

After the files are copied, a new page identifies the support modules and storage adapters 

installed on the server. These devices are “best guess” identifications and should be 

verified with the hardware list you compiled in preparation for this upgrade. 

9. Make needed modifications to the identified hardware, then select Continue to proceed. 

A new page presents a list of the storage devices on the server. 

10. Verify the list of storage devices for accuracy, then select Continue to proceed. 

The installation utility installs the drivers selected in the previous pages, then presents a 

list of network adapter cards in the server. 

11. Verify the list of network adapter cards for accuracy, then select Continue to proceed. 

Note: If your server uses more than one network card and both cards are of the same 

make and model, you need to load only one driver, but that driver will have to be loaded 

twice, once for each card. 

The installation utility now copies the system and Java files necessary to load the 

ConsoleOne utility. At this point, the mouse should be operational. If not, you can still 

navigate your way around the ConsoleOne screen using the arrow keys on the keyboard. 

The first page to appear lets you select the protocols that you wish to run on the network 

card. 

12. Choose IPX, IP, or both, then click Next to continue. 

If you choose IP, then you need to know the server’s IP address, subnet mask, and 

gateway address. 

A new page appears that lets you choose your time zone. 

13. Click your time zone, and click Next to continue. 

The next page to appear begins the installation of NDS. You can either install the server 

into an existing NDS tree, or you can install a new tree. 



14. Make your NDS installation selection, and click Next to continue. 

A new page appears and asks you to specify the following: 

• The NDS tree into which the server should be installed 

• The tree context where the server should reside 

• The full-distinguished name of the ADMIN login 

• The ADMIN password 

15. Enter the required information from step 14, and click Next to continue. 

For NetWare 3.x Servers: A dialog box appears requesting resolution for bindery 

objects with the same name as NDS objects. 

For NetWare 4.x and 5.0 Servers: If you are upgrading an existing NDS tree, the 

system will upgrade the server to the appropriate DS version for NetWare 5.1 and 

perform any schema extensions needed to complete the installation. 

16. Select the correct resolution, and choose OK. 

A new page displays a summary of the NDS tree that was created. 

For NetWare 4.x and 5.0 Servers: If you are upgrading an existing NDS tree, you may 

not see this summary page. 

17. Important: If you created a new NDS tree, write down the summary information, then 

click Next to continue. 

The next page installs the server license. 

18. Insert the license diskette into the floppy drive, and click Next to continue. 

A new screen appears and prompts you to choose all of the additional products that you 

would like installed on the server. 

19. Check the products you would like installed, and uncheck the products you would not 

like installed. Pay particular attention to the following products: 

LDAP 

If you choose to install LDAP, you will be asked if you would like the LDAP 

catalog maintained on this server. LDAP catalog allows faster login to the 

network since only the catalog is scanned when a user logs in, instead of the 

entire tree. 

19a. Maintain one LDAP catalog on a server in each geographical location. 

Because LDAP is maintained as part of NDS, you can maintain backups of the 

catalog by replicating NDS on other servers. If you need more information 

regarding LDAP, click Help. 

DNS/DHCP 

If you chose to install DNS/DHCP, you can specify the context in the NDS tree 

where you would like DNS/DHCP information to be maintained. 

19b. Specify the context, then click Next to continue. 

Note: You can install DNS/DHCP later if you want root object placement to be 

someplace other than the server location (files are always installed anyway). 

Use DNIPINST to extend the schema afterwards. 

20. Click Next to continue. 

At this point a summary screen will appear listing the products that you wish to install. 



21. If you wish to customize any applications, click Customize. 

For example, to load the migration gateway, click Protocols from the list, then click 

Properties. Select the IPX compatibility tab, and check Load the Migration Agent. You 

can specify the compatibility mode network number at this time. 

22. Make your changes, and click OK. 

23. Click Close to end product customization. 

24. Click Finish to continue. 

The process will proceed automatically at this point. 

Note: The file copy procedure takes about 30-45 minutes, depending on server speed. 

25. Restart your server by removing any floppy disks and CDs from the server, and then 

clicking “Yes.” 

You should review the ReadMe file. 

At this point the in-place upgrade is complete. Go to the section “Test Criteria,” and follow the manual 

upgrade instructions (found later in this document). 

Upgrade Wizard Version 3.0 

• If you are upgrading from NetWare 3.x to NetWare 5.1, follow the steps outlined in the 

NetWare 3.x to NetWare 5.1 Upgrade Wizard section. 

• If you are upgrading from NetWare 4.x to NetWare 5.1, follow the steps outlined in the 

NetWare 4.x to NetWare 5.x Upgrade Wizard section. 

• If you are upgrading from NetWare 5.0 to NetWare 5.1, the steps are not documented here because 

generally these will be performed as in-place upgrades. 

NetWare 3.x to NetWare 5.1 Upgrade Wizard 

The steps (and dialog) are to be tested and verified in the lab environment. Make the necessary changes (as 

appropriate). The completed process can be given to the customer as part of their implementation plan to be 

used in the pilot (subprocess 6). 

Set Up the Upgrade Wizard Workstation 

The Novell Upgrade Wizard is a GUI-based workstation utility that helps you copy the files and bindery 

objects from a source server running NetWare 3.x to a destination server running NetWare 5.1 with NDS. 

When copied to the destination server, bindery objects are placed in the NDS tree and automatically 

converted to NDS objects. 

Get the latest NetWare 3.x to NetWare 5.1 Upgrade Wizard from http://support.novell.com. The 

installation process is straightforward. 

The prerequisites for upgrading with Upgrade Wizard are: 

• A Windows 95/98 workstation with 25 MB of available disk space. This workstation must be 

running Novell Client for Windows 95/98 version 3.0.1.0 or later. 

-or- 

• A Windows NT (4.0 or later) workstation with 25 MB of available disk space. This workstation 

must be running Novell Client for Windows NT version 4.50.819 or later. 



• The Upgrade Wizard workstation should be the fastest PC available in your environment, since it 

must copy all of the data and convert the NetWare 3.x bindery into the NetWare 5.1 NDS 

structure. 

• The client workstation must be able to simultaneously connect to the source (NetWare 3.x) and 

destination (NetWare 5.1) servers using IPX. 

• A supervisor or supervisor-equivalent password is required for the NetWare 3.x server. An admin 

or admin-equivalent context and password is required for the NetWare 5.1 server. Additionally, 

the RCONSOLE password is needed for both the NetWare 3.x and NetWare 5.1 server. 

Install the NetWare 5.1 Server 

The NetWare 5.1 server must be installed with the latest patches and must meet the minimum NetWare 5.1 

prerequisites. To do this, complete the following steps: 

1. Use the completed NDS Design document to properly determine and set up the 

following: 


• Appropriate time zone information for the server 

• The type of time server (i.e., reference, single reference, primary, secondary) 

• Replicas to be stored on the server 

• The bindery context needed for the server 

• Admin context and password (if an NDS tree already exists) 

2. Install the appropriate NetWare 5.1 components. 

3. Set up and install the appropriate licensing scheme. 

4. Load and bind the appropriate protocols on the server (such as IPX, IP, IP/CMD, and so 

forth) as identified in the PFC. 

Note: To use the Upgrade Wizard, IPX must be bound on the NetWare 5.1 server. You 

can unbind IPX afterwards (if appropriate). 

5. Set up the appropriate SLP design from the SLP design recommendations in the 

appendicies of this document. 

6. If any volumes you are going to migrate from NetWare 3.x contain files with non-DOS 

naming conventions, you must load the appropriate name spaces on the destination 

volumes of the NetWare 5.1 server and then add the name spaces to the volume prior to 

the migration. 

• Windows 95, Windows NT, and OS/2 name spaces are loaded through 

LONG.NAM (long names). 

• The NFS name space is loaded through NFS.NAM. 

• The Macintosh name space is loaded through MAC.NAM. 

Prepare the NetWare 3.x Server 

The following steps can and should (optimally) be done the day before the actual upgrade to ensure there 

will not be significant changes to the bindery and file system: 

1. Delete old and unused bindery information such as users, groups, print servers, print 

queues. 

2. Run SYS:SYSTEM\BINDFIX to remove obsolete mail directories and trustee 




3. Run BINDFIX a second time to obtain a set of “clean” bindery files. 





6. Optional: Create two complete backups of the cleaned up NetWare 3.x server (after 

steps 1 and 2 above). Ensure that these backups can be restored. Since the NetWare 3.x 

server remains up, backups are not as crucial but are still recommended. 



Isolate NetWare 3.x Server 

Isolate the NetWare 3.x server from the rest of your network. The entire migration setup should consist of 

the source server (NetWare 3.x), the destination server (NetWare 5.1), and the Upgrade Wizard 

workstation. Place these three nodes on a fast link, for example 100 MB Ethernet. 

Update NLMs 

Upgrade Wizard workstation 

Netware 3 

source server Netware 5 

destination server 

Figure 2. Isolate the NetWare 3.x Server 

Make sure that the following NLM programs are updated to the latest versions on the NetWare 3.x server: 

• A3112.NLM 

• AFTER311.NLM 

• CLIB.NLM 

• MAC.NAM 

• SMDR.NLM 

• SPXS.NLM 

• STREAMS.NLM 

• TLI.NLM 

• TSA311.NLM 

• TSA312.NLM 



These updated files are found on the Upgrade Wizard workstation after the Upgrade Wizard is installed. 

They are located at 

C:\PROGRAM FILES\UPGRADE\PRODUCTS\NW3X 

Load TSA500 on NetWare 5.1 Server 

TSA500 is the NetWare 5.1 target service agent (TSA) used to carry out tasks for SMS-compliant backup 

engines like SBACKUP. The Upgrade Wizard uses TSA to move the data from the source server to the 

destination server. TSA500 automatically loads SMDR.NLM (the storage management data requestor), 

which passes commands between the Upgrade Wizard processes and the target service agent. To do this, 

complete the following steps: 

1. Load TSA500.NLM on the NetWare 5.1 server. 

The SMDR configuration screen immediately appears and prompts you for the SMDR 

group context. 

2. Enter the SMDR group context or press Enter to select the default. 

A new screen appears and prompts you for the SMDR context. 

3. Enter the SMDR context or press Enter to select the default. 

Next you are prompted for the fully-distinguished name of the managing user login. 

4. Use the fully-distinguished name of ADMIN, and Press Enter. 

5. Type in the ADMIN password, and Press Enter. 

The target service agent is now successfully loaded. 

Verify Communication between Servers 

Make sure each server can see the other server across the network by executing the command DISPLAY 

SERVERS at the console prompt of each server. The output of this command should reveal the name of the 

opposite server. If the servers are not able to see each other, then unbind IPX from the network cards. 

Rebind IPX making sure that the IPX external network number reference (in the NET= parameter of the 

BIND command) matches for both servers. 

Launch the Novell Upgrade Wizard 

Do the following to launch the Novell Upgrade Wizard: 

1. Click the Windows 95 or Windows NT Start menu. 

2. Choose Programs > Novell > Novell Upgrade Wizard. 

Once the utility is launched, the Startup dialog box appears, ready for you to create a new project. 

Create an Upgrade Wizard Project 

A project is a model you use to place NetWare 3.x objects in the NDS tree. A project is created and 

completed before the actual migration can take place. 

1. In the Startup dialog box, choose Create New Upgrade Project, and click OK. 

A wizard is launched. The first page of the wizard asks you for the name and location of 

the new project. 



2. Type a project name, and use the browse button to indicate the location where you want 

the project saved. Then click Next. 

A new page appears asking you to indicate the NetWare 3.x server you are migrating 

from (the source) and the NDS tree you are migrating to (the destination). 

3. Use the two drop-down list boxes to indicate the source server and destination tree. 

If the desired source server and/or destination tree are not displayed, use the server 

button or tree button to log in to a server or NDS tree. 

4. Once you have indicated the source server and NDS tree, click Next. 

A new wizard page displays information about the utility’s database. 

5. Click Create to create the upgrade project. 

6. Move objects in the project window as necessary. 

The indicated source server and destination tree are displayed in the project window 

where bindery objects and volume data from the source server can be dragged and 

dropped to desired locations in the NDS tree. A sample project window is shown below. 

Create Subordinate Objects (conditional) 

Figure 3. Sample Project Window 

Before dragging and dropping the bindery or volume data, first determine where in the destination tree you 

want each to be copied to. If the desired container (for the bindery) or folder (for the volume data) does not 

already exist in the NDS tree, right-click the “parent” (container for the bindery, folder or volume for the 

volume data). Create and name the new container or folder as shown here: 

Figure 4. Create a New Organizational Unit 



Move Objects 

Click and drag the bindery or volume objects from the source area to the desired location in the destination 

area. 

Figure 5. Sample Project Window with Dragged and Dropped Objects 

Verify Migration Readiness 

Once the bindery and volumes have been moved to the destination area, you should verify that the 

migration can proceed as indicated in the project window. The verification process checks for object 

conflicts, sufficient NDS and file system rights, disk space limitations, and a variety of other things that 

could impede the migration. To verify that the migration can proceed, complete the following steps: 

1. From the toolbar, click Verification, or choose Project > Verify. 

A new wizard is launched. The first wizard page gives an overview of how the 

verification process works. 

2. Click Next. 

A new page appears, allowing you to indicate if you would like to migrate your print 

information, and if so, to which volume. This lets you place your existing NetWare print 

queues, print servers, and printers into desired locations in the new NDS tree. 

3. Choose whether to migrate your print information. 

(3a) If you do not want to migrate the print information, remove the check from the box 

at the top of the page. 

(3b) If you want to migrate the print information, choose the desired volume in the tree 

browser, and click Next. 

A new page appears, allowing you to apply an existing NDS template object to all users 

being migrated. A template object allows you to easily establish a common set of 

properties for the new NDS users, rather than setting those properties individually. The 

properties of the template object are applied only to new user objects created after the 

migration process is completed as new users are added to the NDS tree. 



4. Decide whether to apply a template object. 

If you would like to create a template object, you can do so in the next screen. 

(4a) If you do not want to apply a template object, remove the check from the box at the 

top of the page. 

(4b) If you want to apply a template object locate, choose the desired template object (if 

one already exists), and click Next. 

A new page appears giving you the option to create a template object. You can then 

apply this template when you set up new users in the NDS tree. 

5. If you want to create a template, check the box and enter a name for the template, then 

click Next. 

A new page appears asking what you would like to do to resolve duplicate files. 

6. Make a selection, and click Next to continue. 

A new page appears, prompting you for the password to the source server and destination 

tree. 

7. Enter the passwords, and click Next. 

A new wizard page lets you indicate the type of verification to be performed. Check 

boxes let you indicate what categories are verified. 

8. Mark the appropriate boxes to indicate what you want verified, and click Next. 

After running the verification, a wizard page appears showing remaining naming 

conflicts between same-type objects. 

9. Correct naming conflicts between same type objects. To correct the naming conflicts do 

one of the following: 

• Let the wizard rename the object automatically. 

• Choose to not migrate the object. 

• Merge the objects and maintain the bindery properties. 

• Merge the objects and maintain the NDS properties. 

If you find no naming conflicts, the list box in the wizard page is blank. Click next to 

continue. 

A new wizard page appears showing any naming conflicts between different type 

objects, or items that cannot be merged. These include print forms, print devices, and 

print configurations. 

10. Correct naming conflicts between different type objects. To correct the naming conflicts 

do one of the following: 

• Let the wizard rename the object automatically. 

• Choose to not upgrade the object. 

If you do not choose a conflict resolution option, the object will be renamed. 

If you find no naming conflicts, the list box in the wizard page is blank. 

Address TSA500 Errors 

If the verification results page returns the error “Can’t load the TSA500.NLM,” resolve it by completing 

the following steps: 

1. Save the current project. 

2. Close the migration wizard on the workstation. 



3. Load TSA500.NLM on the NetWare 5.1 server. 

The SMDR configuration screen immediately appears. You are prompted for the SMDR 

group context. 

4. Enter the SMDR group context, or press Enter to select the default. 

Next you are prompted for the SMDR context. 

5. Enter the SMDR context, or press Enter to select the default. 

Next you are prompted for the full-distinguished name of the managing login (use the 

ADMIN login). 

6. Enter the fully-distinguished name of the ADMIN login, and press Enter. 

7. Enter the ADMIN password, and press Enter. 

The target service agent is now successfully loaded. 

8. Run the migration wizard again. 

9. Open the last project. 

10. From the menu bar, click Project, Verify Project. 

11. Repeat the steps from step 2 onward until project verification is finished. 

All errors must be resolved before the migration wizard lets you continue. 

12. Click Next to continue. 

A verification summary page appears with verification results. 

13. Read through the text, and click Finish. 

Migrate Across-the-Wire 

When the project window and verification are completed, and all conflicts, warnings, and errors have been 

addressed, you are ready to migrate the bindery and file system across-the-wire. Do it by completing the 

following steps: 

1. From the toolbar, click the Upgrade button, or choose Project, Upgrade. 

A new wizard launches. The first wizard page describes how the upgrade works. 

2. Click Next. 

Note: From this point, the upgrade repeats all verification steps listed earlier. One 

exception is that the Finish button in step 12 above is now an Upgrade button. 

Any conflicts shown during the previous verification but not corrected are indicated by a check through the 

icon, indicating that the conflict has already been seen. 

3. If you have corrected all the errors, begin the migration by clicking the Upgrade button. 

The wizard first copies the bindery contents, and then the file system (according to where 

you dragged objects in the project window). 

A progress bar indicates the relative percentage of upgraded objects and those yet to be 

upgraded. 

Note: You can stop the migration by clicking Stop. A dialog box appears asking you to 

confirm your choice. If you still want to stop the migration, click Yes. 

The migration is terminated. All NetWare 3.1x server bindery and file contents copied to 

that point remain in their destinations in the NDS tree until you delete them manually. 

If you did not stop the migration, then the process performed by the Upgrade Wizard finishes. 

Go to the “Test Criteria” section later in this subprocess. 



NetWare 4.x to NetWare 5.1 Upgrade Wizard 

You must use Upgrade Wizard 3.0 for a NetWare 4.x to 5.1 upgrade. Older versions of the Upgrade Wizard 

will not work with an upgrade of NetWare 4.x to 5.1. The Upgrade Wizard helps you through the process 

by checking and verifying migration actions prior to the actual migration to minimize risk. 

This upgrade requires a “source” and a “destination” server. The “destination” server will be the new 

upgraded server and can be pre-installed with the new version prior to the upgrade. 

The Upgrade Wizard does the following: 

• Migrates passwords, other bindery and directory objects, and files with trustee assignments/rights 

to the new server hardware. 

• Handles a number of pre-migration validations to increase confidence (for both you and your 

customer). 

• Copies files during business hours (if desired) to minimize file copy time during actual migration 

when you can recopy changed files. 

• Restores all trustees and ownership of files copied. 

• Lets you edit files on the new server while comparing them to their counterparts on the 

old server. 

• Supports license installation (see Licensing Task for more details). 

For an across-the-wire NetWare 4.x to 5.1 upgrade: 

1. Log in to both servers (source and destination) from a workstation. (You must have [Root] 

Admin privileges on the 4.x and 5.1 systems.) 

2. Patch the system. 

Apply patches as indicated on http://support.novell.com . 

3. Run Vrepair.nlm on all volumes. 

Document and resolve any errors. Be sure the appropriate VREPAIR name space support 

modules are loaded during the repair. 

4. Perform an NDS HealthCheck (see Appendix F, NDS HealthCheck Lite, for specific 

information on how to do this). 

5. Perform the upgrade using the Upgrade Wizard, which will walk you through the process. 

Using the Novell Upgrade Wizard is the Novell recommended way to upgrade (across-the-wire) from 

NetWare 4.x. 

NetWare 3.x to NetWare 5.1 Manual Upgrade 

You can only use the manual upgrade option for upgrading from NetWare 3.x to NetWare 5.1. This option 

is not applicable to a NetWare 4.x to NetWare 5.1 upgrade. 

Note: The steps (and dialog) are to be tested and verified in the lab environment. Make the necessary 

changes (as appropriate). The completed status report can be given to the customer as part of their 

implementation plan to be used in the pilot test (subprocess 5). 

A manual upgrade logically follows the same process flow as the NetWare 3.x to NetWare 5.1 Upgrade 

Wizard except that the process of upgrading the bindery and copying the file system is done without 

Upgrade Wizard assistance. This makes the upgrade faster since no workstation is involved. 



Install the NetWare 5.1 Server 

The NetWare 5.1 server must be installed with the latest patches and must meet the NetWare 5.1 minimum 

prerequisites. To do this, complete the following steps: 

1. Use the completed NDS design document to properly determine and set up the 

following: 


• The appropriate server time zone information 

• The type of time server (such as reference, single reference, primary, 

secondary) 

• Replicas to be stored on the server 

• The bindery context needed for the server 

• Admin context and password (if an NDS tree already exists) 

2. Install the appropriate NetWare 5.1 components. 

3. Set up and install the appropriate licensing scheme. 

4. Load and bind the appropriate protocols on the server (such as IPX, IP, IP/CMD, and so 

forth). 

Note: To use the Upgrade Wizard, IPX must be bound on the NetWare 5.1 server. 

You can unbind IPX afterwards (if appropriate). 

5. Set up the appropriate SLP. 

6. If volumes to be migrated from NetWare 3.x contain files with non-DOS naming 

conventions, you must load the appropriate name spaces on the destination volumes of 

the NetWare 5.1 server and add the name spaces to the volume prior to the migration. 

• Windows 95, Windows NT, and OS/2 name spaces are loaded through 

LONG.NAM (long names). 

• The NFS name space is loaded through NFS.NAM. 

• The Macintosh name space is loaded through MAC.NAM. 

Prep the NetWare 3.x Server 

The following can and should be done the day before the actual upgrade to ensure that there are no 

significant changes to the bindery and file system: 

1. Delete old and unused bindery information such as users, groups, print servers, and print 

queues. 



3. Run BINDFIX a second time to obtain a set of clean bindery files. 





6. Optional: Create two complete backups of the cleaned up NetWare 3.x server (after 

steps 1 and 2 above are done). 

Ensure that these backups can be restored. Since the NetWare 3.x server remains up, the 

backups are not crucial but are still recommended. 





Perform the Manual Upgrade 

Important: The bindery must be upgraded into NDS first. If the bindery is not in place before the file 

system is restored, all trustee assignments will be lost. 



2. Run BINDFIX a second time to obtain a set of clean bindery (*.OLD) files. 

2. Copy these *.OLD files to the SYS:SYSTEM directory on the NetWare 5.1 server, and 

rename them to *.SYS files. 

3. Set BINDERY CONTEXT on the NetWare 5.1 server to the container you want the 

bindery objects imported to. The NetWare 5.1 server must have a read-write or higher 

replica of container you are setting bindery context to. 

4. Import the NetWare 3.x bindery files into NetWare 5.1/NDS using one of the following: 

• NWCONFIG 

• Directory options 

• Upgrade NetWare 3.x bindery information into the directory 

At this point, the NetWare 3.x bindery is migrated into NDS. 

Copy the File System from NetWare 3.x to NetWare 5.1 

The necessary NetWare 3.x files can be copied to the NetWare 5.1 server. Novell recommends a server-toserver 

restore (for speed) or another option that will preserve trustee assignments, name space, IRM, and 

directory restrictions. 

Note: Do not use COPY or NCOPY because these two utilities change ownership to the UserID 

performing the copy and all trustee assignments are lost. 

Cleaning Up NDS After a Manual Upgrade 

If users have multiple accounts on multiple NetWare 3.x servers and all of these NetWare 3.x users and 

servers are placed into the same NDS container, the upgrade utility will ask or handle how to merge likenamed 

user accounts. However, if users and servers are not upgraded into the same NDS container, you 

need to decide which user account to keep in NDS, as the NDS goal is one user account per tree. 

The MERGEGROUP utility available from http://www.dreamlan.com can be used to combine the group 

membership list for a user. 

The CLEANUP utility can be used in NDS to convert uppercase names (which is how they are represented 

in the bindery) to lowercase names. Additionally, this utility replaces spaces in names with underscores. 

Accelerated Upgrade 

This is for NetWare 4.x or 5.0 to NetWare 5.1 upgrades. 

Before you begin the upgrade, you must already have one NetWare 5.1 server that was installed as an inplace 

upgrade in order to use the accelerated upgrade utility; this is because the accelerated upgrade utility 

does not extend the schema. 



Do these steps to prepare for an accelerated upgrade: 

1. Copy the accelerated upgrade utility (UPGRADE.IPS) to the source server (use your 

existing NetWare 5.1 server with the CD mounted). 

2. Prepare the destination server (the server to be upgraded—your existing 4.x server). 

3. Make a backup of the DOS partition. If downtime is a concern, try using MOUNTDOS.EXE 

(a third-party utility) to mount the DOS partition as a volume, and copy the data elsewhere 

to another location (your workstation or an existing server not affected by this upgrade). 

Do these steps to complete the upgrade: 

1. Access the NetWare 4.x console (either directly or via RCONSOLE). 

2. Load INSTALL.NLM. 

3. Select Product Options, then select Install a Product Not Listed. 

4. Press F3, and enter the path to the directory (on your source server) where the accelerated 

upgrade utility is located (UPGRADE.IPS). 

5. Log in to the source server (must have admin equivalency). 

6. Select the tasks to be performed. Normally, select all the tasks unless you need to do 

something unique. 

7. Enter the directory of the NetWare 5.1 CDROM (sourceservername/volume:) 

8. Verify the directory name for DOS partition files (default is C:\NWSERVER). 

Once steps 1-8 are done, the utility will copy the necessary files, reboot, and automatically run the 

hardware detection NLMs. The auto-detection code will then replace your existing STARTUP.NCF, to 

load the appropriate .HAM and .CDM drivers when it reboots. As a backup, the existing drivers will 

automatically be renamed with a .OLD extension. 

By default, the server will allow three connections to the new server before licensing is installed. The 

upgrade utility does not allow for licensing. You must use NWCONFIG.NLM to install the appropriate 

license after the server is up. (According to documentation, licensing can now be handled by the 

Accelerated Upgrade utility; as of this writing, it has not been tested or verified.) 

Note: An accelerated upgrade is a utility that lets you quickly upgrade a NetWare 4.11+ server to 

NetWare 5.1 without having to be at the server console. The accelerated upgrade utility assumes that the 

baseline configuration has been met (hardware requirements, etc.) from PFC information previously 

gathered. It uses a text-based script to copy all the files necessary for the upgrade. You can help yourself by 

either pre-mounting the NetWare5.1 CD in a server, or by having these files available elsewhere on the 

network. You must access the target server’s console directly or via RCONSOLE. Using a source server 

eliminates the need to physically access the server being upgraded. 

An accelerated upgrade has the following limitations: 

• The server cannot be the first NetWare 5.1 server in the tree. 

• The server must be running NetWare 4.10?? or 4.11 (patched). 

If it is a NetWare 4.10 server, it must already have long name space on all volumes, and not have 

more than 1 million directory entries on any volume. (Does not apply to 4.11). 

• The server cannot be running SFT-III. 

• The server cannot be running HCSS. 

• The server must already have IP bound to the LAN adapters. (You cannot add IP during the 

accelerated upgrade. Technically, you could add IP after installation is completed.) 

• The REMOTE.nlm and RSPX.NLM must be loaded. 



The following are the minimum requirements for using an accelerated upgrade: 

• The server must meet the Novell recommended NetWare 5.1 hardware specifications (see 

“NetWare 5.1 Prerequisites”). 

• There must be 35-50MB of disk space available on the DOS partition (you can get by with 25MB) 

and 250MB available on the SYS: volume (purge the volume first). You can get by with the 

25MB available on the DOS partition if and only if you are copying over existing files (i.e. 

C:\NWSERVER.) 

• Access to the accelerated upgrade script (UPGRADE.IPS). 

• Access to the upgrade files on the network (the NetWare 5.1 CD). 

• Access to the license disk (you can always add the license later after the server reboots). 

The accelerated upgrade is used for NetWare 4.x customers to quickly get upgraded to NetWare 5.1. This 

utility is not available for NetWare 3.x customers. 

DSMAINT 

DSMAINT requires that you have an NDS version of NetWare (non NetWare 3.x servers). This upgrade is 

similar to the across-the-wire upgrade in that it requires a “source” and “destination” server. 

This document briefly describes how to use DSMAINT.NLM to upgrade a NetWare server to newer 

hardware. For purposes of this document, the term “Server A” refers to the NetWare server being replaced. 

The term “Server B” refers to the new server. Server B will completely replace Server A in the tree. 

The following tasks outline the overall procedure: 

1. Ensure the NDS tree is healthy on Server A. 

2. Back up Server A with SMS compliant software. 

3. Log in to Server A. 

4. Use DSMAINT.NLM to back up directory services. 

5. Copy the backup.ds file to a local client hard drive. 

6. Install Server B into a “bogus” tree with the same name and IPX number as Server A. 

7. Log in to Server B and copy backup.ds to the SYS:\SYSTEM directory. 

8. Remove directory services from Server B. 

9. Use DSMAINT.NLM or INSTALL.NLM to restore directory services to Server B. 

10. Reinstall the backup software to Server B and restore the file system and trustees from tape. 

11. Verify the integrity of the migration. 

Ensure that the NDS tree is healthy on Server A. 

The NDS tree must be healthy before anything is done. There cannot be any communication 

(-625), synchronization, or TTS (-621) errors in the tree. There will be problems with the upgrade if these 

errors are not resolved. 

1. Load DSREPAIR.NLM on the server that holds the master of the [Root] partition and run 

Time Synchronization. Make sure that all servers are synchronized and error free. 

If there are time sync problems, see TID 2930686 for help in resolving them. 



2. Run “Report Synchronization Status” on the Master of [Root]. 

If there are any errors, resolve them. For example, a -625 error means there is a 

communication error with a specific server. Search the web for specific references to these 

problems and how to resolve them, or talk with Novell Technical Support about fixing them. 

3. If necessary, repair the directory services database of Server A. 

Load DSREPAIR.NLM, Advanced Options, Repair Local DS Database. 

Set every option to “No” except for “Check Local References.” 

Press F10 to run the repair. 

Save the database if the number of errors is low (fewer than 20). Run DSREPAIR and save 

until there are no more errors. Review the log file to determine what errors occurred. 

If there are no errors in either time synchronization or report synchronization status, the Tree 

is healthy. However, if the Tree is large, you may run this procedure (time synchronization 

and report synchronization status) at different points in the Tree to guarantee that there are 

no problems. 

Performing a DSMAINT procedure on a server that holds the master replica of a partition ([Root] or 

another partition) is not necessary with NetWare 4.1x and NetWare 5.1 as it was with NetWare 4.0x. 

Beginning with NetWare 4.1x, NDS recognizes that the master replica is down and all requests are routed 

through a read/write replica of the partition. When a new server is brought online, it receives all of the 

updates that occurred while that master replica was offline. 

The master replica of a partition is needed for: 

• Partitioning operations 

• Janitor process (cleaning up deleted, renamed, or moved objects) 

• Limber process (server address and name checking) 

• Other NDS background processes 

Note: When using DSMAINT on a server that holds the master replica of a partition, do not perform 

partitioning operations, move, delete, or rename objects in the tree while the server is offline. 

Because every 4.x server (or above) contains a directory services database, DSMAINT can even be used on 

a server that does not hold any replicas (external reference server). External reference servers do not hold 

real objects like a server that has a read/write or master replica, but pieces of objects are located on them. 

The external references comprise the DS database on this type of server. If DSMAINT is not used, the 

printing, trustees, and anything else specifically identified with the server will be lost and will have to be 

recreated by hand. 

Back up Server A with SMS compliant software. 

SMS compliant software includes ARCserve, Backup Exec, and SBACKUP.NLM. The backup must use 

Novell’s TSAs in order to copy data and trustees from the server. 

You must enable a switch in ARCserve because it does not back up NetWare trustees by default. Go to the 

ARCserve Scheduler console screen and into “Configure ARCserve server.” Make sure that “Use SMS 

logic for DOS and Mac files also” is set to “Yes.” 

If your backup program does not use Novell’s TSAs, the trustees on every volume must be reassigned 

manually on Server B. 



Note: Some customers have tried to copy data from Server A to Server B (before making the DS switch). 

When this occurs, the trustees—ownership and file rights—are not copied. 

Directory services must go on before the trustees are laid down with the file system. Trustees are not a part 

of directory services. They are a part of the file system, so restoring directory services will not restore 

trustees. Trustees are re-linked to directory services by their full distinguished names (cn=admin.o=novell). 

If that name does not exist in directory services, the trustee is deleted. Therefore, NCOPY (which does not 

copy trustees) will not work by itself. The TCOPY or TBACK utilities from the support.novell.com site 

have to be used also. Restoring the file system and trustees before NDS is restored does not work either 

because the trustees have nothing to link to, or they will try to link to a name that does not exist in NDS. 

The trustees will be invalid and will be deleted. Replace NDS first, then trustees. 

Novell has programs on its web site that may ease this problem. TCOPY is a file migration utility. 

However, it only works in 4.x to 4.x (or 5.x) environments and both servers must be up and operating. This 

means that the NetWare OS cannot be upgraded because both servers cannot be on the wire at the same 

time. Using TCOPY alone is the same as restoring the file system before the directory is restored. 

TBACKUP, on the other hand, will back up trustees and let you restore them afterwards (IRF, ownership, 

rights, etc.). To use this program, copy the data from Server A to Server B. After the directory is moved 

over, use the TBACKUP file from Server A to restore the trustee rights. Both TCOPY and TBACKUP can 

be found on the minimum patch list page at http://support.novell.com. 

If you have an SMS compliant backup program, use it and don’t bother with the other methods. It depends 

on your schedule and what you can accomplish ahead of time to prevent a long day. 

1. Make sure you use the latest version of target service agents (TSAs) on the server. 

2. If necessary, apply the server patch kit for 4.11 (IWSP5b) or SMSUP6 for NetWare 4.10. 

Note: The version of the TSAs used is critical because the storage of the full distinguished 

name in the trustees list depends upon it. 

3. Do the SMS-compliant backup. 

Use DSMAINT.NLM to back up directory services. 

1. Log in to Server A as admin or admin equivalent, and map a drive to the system directory. 

Note: You must log in to Server A before backing up the directory; once the backup begins 

directory services are locked and login is disabled. 

2. Search the system directory for a file called “backup.ds” or “backup.nds.” If either file 

exists, delete or rename it. 

Note: Rename or delete the backup.ds or backup.nds file before running DSMAINT; 

otherwise, problems will occur. DSMAINT creates backup.ds, and INSTALL.NLM creates 

backup.nds during a backup of directory services. 

3. If necessary, upgrade Server A to the latest version of DS (DS411L.EXE). The latest version 

of DS also updates DSMAINT.NLM and others. 

You are now ready to back up directory services. 

Note: If DS411L.EXE, or later, is installed on the NetWare 4.11server (includes DS.NLM 

version 5.99a), follow the 4.10 procedure with DSMAINT. Use the improved version of 

DSMAINT included with DS411L.EXE; otherwise, load INSTALL.NLM at the system 

console prompt. Choose “Directory Options” and then “Directory Backup and Restore 

Options.” Then select “Save Local DS Information Prior to Hardware Upgrade.” 

4. Establish an RCONSOLE session with Server A, and load DSMAINT.NLM. 

5. Select the option to back up directory services. Read the warning screen that appears. 



6. Log in as the system administrator using the full context (.admin.novell, for example). If you 

do not use the full context for the administrator, a -601 error appears saying, “unable to 

locate object.” 

7. Redirect and save the NDS backup file to SYS:\SYSTEM. 

Note: Some versions of DSMAINT.NLM will ask for an alternate path to store the backup 

file. Always redirect the file to SYS:\SYSTEM. (Remember, you are logged into this server 

from your PC and probably running this utility via an RCONSOLE session.) 

Never save the file to Drive A:\. Most customers have NDS databases that are larger than 

1.44 MB. DSMAINT.NLM does not provide a way to span diskettes. If you accidentally 

choose to store the NDS backup file on drive A: and your database is larger than 1.44 MB, it 

won’t work. 

Note: After the backup is complete, Server A’s directory services database is locked. No 

one can log in to the server, and no changes can take place in its database. (Do not perform 

any other DS maintenance tasks at all until this entire process is completed.) 

Since NDS is a dynamic environment, DSMAINT.NLM locks the NDS database to create a 

static copy of it. Backing up NDS and letting it remain open guarantees that changes will 

occur between the time the backup is performed and when NDS is restored to the network. 

Often the consequences of those changes are not easy to fix. Turning a dynamic process to a 

static one creates a point of reference so that when NDS is restored to Server B, the other 

servers in the network will know exactly where to pick up and send updates. 

8. Once the backup of directory services is complete, go to the client workstation that is 

already logged in and retrieve the backup.nds file (backup.ds for DSMAINT.NLM users), 

and copy it to the local hard drive. 

Note: Do not delete this file on either the client or server—it is the only copy of Server A’s 

directory. If there are any problems with the new server (Server B), this file lets you unlock 

DS on Server A so that it can still function while problems with Server B are being 

addressed. Just leave it alone. If there are multiple instances of the file, check the date and 

time and copy the most recent one. 

9. Down Server A and remove it from the network. Set Server A aside until Server B is on the 

network and functioning properly. 

Note: For now, ignore Server A. Do not FDISK or reformat the hard drive. Do not run it as 

a client workstation. 

Install NetWare on Server B. 

When NetWare is installed on Server B, make sure it is identical to Server A. For instance, if compression 

was enabled on Server A, enable compression on Server B. (Use INSTALL.NLM to check compression in 

“Volume Options.”) If name spaces were installed on Server A, make sure name spaces are installed on 

Server B. (Type “volumes” at the system console.) 

Sub-allocation and block sizes can differ from Server A to Server B. In other words, Server A could have a 

volume with sub-allocation disabled and a 4KB block size while Server B’s corresponding volume could 

have sub-allocation enabled and a 64KB block size. The specific difference doesn’t matter. Consider 

copying the contents of the DOS partition from server to server—including the startup.ncf file. This is a 

convenient way to apply all of the patches from one server to the other. However, the drivers in the 

startup.ncf will probably change because the new server will likely have different hardware and will 

therefore need different drivers and settings in the startup.ncf file. Do not copy the patches from a 

NetWare 4.10 to 4.11 server—they are not compatible. Install the service pack to enable the patches. 



1. Give Server B the same name and internal IPX number as Server A. 

Note: As long as Server A is no longer on the network, you shouldn’t experience any LAN 

communication problems. Having two servers on the same network with identical IPX 

numbers and names can prevent routers from finding the correct server to address data to 

because each server is broadcasting itself as the correct route. To address this problem, 

either install NetWare with Server B offline, or insert Server B into the production LAN 

only after server A has been turned off. 

2. Create a temporary (new) NDS Tree for Server B unless Server A was the only server on the 

network. 

Note: NetWare does not process Directory Services SAP traffic across Trees, so even 

though Server B has the same name and IPX number as Server A, it isn’t known to the rest 

of the servers on the network. The other NetWare servers still believe Server A is down. If 

server B is installed into the same Tree as Server A and the other server or servers 

communicate with it, NDS will not synchronize properly. 

3. Upgrade DS.NLM to the latest version and apply the appropriate patches to Server B. 

4. Log in to Server B as admin or an admin equivalent and copy the backup.ds or backup.nds 

file from Server A to the SYS:\SYSTEM directory. (Backup.ds is the file that 

DSMAINT.NLM creates and uses. Backup.nds is the file that INSTALL.NLM creates and 

uses.) 

5. Load INSTALL.NLM, and remove Directory Services from Server B. Select “Directory 

Options,” then “Remove Directory Services from this Server.” 

6. Log in as admin using the full context and make sure that Directory Services are removed. 

Note: Because Server B is the only one in the temporary tree, it holds the Master replica of 

[Root] and is a Single time source. Error messages to that effect will warn you not to 

continue. Ignore them and go on. 

7. Restore backup.ds or backup.nds using DSMAINT.NLM or INSTALL.NLM as appropriate. 

Note: Novell recommends using the same program to restore the file that you used to back it 

up. Ideally, DSMAINT.NLM should be used throughout the procedure instead of 

INSTALL.NLM. 

NetWare 4.11 and NetWare 5.1 do not come with DSMAINT.NLM installed on the server 

by default. A directory services patch must be applied to NetWare 4.11. For NetWare 5.1, 

DSMAINT.NLM can be found in a NetWare 4.11directory services patch. Check 

http://support.novell.com on the minimum patch list page for this patch. 

8. Edit Server B’s AUTOEXEC.NCF and change the time server type from Single to 

Secondary. 

9. Using INSTALL.NLM or DSMAINT.NLM, restore Directory Services, and place Server B 

in the “original” (production) tree. (Do not choose to restore server references or anything 

like that—leave these options alone. The top two options are the only ones used in this 

procedure.) 

Note: If you are asked to log in, make sure it is with full context (.admin.novell). 

Some errors may result at this point if the procedure was not followed correctly. 

If all of the servers are not up and communicating (except Server A), the file will not be 

restored. This program “talks” with every server that Server A knew about. If one is down, 

the restore will error out and fail. 

If the IPX internal network number and the name of Server B are not the same as server A’s, 

the restore will fail. If this happens an error message will inform you that the IPX numbers 

are different between the servers and that backup.ds cannot be restored. 



Restore the file system and trustees to Server B. 

1. Install the backup software to Server B. 

Note: Use the same program and version that you used to back up Server A. 

2. Restore the file system and trustees. 

Note: Never restore NDS from your tape backup during a dsmaint procedure. 

Common questions and answers concerning the restoration of files 

Questions Answers 

If the server is upgraded to a 

newer version (4.10 to 4.11, for 

example), should every file be 

copied—including the system 

and public files? 

If the server is not upgraded to a 

newer version of NetWare, 

should every file be copied? 

No. There are four directories you will 

probably not copy from the SYS volume: 

SYSTEM, PUBLIC, LOGIN, and ETC. 

However, some of the configuration files in 

the ETC directory should be brought across 

if the server used MPR or NFS, for 

example. Mail directories may need to be 

copied across if there are users who 

authenticate to the server with a bindery 

connection, or if programs, such as Pegasus 

Mail used the mail directory. You may also 

need to restore the Queue directories so that 

Server B can use Server A’s print queues. 

Yes. By default, this type of migration 

means that the two servers will be the same. 

Note: If you accidentally restore NDS (from the tape backup software) to Server B, there 

will be big problems if it is left in the production environment. To fix these problems, 

remove directory services, restore the backup.ds file using DSMAINT.NLM, and restore the 

file system again. The file system must be restored again because directory services was 

removed. When directory services are removed from a server, all of the trustees to every 

volume are removed too. 

1. Use NWADMIN to make sure trustees and rights were restored correctly. Make sure that 

printing works correctly, the login scripts function, and anything else you feel important is 

running well. 

2. Allow the server 20-30 minutes to contact other servers on the LAN and re-establish its 

synchronization ring. 

3. Use DSREPAIR to check synchronization status. 

What to do if Server B doesn’t work correctly and Server A needs to come back up: 

1. Take Server B off the network. (Unplug the LAN cable or down the server.) 

2. Connect Server A to the network and bring it up. 

Note: Server A will report an error immediately after mounting the SYS volume that the 

local database is inconsistent and cannot be opened. NetWare will suggest using 

DSREPAIR to fix the problem. Ignore this message. DSREPAIR cannot fix this problem. 

The error is a result of the database changes made to NDS while DSMAINT performed the 

backup. 



3. Load DSMAINT.NLM or INSTALL.NLM (whichever one was used to do the backup), and 

choose the option to restore directory services after a hardware upgrade. If asked, direct the 

program to SYS:\SYSTEM for the backup.ds file. Directory services will be restored from 

the backup.ds file on Server A. After the restore, Server A should function as before. 

4. Use INSTALL.NLM to remove directory services from Server B so that the DSMAINT 

process can be repeated cleanly. 

Note: If this does not work, you can log an incident with Novell Technical Support who can 

provide additional help with the restoration of backup.ds. Do not forcefully remove 

directory services from Server A until you have talked with Novell about this problem 

unless you are confident that removing DS from Server A will result in a faster resolution. 

Removing DS problems (usually happens with Server A after Server B is working properly): 

If you have problems removing directory services from a server, type “load install – dsremove” at the 

command line to remove it forcefully. 

INSTALL.NLM will go down the same code path to remove directory services as if the 

“– dsremove” switch was not loaded. However, install will not stop the removal of directory services when 

errors are encountered as it normally does. It will continue until removal is complete despite any errors that 

come up. Essentially it will remove the NDS files from the server no matter what. Ignore any errors that 

come up even if Install says, “directory services was not successfully removed.” If it prompts you to log in, 

press Esc, and skip the login prompt. 

Normally, INSTALL.NLM will contact the other servers in the Tree and tell them that a specific server is 

having its directory services database removed. These servers will remove all references to that server. 

When communication has broken down between servers, INSTALL.NLM has a hard time contacting other 

servers to inform them of changes. Forcefully removing directory services from a server can leave behind 

remnants of the directory that will cause problems if they’re not taken care of. 

If directory services will not come off Server B, remove them (offline) using the “– dsremove” switch. 

Conversely, if Server B is successfully placed into the Tree, but Server A’s directory services will not come 

off, remove them forcefully. There will be no consequences in removing directory services from Server A 

because Server B has replaced it. 

Warning: Do not remove directory services forcefully from a server unless you understand all of the 

consequences and are prepared to deal with them. 

Test Criteria 

The following criteria must be tested and validated in the prototype to verify the success of the conversion. 

Determine what the customer’s pass/fail criteria are for the upgrade to NetWare 5.1. It will be necessary to 

document, discuss, and troubleshoot issues as they arise during the test and validation phase. Any items that 

fail must be properly resolved. The resolution must be documented. Each and every item test criteria item 

must pass before the engagement can continue. 

Log in as a typical user (not Admin), and verify authentication to NDS. 

❏ ❏ Verify conversion of login scripts and proper execution. 



❏ ❏ 

Note: Don’t forget the user login scripts (if appropriate). The MAIL 

directories become messy, since all user object IDs are changed during 

an across-the-wire (ATW) upgrade (not during an in-place upgrade). 

Verify that drive mappings are correct and functional. 

❏ ❏ Verify that print queues are captured. 

❏ ❏ Verify printing from all applications that existed pre-migration. 

❏ ❏ Verify rights to objects and containers (this also may include 

ACL/filters, etc.). 

❏ ❏ Verify SAP/RIP by display servers at the console. 

❏ ❏ Verify that volumes are mounted (VOLINFO or volumes at the system 

console). 

❏ ❏ Verify that IP/IPX is bound (if it is the desired protocol). 

❏ ❏ Verify that pre-migration applications run in accordance with the 

prototype. 

❏ ❏ Verify that all pre-migration NLMs are loaded and functional (a list of 

pre-migration from the PFC). 

❏ ❏ Verify that the files were migrated. 

Note: It has been reported in the support forums that the Upgrade 

Wizard indicates that it is migrating files when it actually is not. 

❏ ❏ Load common utilities (install.nlm/monitor/nwconfig), and verify that 

utilization is normal. 

❏ ❏ Verify that all memory can be seen and is available. 

❏ ❏ Verify that licensing is functional as per the design document. 

❏ ❏ Verify that VREPAIR can be run successfully. 

Task 4—Modify and Retest Prototype as Required 

Update all process documentation until the process works without error in the lab. 

Task 5—Document Solution Design 

Update the solution design report to include lab testing results. This document will now be used for the 

pilot. 

The customer should sign off on the lab testing. Everything should be in a pass state before proceeding to 

the pilot test (subprocess 5). 



Task 6—Review and Deliver Solution Design Report to Customer 


The project manager should review your solution design report and make any recommendations or 

suggestions. 

Activity 2—Deliver Solution Design Report 

Deliver the solution design report to the customer. 

Task 7—(Conditional) Negotiate Pilot Work Order 

(Conditional) Prepare, present, and negotiate a work order agreement for pilot implementation. 



Subprocess 5—Perform the Pilot 

The pilot is performed on production workstations (a small subset). 

Key Inputs 

Personnel 



• Customer contacts 



• Suggested pilot sites with site surveys 

• Solution design 

• Modified system implementation plan 

• Modified test and acceptance plan 

1. Prepare a draft deployment plan and pilot test report. 


Subprocess 5—Perform the Pilot 

Task Summary 

Key Outputs 

Personnel 



• Identified pilot sites w/site surveys 

• Pilot systems 

• Pilot results 

• Pilot system documentation 

• Test and acceptance documents of pilot systems 

• Debriefing 



• Closing report 

2. Identify potential pilot sites; gather site surveys, evaluate and select pilot sites. 

3. Develop a detailed system implementation plan for each pilot site. 

4. Build and test pilot systems per solution design specifications. 

5. Modify and retest pilot system as required. 

6. Document final solution design and reports. 

7. Review and deliver reports to customer. 

Task 1—Identify Pilot Sites 

Choose a fairly technical department within the company to act as the pilot site (such as the MIS 

department). These people are used to dealing with computer problems and can provide good input if 

something goes wrong. They may even know how to resolve the problem. This department can be around 

30 to 50 people. Avoid selecting a department with sales people or high-level executives. 

User feedback is critical during the pilot test, so select pilot users carefully. The pilot group should be 

located physically near your IS staff so that problems can be documented and fixed quickly and in-person. 



Task 2—Prepare Pilot Implementation Plan 

The pilot implementation plan provides information, logic, and recommendations for performing the 

NetWare 5.1 upgrade in the limited production environment. The pilot implementation plan is based upon 

your testing and reports from the lab (subprocess 4). 

This plan should contain information about the upgrade hierarchy (or order) for implementing NetWare 

5.1. The order depends on the network design and on the customer’s network protocol migration objectives. 

For example, if the customer chooses to upgrade the servers using the dual stacks approach, then few 

restrictions exist regarding the network upgrade order. On the other hand, if the customer chooses a rapid 

IP transition option, then the upgrade sequence will be more tightly controlled. The plan should also 

include information about pilot test sites, which reside in the customer’s production network. 

At this stage the implementation plan will be considered a “draft” and will be updated appropriately based 

upon the pilot results. 

Task 3—Prepare Pilot Test Plan 

This plan will document what will be tested after the upgrade, to determine whether or not the upgrade was 

successful. You can use the Test Criteria from the previous subprocess; additional examples include: 

• Can the workstation log in? 

• Can they run NAL-delivered applications (if appropriate)? 

• Can they print? 

• Etc. 

Task 4—Perform the Pilot 

Use the information from tasks 1-3. 

Task 5—Modify Implementation Plan (if appropriate) 

Note anything that did not work as expected in the pilot and revise for the full implementation. If 

appropriate, you can retest again in the lab before implementation to the rest of the production 

environment. 

Task 6—Document Final Solution Design 

Update the implementation plan created in task 2 using information from the pilot. This report should 

include final recommendations on steps the customer should take to complete the project. 

Task 7—Create the Closing Report 

The closing report summarizes the information, design considerations, and recommendations for the 

NetWare 5.1 upgrade project. The report summarizes project status, key project issues, and outstanding 

issues or concerns. The report also discusses future considerations and recommendations. 

Task 8—Review and Deliver Final Solution Design and Closing 



Reports to Customer 


The project manager should review your final solution design and closing reports and make any 

recommendations or suggestions. 

Activity 2—Deliver Final Solution Design and Closing Reports 

Deliver final solution design and closing reports to the customer. 

Consider sending copies of the report to the Novell sales representative and to the Novell service account 

manager (SAM). 



Deploying Novell Distributed Print Services 

(NDPS) 

NetWare 5.1 provides support for, and ships with, the following methods of network printing: 

Notes: 

• Legacy NetWare queue-based printing (QMS) 

Note: Upgrading to NetWare 5.1 will not disable queue-based printing (as it states in the 

README). What the documentation people were trying to say is that there is no IP support for 

queue-based printing. 

• Novell Distributed Print Services (NDPS) Version 2.1.1 which includes these new features: 

• Internet Printing Protocol (IPP) 

• Line Printer/Line Printer Daemon (LPR/LPD) 

• Vendor-specific gateways 

• NetWare Print Services for Unix does not ship with NetWare 5.1 (it did with NetWare 5.0). 

Please contact Novell Support to obtain this product. However, Novell recommends that you try 

to get the customer to transition to using NDPS. Setting up NetWare Print Services for Unix will 

not be discussed here. 

• NDPS Version 2.1.1 ships with NetWare 5.1 and only runs on NetWare 5.1 

• NDPS Version 2.0 is used with NetWare 5.0. 

• NDPS 1.0 (or the new NEPS) runs on NetWare 4.11 or NetWare 4.2. 

What’s New With NDPS 2.1.1 

New in NDPS 2.1.1 as compared to NDPS 2.0 are: 

• LPR Server -- NDPS connectivity for users who have access to LPR (Unix, Mac, etc.). 

• IPP Server -- NDPS connectivity for users who have access to IPP (small now but growing). 

• New third party gateway support - Kyocera, Lexmark, Epson, Tektronix, Axis, Extended Systems. 

• More features will be exposed in Support Pack 1. 

New in NDPS 2.0 as compared to NDPS 1.0: 

• Fault Tolerance. NDPS 1.0 did not allow you to load the NDPS Manager on any server other than 

the server on which you originally created the NDPS Manager. NDPS 2.0 allows you to load the 

NDPS Manager on other servers. If you shut down the server on which the NDPS Manager is 

running or if that server abends, you can load the NDPS Manager on another server and continue 

to provide print services without interruption 

• NDPS Client Software for Windows NT and Windows 98 clients. NDPS 1.0 provided client 

software only for Windows 95 and 3.1x clients. 

• Support for Windows Add Printer Wizard. With NDPS 1.0, you had to install printers on NDPS 

clients using NWPM.EXE (available on each client desktop). Alternately, you could remotely 

install printers using PSETUP.EXE. With NDPS 2.0, NDPS users can use the Add Printer Wizard 

utility available on Windows clients to install printers on their desktop. 



• Improved Utility for Remotely Installing NDPS Printers. NDPS 1.0 provided a way to remotely 

install NDPS printers on desktops through the PSETUP.EXE file, which worked but had several 

limitations. NDPS 2.0 includes the Remote Printer Management utility, which overcomes the 

limitations of PSETUP.EXE. The Remote Printer Management utility offers the following 

improvements to PSETUP.EXE: 

• Enables you to install and uninstall public access printers (as well as controlled access 

printers). 

• Uses time-stamping to determine whether or not an NDPS client requires updating 

at login time. 

• Enables you to load new printer drivers for NDPS printers that are already installed on client 

desktops without disturbing the clients’ printer profiles. 

• Enables you to access the utility through the NetWare Administrator (NWADMIN) utility. 

• Support for Printers on IP Networks. NDPS 1.0 provided no way to print in IP-only environments. 

NDPS 2.0 includes an NDPS Gateway to support Line Printer Remote/Line Printer Daemon 

(LPR/LPD) printers on IP networks and an enhanced Hewlett-Packard gateway, which can print 

over both IP and IPX to JetDirect cards. 

• Support for Simple Mail Transfer Protocol (SMTP). NDPS 1.0 did not support SMTP. NDPS 2.0 

supports SMTP. As a result, NDPS can notify users of printer and job events through any e-mail 

system that also supports SMTP. 

• Customizable Server Install. NDPS 1.0 server installation program copied not only system and 

public files but also resource management files to the NetWare installation volume. NDPS 2.0 

allows you to customize the server installation program to install only system and public files, 

enabling you to install resource management files only when necessary. 

Queue-Based Printing 

The following table helps illustrate some common points concerning the use of the legacy NetWare (QMS) 

printing environment after upgrading to NetWare 5.1: 

Benefits Issues 

Less thought about printing is required 

during the upgrade process. 

Works for bindery-based programs and 

workstations. 

The environment is IPX dependent. This 

prevents a pure IP environment and impacts the 

SLP design, because MAs must be used for 

connectivity. 

Each printer in the printing environment requires 

at least three separate NDS objects in the tree. If 

there are many networked printers, there could 

be a noticeable impact on the size and speed of 

NDS. 

Printers can get automatically logged off from the 

NetWare servers because of lost watchdog 

packets. This creates a service interruption for 

the users. 

Workstation-based connections to printers often 

have to be re-established after a network 

upgrade. If workstations need reconfiguration, 

the incremental cost to configure them for an 

alternative print solution would be minimal. 



Novell Distributed Print Services (NDPS) 

The NDPS printing environment is a TCP/IP-based solution that integrates printing with the NDS 

infrastructure. NDPS was developed to simplify management and reduce the expenses related to 

maintaining network printing. The functionality of NDPS is possible because of NDS, which allows 

administrators to centrally manage NDPS from the NetWare Administrator utility. 

NDPS automates and eases most aspects of network-based printing by providing: 

• Solid integration with NDS 

• Usability in a pure IP-based or IPX-based environment (or a mixture of both) 

• Simplified and centralized administration of all printing resources through NWAdmn32; this 

administration is done on a container basis; user and group functionality should be added around 

the BrainShare 2000 time frame 

• Automatic printer driver download and installation 

• Bi-directitonal feedback and control of printers and jobs 

• Support for existing printers and printing technologies (full backward compatibility) 

• New printer and job configuration options for specific printers 

• New print job scheduling and notification options (e.g., scheduling jobs according to time of day 

or size) 

• Remote workstation printer management capabilities 

The following table helps illustrate some common points concerning the transition to an NDPS printing 

environment during a NetWare 5.1 upgrade: 

Benefits Issues 

NDPS is easy to set up and administer. 

Once the software is installed on the servers 

and clients, the configuration within NDS is 

centrally managed. 

The NDPS server is less likely to have a 

failure than the legacy print servers. 

NDPS is a TCP/IP-based printing solution. It 

will remove the IPX dependencies from the 

printing environment. 

Print driver distribution is automated through 

NDPS. Each NDPS server has a database 

of print drivers that are distributed to the 

workstations when print services are 

requested. This driver database is 

customizable so new printers can be 

managed through NDPS as long as a driver 

is provided from the printer manufacturer. 

NDPS provides manageability to the printing 

environment. When using NDPS controlled 

access printers, print jobs can be monitored, 

paused, and deleted. 

NDPS requires NetWare 5.1 servers to run 

NDPS related NLMs to provide the printing 

services. Loading these NLMs will increase 

resource utilization on a NetWare 5.1 server. 

The NDPS server becomes a point of failure in 

the printing environment. In the event the NDPS 

server goes down, the printers associated with 

that server will not be available. 

The workstations need relatively new clients (that 

support NDS, IP, and NDPS). 

If the print server hardware does not natively 

support NDPS, a NDPS gateway will need to be 

loaded and configured to enable non-NDPS 

printers to work with NDPS. 

An SLP infrastructure is required. 



NDPS controlled access printers require 

only one NDS object per printer versus 

legacy printing; this reduces the number of 

NDS objects required in the NDS tree for 

printing. 

To print in a pure IP environment, external print 

server hardware, such as JetDirect cards, must 

support the TCP/IP protocol. 

As a printing solution, NDPS makes the most sense for clients who plan to utilize TCP/IP. However, the 

NDPS printing environment must be carefully planned before it is implemented. A poor implementation of 

NDPS will cause excessive network traffic, and it may adversely affect the performance of other services 

on the network if loaded on the wrong servers. 

NDPS Components 

There are four main components to NDPS that need to be discussed so that an efficient NDPS infrastructure 

can be designed. 

(1) NDPS Broker 

The broker (BROKER.NLM) is loaded on a NetWare 5.1 server to perform the overall NDPS management 

of the system including automatically pushing down the print driver files. (The NDPS broker is not in the 

print path.) There are three services associated with the broker; by default, they are all enabled when you 

load BROKER.NLM. They can be individually disabled within the BROKER.NLM menu. The three 

services associated with the broker and their functions are: 

Event Notification Service (ENS) — This is the service that notifies users or administrators of events 

associated with the printing environment. For example, when a print job completes and user notification 

has been enabled, it is the ENS that informs the user the print job has finished. 

Resource Management Service (RMS) — This is the service that holds the print drivers, banner files, and 

Novell printer definition files (*.PDF) for each broker. This service is not “shared” among brokers; so, if 

you have two NDPS brokers on a segment and you want to add a printer driver to both, you must do it 

twice – once for each broker. 

Note: Do not disable the RMS. 

Service Registry Service (SRS) — This is the service that is required for public access printing . 

Note: Disable this service if you will not be using public access printers. This is a bandwidth-saving 

feature because if SRS is on, every broker registers with every other broker on the network. And, every 

printer agent is registered with every broker on the network. These services are registered (through SAP or 

SLP) when the NDPS Manager comes up and deregistered when the NDPS Manager goes down. 

Therefore, any time that you take down NDPS Manager, it deregisters itself with every broker running SRS 

on the network. In the worst case, this can hang the NDPS Manager “box” if there are WAN problems. 

SRS is the only component of NDPS that requires SAP or SLP, for finding Public Access Printers. 

(2) NDPS Manager 

The NDPS Manager (NDPSM.NLM) is loaded on NetWare 5.1 servers. This component is roughly 

equivalent to PSERVER.NLM in a QMS environment. The NDPS Manager is responsible for managing 

the printer agents with which it is associated. This is the piece of NDPS that is required for processing the 

print jobs from the clients and forwarding them to the printer agents on the network (NDPS Manager is in 

the print path). Clients resolve printing services through the NDS tree and their jobs are spooled to the 



NDPS Manager that manages that specific printer. The job is then sent from the NDPS Manager to the 

printer via TCP/IP. 

(3) NDPS Printer Agent 

With NDPS, printer and print queue functions are combined into a single entity called the Printer Agent 

(vs. having two separate NDS objects with QMS printing). There is a one-to-one correlation between 

physical printers on the network and the Printer Agent. Printer Agents eliminate the need to create print 

queues and allow users to send print job directly to printers. 

Note: Even though NDPS does not require print queues, your network may continue to include queuebased 

printers and clients not currently configured to support NDPS. The backward compatibility of NDPS 

allows you to continue using these queue-based services and resources transparently. Although NDPS can 

take jobs from a print queue, it does not use QMS; rather, it does spooling on the NetWare file system or 

can do the spooling local. 

NDPS-Embedded Printers 

The NDPS Manager communicates directly with the printer to process the print job. 

Note: As of January 2000, there are currently no NDPS-embedded (“native NDPS”) printers on the 

market. Novell is in the process of signing up partners to embed NDPS into their printers. If you can 

provide information on customer demand for NDPS-embedded printers, it would be a great help in our 

effort to get printer vendors committed. Some of the customer benifits that have been identified for 

NDPS-embedded printers are: 

• Ease of installation to the network. True plug-and-print functionality is available for NDPSembedded 

printers. 

• Improved printer bi-directionality and manageability. NDPS gateways provide different levels of 

bi-directionality and manageability to non-NDPS-embedded printers. 

• No unnecessary WAN/LAN traffic: 

• Print jobs (typically .5-3 MB in size) do not have to make a “pit stop” at a NetWare 5.1 server 

before going to the printer. For remote “satellite” offices without a NetWare 5.1 server, this 

means that the print job does not have to cross the WAN twice; in fact, the print job would 

never cross the WAN. 

• NDPS-embedded printers do not SAP. This delivers recovered bandwith in IPX installations. 

• NDPS-embedded printers report status and other information without polling. The 

WAN/LAN is only used when an event occurs. Some gateway solutions poll their printers to 

get this information. 

• No NetWare 5.1 server utilization impact. Interaction with the printer is between the client and 

the printer only. 

• High availability of printers. Because print jobs are sent directly to the printer without required 

NetWare 5.1 server involvement, printing on the network is possible even when the network is 

having problems. 

Non-NDPS-Embedded Printers 

For non-NDPS-embedded printers, the printer agent resides within NDS as an NDPS printer object. But 

because the printer hardware itself cannot natively process NDPS commands, a gateway component to 

NDPS is required (next). 



(4) NDPS Gateway 

Note: NDPS-embedded printers (when available) will not require the NDPS Gateway. 

Non-NDPS-embedded printers can be brought into the NDPS system through the use of gateways. NDPS 

ships with a generic gateway (Novell Printer Gateway); therefore, all printers can be used with NDPS. 

Printer vendors are working to deliver NDPS gateways to support their currently shipping printer product 

lines. The NDPS gateway software allows the NDPS infrastructure to communicate with non-NDPSembedded 

printers. The gateway software is loaded on NetWare 5.1 servers and its sole responsibility is to 

take NDPS formatted print jobs and reformat them in a language the printer can understand. NetWare 5.1 

comes with the following NDPS gateways on its installation CD: 

• Axis Gateway 

• EpsonNet NDPS Gateway 

• Extended Systems Gateway 

• Hewlett-Packard IP/IPX Printer Gateway 

• Kyocera NDPS Gateway 

• Lexmark IP Printer Gateway 

• Novell Printer Gateway 

• Tektronix Printer Gateway 

• Xerox Printer Gateway (IP/IPX) 

Note: It is to your advantage to use a vendor-supplied NDPS Gateway (if possible) versus the Novell 

Printer Gateway; this is because the Novell Printer Gateway is “generic” and, therefore, does not support 

all of the available NDPS features. 

The NDPS Gateways are NLMs that run on NetWare 5.1 servers. Until print server manufacturers start 

adding NDPS Printer Agents to their hardware, most customers will need to install an NDPS Gateway to 

get their printers to work in an NDPS environment. 

Subprocess 1—Designing and Implementing NDPS 

Note: Check for the latest NDPS 2.1.1 support pack at http://support.novell.com . 

Task 1—NDPS Design 

ENS 

Deliverable: 

NDPS Brokers 

RMS 

• A report detailing how NDPS will be designed. You can expand and complete the following table 

and include as part of the report. 

SRS 

NDPS Managers NDPS Printer 

Agents 

CAP PAP 

NDPS Gateways Comments 



The design of the NDPS environment needs to reflect the physical topology of the network as well as the 

distribution of the printers in the network environment. If there are printers distributed everywhere on the 

network, NDPS servers will also need to be widely distributed. 

NDPS Brokers 

• Install NDPS Broker software (BROKER.NLM) on at least one NetWare 5.1 server per physical 

location. This recommendation is because if the NDPS Manager needs the broker and it is not 

local, it will walk the NDS tree to find it, which can cause unnecessary traffic on WAN links. 

Additional brokers can be installed at each physical site for fault tolerance purposes; however, a 

maximum of two brokers per site is recommended for minimizing traffic. At a minimum, you 

should have at least two brokers per tree, at central points in the WAN infrastructure. Place 

LOAD BROKER.NLM in the AUTOEXEC.NCF file. 

• Determine which of the three services (i.e., ENS, RMS, SRS) need to be enabled on the brokers. 

As stated above you should never turn off RMS; ENS should be left on for notification purposes, 

and SRS should be disabled if you are not using Public Access Printers. 

NDPS Managers 

• Install NDPS Manager software (NDPSM.NLM) on at least one NetWare 5.1 server per physical 

site and, preferably, on the same server that is hosting BROKER.NLM. Installing the NDPS 

Manager software will autoload NDPSM.NLM; however, you must go back and manually add this 

line to the AUTOEXEC.NCF file. Also, if you create a Public Access printer before you create a 

Controlled Access printer, you must manually load NDPSM.NLM then put this statement in 

AUTOEXEC.NCF. –or– 

• Another option is to install NDPS Manager on each workgroup’s file server per physical site and 

control those workgroup’s printers. Rationale: No good reason for centralization; using NetWare 

Administrator you don’t need to know what file server the NDPS Manager is on; you don’t want 

one group’s file server to disable printing for another group. 

Server Requirements 

In a high-volume printing environment, NDPS servers (i.e., those running the NDPS Broker and NDPS 

Manager software) could experience a fairly high load. Extra care needs to be taken to make sure the NDPS 

servers have more than enough resources (RAM, CPU, etc.). This is especially true if mail, database, or 

other mission critical high load functions are also going to be running on that same server. 

Approximately 10-20KB of memory per NDPS printer is required after the first printer. A server running 

the NDPS Broker, Manager, and HP Gateway should expect less than 20% utilization for 100 printers. 

The NDPS environment has been tested with 600 NDPS printers being serviced by the same NDPS 

Manager. While this is not a recommended configuration for NDPS, it does prove the scalability of the 

NDPS technology. In an environment where hundreds of printers will be handled by a single NDPS server, 

Novell would recommend using a server dedicated to NDPS management. 



NDPS Printers 

• Determine whether the customer should use Controlled Access NDPS Printers or Public Access 

NDPS Printers. Discuss the advantages/disadvantages from this chart: 

Controlled Access NDPS printers Public Access NDPS printers 

Intended for large printing environments 

where control is wanted over who can print 

to what printers. 

Controlled Access NDPS printers have 

corresponding NDS objects. You browse 

through the tree structure to find them. 

The driver can be set up to automatically 

download to workstations by: 

• NDPS Remote Printer Manager Tab 

on the Controlled Access printer 

object. 

The drivers will install and the printer icon 

will appear in the printer folder. 

Another tab shows who can “see” the 

Controlled Access printer: 

If the driver is not set up to automatically 

download, you can manually install the 

printer driver with Microsoft’s Printer Wizard 

or the NWPM32 utility. 

Intended use was for “Mom and Pop” shops 

where everyone prints to all printers. The 

[Public] object is given all rights to Public Access 

printers. 

Public Access printers are not NDS objects. 

They are discovered via SAP or SLP. You can 

see a list of NDPS Public Access Printers within 

NWAdmn from “Tools, NDPS Public Access 

Printers.” 

The driver can be set up to automatically 

download to workstation by one of two methods: 

• NWAdmn32, Tools, NDPS Public Access 

Printers 

• NWPMW32.EXE 

The drivers will install and the printer icon will 

appear in the printer folder. 

If the driver is not set up to automatically 

download you will have to manually install the 

printer driver with the NWPMW32 utility. You 

cannot use the Microsoft Printer Wizard because 

a Public Access NDPS printer has no 

corresponding NDS object. 

• Create and configure NDPS Printer Agents – one to represent each NDPS printer. 

• Install printer drivers on NDPS workstations. 

The method of manually installing the print driver for a Public Access NDPS printer (or for a nonconfigured 

Controlled Access Printer) differs depending on if you are using the Microsoft Printer 

Wizard or the Novell Printer Manager (NWPMW32.EXE): 

• If you are using the Microsoft Printer Wizard, going through the network printer setup process 

will only create a port. You will then have to go back into the Microsoft Printer Wizard and 

create the print icon as if it were a local printer (you will need to manually install the print 

driver and select the now-installed NDPS port). 

• If you are using the Novell Printer Manager (NWPMW32.EXE), you will see a dialog box. 

You may modify the printer name that appears and select a pre-defined configuration. If the 

default driver is not the one you want, you can change it through the Configuration tabs. If 

you cannot find the appropriate driver, check the NetWare 5 .1documentation for details on 

how to add to the driver list. This utility is easier and the utility can be distributed with 

ZENworks. 

NDPS Gateways 

• Install and configure the appropriate NDPS Gateway(s), if you don’t have NDPS-embedded 

printers. 



SLP Considerations 

If you are using TCP/IP and are planning to use Public Access Printers, you must have an SLP 

infrastructure. This is because workstations use SLP to communicate with the broker’s SRS service in the 

following situations: 

• When browsing for public access NDPS printers to set up on the workstation 

• When the first print job is sent from a workstation to a public access printer 

• After a communications failure between a workstation and a public access printer 

• Printers use SLP to register with the SRS service 

NDS Considerations 

The NetWare 5.1 server running the NDPS Manager software should contain a replica of the partition in 

which the associated users and printer agents are located. This will allow for an efficient printing 

environment, as no tree walking will be required to resolve print services available on the network. 

Placement Example 

The following figure shows the distribution of NDPS brokers, managers, and gateways for a hypothetical 

network. This distribution should provide for the isolation of printing traffic on the network, which will 

make the performance of the WAN links the most efficient. 

NDPS Services 

BROKER.NLM 

NDPSM.NLM 

HPGATE.NLM 

Remote 

Site #1 

175 Printers 

Dedicated NDPS Server 

BROKER.NLM 

NDPSM.NLM 

HPGATE.NLM 

NDPS1 

10 Printers 25 Printers 

Task 2—NDPS Deployment 

Main Ring 



Remote 

Site #2 

RMT1_FS1 RMT2_FS1 

NDPS Services 

BROKER.NLM 

NDPSM.NLM 

HPGATE.NLM 

Once the first NetWare 5.1 servers are in place, the printing environment upgrade can begin. There are 

server and client factors to keep in mind while laying out the deployment schedule: 

Configuring NetWare 5.1 servers to support NDPS 2.1.1 

• Any server that is going to act as a NDPS 2.1.1 server will need to be upgraded to NetWare 5.1 

before NDPS 2.1.1 can be installed. 

• Any print server hardware that is not NDPS-aware but you want to print to it using TCP/IP, will 

need to be upgraded and/or replaced with new hardware that supports LPR/LPD printing.

Configuring NetWare clients to support NDPS 2.1.1 

• Each workstation should have the Novell Client that ships with NetWare 5.1 installed. The 

minimum client necessary to support NDPS 2.1.1 (including LPR/LPD and IPP) is ___________. 

• Configure the clients to support NDPS. If you select the Custom install option, make sure you 

choose the option to install NDPS. The NDPS components of the Novell Client require 

approximately 800 KB of RAM. 

• If the client needs to access NDPS public access printers, the workstation will need to access the 

SLP scope where that information resides. Depending on the SLP design, this may require 

additional configuration on the client. 

• Install NDPS printers in any of the following ways: 

Automatic Printer Installation 

While NDPS allows users to download and install printers on their workstations, it also allows 

administrators to designate printers to be downloaded and installed automatically. These printers then 

appear on the user’s installed printers list with no action required by the user. 

You can designate a printer to be installed automatically by using the Remote Printer Management feature 

in NetWare Administrator. Here is how Remote Printer Management works: 

• After a printer has been designated for automatic installation on a user's workstation, this 

information is stored on the NDSTM container object where the administrator has configured it. 

• When a user logs in after the machine is rebooted, the workstation's client software checks the 

container object where the User object resides for the Remote Printer Management configuration. 

• The client software compares "time stamps" stored on the workstation and in NDS to determine 

whether any changes have occurred. 

• If the time stamp is different, action is taken, and the printer list on the client is automatically 

updated to match the printer list maintained by NDS on the container. 

• If the client finds a printer designated for installation that has not yet been installed, it is 

automatically installed. 

• If a currently installed printer is added to the Printers to Remove list, that printer will be 

uninstalled automatically. 

• If you designate a different printer to be the default in the Remote Printer Management list, the 

change will be automatically made on each client when it logs in. 

• If the "Do not update workstations” control is checked, you can update the Remote Printer 

Management configuration, but no changes will occur on the workstation. 

Here are some issues to keep in mind when using Remote Printer Management: 

• A log file named dprpmlog.txt is created in the drive:/windows directory of each workstation 

where Remote Printer Management has installed one or more printers. This log file is limited to 5 

KB and can be turned off in the Windows Registry. (Type regedit, then select 

HK_KEY_LOCAL_MACHINE/SOFTWARE/NDPS/RPM and set the error log setting to 0 to 

disable it.) You can only do this after you have used the Remote Printer Management tool. 

• When you install a printer using Remote Printer Management or the Novell Printer Manager, its 

installed name will be limited to no more than 31 characters (including the periods). The name 

will be broken off at a logical point from the beginning of the installed name. This will not affect 

the ability of the printer to service jobs. 



The reason that names are limited to this length is that some applications cannot handle printer names of 

over 31 characters. 

Remote Printer Management can be accessed in any of the following ways. Somewhat different 

functionality is available at each location. 

• From the Tools menu in NetWare Administrator. By selecting the NDPS Remote Printer 

Management option from this menu, you can manage printers in all containers to which you have 

Supervisor rights on the container object. 

• From the Details page for the Container object. By pressing the NDPS Remote Printer 

Management button from this page, you can manage printers for this container only. 

• From the Details page for a specific printer. By pressing the NDPS Remote Printer Management 

button from this page, you can remotely manage that printer. 

• From the Public Access Printers view under the Tools menu. By highlighting a printer and 

selecting the Object/Details option, you can access the Printer Control page for that printer. Then, 

by pressing the NDPS Remote Printer Management button from this page, you can remotely 

manage that printer. 

Manual Printer Installation 

The are two methods for manually installing an NDPS printer on a workstation: 

• For Win95/98/NT4 workstations, the user can use the Windows Add Printers wizard in the 

Windows Printers folder to install NDPS printers. 

• The user can install the NDPS printer through use of the Novell Printer Manager utility. 

To run the Novell Print Manager, do the following: 

• For a Win3.x workstation, run SYS:PUBLIC\NWPMW16.EXE 

• For a Win95/98/NT workstation, run SYS:PUBLIC\WIN32\NWPMW32.EXE 

Once you are in the Printer Manager utility (or in the Print Wizard), you can browse for the appropriate 

NDPS public access or controlled access printers. 

The method of manually installing the print driver for a Public Access NDPS printer (or for a nonconfigured 

controlled access printer) differs depending on if you are using the Print Wizard or the Printer 

Manager: 

• If you are using the Print Wizard, going through the network printer setup process will only create 

a port. You will then have to go back into the Print Wizard and create the print icon as if it were a 

local printer (you will need to manually install the print driver and select the now-installed NDPS 

port). 

• If you are using the Printer Manager, you will see a dialog box. You may modify the printer name 

that appears and select a pre-defined configuration. If the default driver is not the one you want, 

you can change it through the Configuration tabs. If you cannot find the appropriate driver, check 

the NetWare 5.1 documentation for details on how to add to the driver list. 

• By allowing workstation users to install printers on their workstations by using the Novell 

Printer Manager. 

• By allowing Win95 and WinNT workstation users to install printers on their workstation with 

the Windows Add Printers wizard in the Windows Printers folder. 



Note: Certain print drivers (mostly older drivers) will not work when the printer name/port name 

has a long name (32 characters or more). The port name looks something like 

\TREE_NAME\SERVER_NAME\installed printer name. To resolve this problem for NDPS, a 

new flag has been added to the registry for Windows 95 and Windows NT that will allow for 

printer names to be less than 31 characters in length so that old applications can still print. The key 

is as follows: 

HKEY_LOCAL_MACHINE\Software\NDPS\RPM\TruncatePrinterNames 

0 = use long names 

1 = truncate the printer names 

Enabling NDPS on a Previously Installed Client 

It is possible to install the correct version of the Novell Client without enabling NDPS. To enable NDPS at 

a later time, you can do so by adding the service through the Network Neighborhood properties. Some 

points to consider: 

• You will need the Novell Client CD-ROM, or access to whatever storage media you have placed 

the current Novell client. 

• On Windows 3.x workstations, you must reinstall the Client to enable NDPS. 

SAA Host Print to an NDPS Printer 

This is possible following these steps: 

• Associate a Host Print printer with an NDS or Bindery queue 

• Configure the NDPS printer to service this NDS or Bindery queue 

Steps to configure NDPS printer to services bindery queues are: 

• Select details on the NDPS Printer object you want to print to 

• Select the Jobs button 

• Select Spooling Configuration 

• Select Service Jobs from NetWare Queues 

• Select the Add button and select the appropriate queue for your host print session 

Removing Old Legacy Dependencies 

Once NDPS has been setup on all appropriate workstations, the last step is to cleanup the old legacy 

printing environment. It would be a good idea to wait until your new NDPS system has been tested 

thoroughly before removing these dependencies. 

Removing the legacy print queues and related NDS objects is easy to do through NetWare Administrator, 

but the following actions should be kept in mind: 

• The appropriate print servers (such as HP JetDirects) must be reconfigured to no longer attempt to 

service the legacy print queues. 

• Many workstation Operating Systems allow the users to establish persistent network connections 

such as drive mappings and printer connections. If the legacy print queues are removed without 

first cleaning up these workstation connections, users will see error messages. 



• Existing CAPTURE commands should be removed. These statements might exist in container or 

user login scripts, in the bindery login script (SYS:PUBLIC/NET$LOG.DAT), in batch files, or 

other locations. If the legacy print queues are removed without first removing the CAPTURE 

commands, users will see error messages. 



Subprocess 2—Implementing Internet Printing 

Protocol (IPP) 

IPP is a new printing protocol that makes it possible to send print jobs to printers on intranets or on the 

Internet in the same way you send print jobs to a printer on your desk. IPP is growing to become a 

standards-based version of NDPS. 

IPP Requirements 

Novell’s implementation of the Internet Printing Protocol allows users running IPP clients to send print 

jobs addressed to a URL. The IPPServer runing on the Novell Server, where the NDPS Printer Agent that is 

setup to receive the URL, converts the http data stream and sends the information to the NDPS Printer 

Agent. 

Requirements for IPP: 

• Netscape Enterprise Server for NetWare 

• Follow the instructions found in server\SYS:SYSTEM\IPP\NDPSIPP.TXT 

• Enable IPP on an NDPS Printer Agent 

• Clients that want to print to IPP printers need an IPP client 

The following is a screen shot of a IPP-enabled NDPS Printer Agent. The IPP URL field is the URL that 

the IPP client software would need to print to the NDPS Printer Agent. 



To use IPP, you need: 

• an IPP client 

• an IPP printer (or print server) 

both of which must have the HTTP 1.1 stack (which is what IPP 1.0 uses). 

The IPP client encodes requests, uses HTTP 1.1 to send these requests across the wire, and decodes 

responses from IPP printers. For a printer to receive and understand print requests from IPP clients, it needs 

IPP server software, either embedded on the printer itself or running on the print server. The IPP server 

software decodes the IPP client requests it receives, translates those requests into a language the printer can 

understand, and encodes any responses from the printer back into a language the IPP client can understand. 

With IPP client software running on users’ desktops, users can install the IPP printers on the desktops to 

which they want to print. When users with IPP client software first install IPP printers on their desktops, 

they also need to install the appropriate printer driver, just as they would to install any printer. Users must 

also specify the printer’s URL. Users then can make the IPP printer their default printer (which may be 

preferable on an intranet), or they can choose the printer each time they print. 

IPP Clients 

IPP client software for both Windows and UNIX platforms is available from several vendors, including: 



• Hewlett-Packard 

• Microsoft 

For more information about IPP on Windows 95, see 

http://www.microsoft.com/Windows95/downloads/contents/WUPreviews/IPP/Default.asp 

For more information about IPP on Windows 98, see 

http://www.microsoft.com/Windows98/downloads/contents/WUPreviews/IPP/Default.asp 

• ShineSoft 

• Easy Software Products 

Easy Software Products has had IPP client software available for about nine months as part of its 

Common UNIX Printing System (CUPS). CUPS replaces the System V and Berkeley print 

systems included in most versions of UNIX with a compatible IPP-based printing system. CUPS 

also uses Adobe PostScript Printer Description (PPD) files and a MIME-type filter database that 

together enable you to print to PostScript printers--and use all of their capabilities--just by 

grabbing the appropriate PPD file. For more information about CUPS, visit http://www.cups.org. 

Easy Software Products also provides ESP Print Pro software, which is based on CUPS and 

includes drivers for more than 1600 PostScript and non-PostScript printers. (For more 

information, visit http://www.easysw.com/printpro. ) 

• Apple Computer has also announced plans to support IPP in future versions of the Macintosh 

operating system. 

For an updated list of IPP client software and other IPP products, visit ftp://ftp.pwg.org/pub/pwg/ipp and 

open the Products folder. 

IPP Printers and Print Servers 

Printers with embedded IPP software are available from Lexmark and Xerox. Small print servers that can 

accept IPP requests for jobs intended for specific printers are available from Hewlett-Packard, i-data, and 

Tally. Large print servers, such as the NDPS IPP server, that can accept IPP requests are also available. 

NDPS IPP Server 

The NDPS IPP server supports IPP 1.0, as described in the IETF Requests for Comments (RFCs) numbers 

2565 through 2569 and 2639. You can download these RFCs by visiting 

http://www.pwg.org/ipp/index.html and clicking the hypertext links to those documents. IPP 1.0 describes 

how IPP clients can submit jobs to IPP printers and find out about IPP printers’ capabilities and status. 

NDPS also supports IPP Optional Operations--Set 1, which is described in the IPP/1.1 IETF Internet-Draft. 

You can view this document at http://www.ietf.org/internet-drafts/draft-ietf-ipp-model-v11-04.txt. As the 

name suggests, these IPP Optional Operations describe additional operations (such as hold job, restart job, 

pause printer, and resume printer) that vendors have the option to include in their implementation of IPP. 

The NDPS IPP server sits in front of NDPS Printer Agents, translating requests from IPP clients into a 

language NDPS Printer Agents can understand and coding responses from NDPS Printer Agents into a 

language that IPP clients can understand. The result is that any IPP client can print to any NDPS printer, 

assuming, of course, that there are printer drivers available for the printers to which the IPP client wants to 

print. 



Subprocess 3—Implementing Line Printer/Line Printer 

Daemon (LPR/LPD) 

The LPR/LPD server is an NLM that is automatically loaded when you use the NWADMIN utility to 

configure a Printer Agent to support LPR/LPD. To configure a Printer Agent to support LPR/LPD, you 

complete three simple steps: 

• Using the NWADMIN utility, double click to open the NDPS Printer object (also known as a 

controlled access printer) or Public Access Printer that represents the physical printer for which 

you want to enable LPR/LPD support. 

• Click the “Enterprise NDPS LPR/LPD Support” button. 

• Click “Enable LPR/LPD services for this printer.” 

By configuring the Printer Agent to support LPR/LPD, you enable any system that can submit jobs via the 

LPR/LPD standard to print directly to the NDPS printer that this Printer Agent supports. UNIX, 

Macintosh, and even some mainframes support LPR/LPD. Clients that need to connect to the NDPS Printer 

Agent that is acting as LPR/LPD printer need the IP address or the DNS name of the server running the 

NDPS Manager process where the NDPS Print Agent is defined, as well as the leaf object name of the 

NDPS Printer Agent. 

Unix 

By default UNIX workstations print using LPR/LPD. After you have enabled a Printer Agent to accept 

LPR/LPD print jobs, the UNIX users need only load the correct driver on their workstations to send jobs to 

this printer. 

Macintosh 

You can configure Macintosh workstations to print to NDPS printers by changing the desktop default 

settings from printing via AppleTalk to printing using LPR/LPD. You can configure Macintosh 

workstations to print using LPR/LPD when you create new printers to represent the NDPS printers to 

which the Macintosh users will print. 

For more information about configuring Macintosh workstations to print using LPR/LPD, see “How Do 

You Get From Mac to NDPS? [No Queues Please!]” available at http://www.nwconnection.com. 

Mainframes 

You can configure many mainframes to print to NDPS printers using LPR/LPD via TCP/IP services. For 

example, to configure systems running Open Virtual Memory System (OpenVMS) to print via LPR/LPD, 

you can use a product such as Compaq’s Digital TCP/IP Services for OpenVMS software. For more 

information, see http://www.openvms.digital.com:8000/72final/6525/6525profile_015.html#print_chap . 

To configure IBM systems running the Virtual Storage Extended (VSE) operating system (such as IBM 

4381s and IBM 9870s) to print via LPR/LPD, you can use a product such as Connectivity Systems’ TCP/IP 

for VSE. For more information, see http://www.tcpip4vse.com/concept.htm . 

To configure IBM systems running Multiple Virtual Storage (MVS) operating system and systems running 

Virtual Machine (VM) operating system to print via LPR/LPD, you can use IBM’s TCP/IP services for 

those operating systems. For more information, see 

http://www.redbooks.ibm.com/abstracts/gg243376.html . 



Caveats 

The above non-Windows users do not get all of the advantages that Windows users do because there is no 

NDPS client software for non-Windows platforms. So, the good news for UNIX, Macintosh, and 

mainframe users is they don’t have to install any software to be able to print directly to NDPS printers. 

However, the “bad” news is that because they haven’t installed any software, they don’t have the NDPS 

benefit of automatically loading drivers. Additionally, you cannot notify non-Windows clients of a 

printer’s characteristics or of a print job’s status. 

In other words, the value in supporting UNIX, Macintosh, and mainframe clients (through the LPR/LPD 

server) is not to the end user but rather to the network administrator. 

IPP versus LPR/LPD 

For UNIX and Macintosh users, IPP offers much richer features than those offered by LPR/LPD. For 

example, using the NDPS IPP server, IPP clients on an NDPS network can discover the capabilities of an 

NDPS printer, such as the printer’s speed or whether or not the printer supports color. IPP clients on an 

NDPS network can also collect information about a print job (such as whether or not the job has been 

completed or was cancelled) after it is sent to an NDPS printer. In other words, the level of information that 

UNIX and Macintosh users can get using IPP is “orders of magnitude above” the information they can get 

using LPR/LPD. 

UNIX, Macintosh, and Windows users with IPP client software can also print to an NDPS printer via the 

NDPS IPP server without having to log in to the network. However, you can still control which users are 

able to print to printers for which you have configured NDPS to allow IPP services. Because users can print 

to NDPS printers without having to log in to the network, users can finish up a document from a home 

computer or a laptop that is not running NDPS client software and send this document to the printer on 

their desk at work. 



Subprocess 4—QMS to NDPS Migration 

The upgrade from QMS to NDPS is a two-step process: 

(1) Back-end Upgrade. Take one print server and create an NDPS printer for each printer it services. 

• Use the appropriate NDPS printer gateway 

• Configure NDPS to service QMS queues 

• UNLOAD PSERVER.NLM 

• LOAD NDPSM.NLM 

At this point, the backend is NDPS and nothing has been done to the clients yet. 

(2) Front-end Upgrade. Client upgrades. 

• If latest Novell Client (Version ____) is already installed, just need to create the NDPS printers 

using one of the methods described above. 

• Delete Pserver and Printer objects (non-NDPS). 

• Can delete old print queues because NetWare 5.1 (NDPS 2.1.1) supports DOS box printing 

(NetWare 5.0/NDPS 2.0 does not). 

Subprocess 5—Troubleshooting / Real World Issues 

• NDPS relies upon STREAMS, CLIB, and TLI; therefore, check to see if the NDPS servers are 

running the latest of these NLMs. 

• NWAdmin is used to troubleshoot printing problems; future will be NetWare Portal Manager. 

Working to enable it with ConsoleOne (hopefully a demo at BrainShare 2000). 

• Debugging tool console command: NDPS Manager. Typing this alone gives you the list of 

available switches. Once you type NDPS Manager you are switched to that screen 

where you can type “o” for options. 

Subprocess 6—Create the NDPS Report 

Document for the customer how to implement NDPS. 

Subprocess 7—Review and Deliver NDPS Report to 

Customer 


The project manager should review your NDPS report and make any recommendations or suggestions. 

Activity 2—Deliver NDPS Report 

Deliver NDPS report to the customer. 





Integrating Office 2000 with NetWare 5.1 

This section will help you integrate Microsoft Office 2000 applications and Web Folders in a NetWare 5.1 

environment using the protocol WebDAV. 

Introduction 

WebDAV allows users and administrators the ability to use new methods of collaborating and sharing of 

resources on a network, Intranet or the Internet, using Microsoft Office 2000 and Web folders. The 

NetWare 5.1 file system has been written to allow every document and directory to have a URL associated 

with it, to support the access of files and folders through the use of a web browser. Through the use of the 

WebDAV protocol and NetWare 5.1 users and administrators can collaborate on documents via traditional 

means (e.g., shared network drives on a NetWare server) as well as through the web. WebDAV takes 

advantage of the new features incorporated into Office 2000, such as Web Folders and “Save as Web 

Page.” WebDAV allows users to access documents through the Internet and open, edit and save a 

document in its originally created application, e.g. Word, Excel. This functionality allows for easier 

document collaboration. For example, instead of emailing a document to another user, you simply send a 

URL. The recipient clicks on the URL from the email and opens the document from its original location, 

makes changes, and saves it. The document never leaves its original location and is opened in the 

authoring application. 

It is NetWare 5.1 that “extends” the file system to allow documents and directories the ability to have 

URLs associated with them. It is the WebDAV protocol that allows access to the URLs through a browser. 

The presence of a “client” has always been a requirement for modifying and manipulating files on a server. 

The need for a client-based login to servers in order to view, edit and save data files has been replaced by 

WebDAV, or Web-based DAV (Distributed Authoring and Versioning.) WebDAV is the beginning of the 

completion of the Internet’s vision of a collaborative network of resources. The vision of the WebDAV 

creators is to be able to access a resource from anywhere without having a specific client and be able to 

open, edit, and save a document using the application the document was created in. 

What is WebDAV? 

WebDAV is a protocol (RFC 2518) that extends HTTP 1.1 to provide a standards-based infrastructure for 

asynchronous collaborative authoring using the Internet as the backbone, as if the documents were on the 

local workstation. The WebDAV extensions support the use of HTTP for interoperable publishing of a 

variety of content, providing a common interface to many types of repositories and making the Web 

analogous to a large-grain, network-accessible file system 1 . 

The WebDAV protocol has been accepted as an industry standard and potentially there will be widespread 

support for it in more and more applications. Novell and Microsoft are just a couple of the first to support 

WebDAV interoperability with the file system and document authoring applications. Note that other 

applications may have the WebDAV capability in the future; therefore, WebDAV may have benefits 

beyond Office 2000. 

WebDAV Benefits 

WebDAV uses a Web browser as the client instead of the traditional method of client connectivity. By 

simply using a browser like Microsoft Internet Explorer 5.0 or any HTTP browser that supports the 

1 WebDAV: IETF Standard for Collaborative Authoring on the Web. E. James Whitehead, Jr. p.1 



WebDAV protocol, one can access files and folders located on the network file system. The browser-based 

connection is then authenticated, if required, for a particular location and user rights are applied to the file 

system. WebDAV being a protocol and not a specific client brings many benefits to the network-computing 

world. Some of the features of Novell’s implementation are: 

• WebDAV is a protocol (see the RFC and footnote reference at the end of this section) 

• No client required 

• Authenticated and encrypted access using SSL, by default 

• Access control through NDS 

• Every document and directory has a URL 

• Will force users to log in, if required 

• Support for ease of web page authoring and modification 

To share documents with WebDAV, you will only have to e-mail a URL in order for a person to access a 

document. Document sharing can be accomplished through the use of Web folders instead of through the 

sending of e-mail attachments. By not having to send a changed or “versioned” document through e-mail 

repeatedly to other team members, collaboration is more fully realized and there are not different versions 

of the same document floating around. Instead documents are instantly accessible to a workgroup from one 

location through a browser. 

WebDAV extends HTTP to allow six capabilities, three of which are fully implemented and are discussed 

below: 

• Overwrite prevention 

• Properties 

• Name space management 

The other three extensions: 

• Version management 

• Advanced collections 

• Access control 

are scheduled for completion in the fall of 2000. However, Novell uses NDS for access control and does 

not fully support version management and advanced collections at this time. 

Overwrite Prevention 

WebDAV has overwrite prevention or “locking” to overcome the “lost update problem.” WebDAV 

provides an exclusive write lock, which guarantees that only the lock owner can overwrite a locked 

resource. These locks are applied when a user accesses and opens a document; in essence a copy of the 

document is opened on the local workstation allowing the document on the server to be locked. Once the 

document is closed on the server the lock is released and the next person can have full access to the file. If 

a person accesses an already locked file, that person is notified by the usual message “someone else has this 

file in use, would you like to make a copy?” The user answers yes and they have a locally loaded copy in 

read-only mode. 

Properties (metadata) 

All published information on the Web has additional pieces of information associated to it, such as title, 

subject, creator, publisher, length and creation date. These properties of the information as WebDAV 



knows them are also known as metadata. The use of metadata in, for example, a search will allow a search 

to be more specific, because the specifics about a document are stored in the metadata, this will allow a 

search to be able to focus on particular properties of information, i.e. Author = “John Doe” therefore 

allowing searches to be faster and retrieve more relevant results. 

Name Space Management 

Name space management is the ability to conveniently manage Internet files and directories, to include the 

ability to move and copy files. This also allows the creation of directories and the organization of files in 

directories, much like a word processing application does to documents and directories. 

Additional Resources on WebDAV 

• 

• 

http://www.ics.uci.edu/pub/ietf/webdav (IETF Working group Website) 

http://www.excosoft.se/dev/webdav/slides/ppframe.htm (Introduction to WebDAV) 

What are Web Folders? 

Microsoft Office 2000 installs an Icon in “My Computer” and extends Windows Explorer to include a new 

type of folder called a “Web Folder.” Web folders are setup using the Add Web Folder wizard, once the 

initial installation of Web folders is complete they are available for use with the WebDAV protocol through 

Internet Explorer 5.0. 

A Web folders button is available in all Microsoft Office 2000 applications and allows documents to be 

saved to Web folders locations. Once Office 2000 is installed, dialogs are available through the standard 

File, Save, then choose “Web Folders” on the bottom left of the dialog box. Also this makes it easy for 

Web Page administrators to update changes to content and save it to a Web location, without having to be 

an FTP and Namespace expert. 

Subprocess 1—How to Integrate NetWare 5.1 and 

Office 2000 

Requirements 

One NetWare 5.1 server running: 

• The NetWare Enterprise Web Server (which installs by default with NetWare 5.1) 

• WebDAV.NLM(which loads by default with the Enterprise Web Server) 

Provides support for WebDAV 

• Office 2000 running on workstations 

Extends “My Computer” to allow Web folders functionality 

• Internet Explorer 5.0 running on workstations 

Note: Internet Explorer 4.0 and Netscape’s browsers do not support the WebDAV protocol and 

they do not support Web Folders. However, the WebDAV.NLM does provide some administrative 

functionality that uses the standard HTTP protocol without the WebDAV enhancements. 



• NDS 7 or NDS 8 – However, the WebDAV.NLM uses features of NetWare 5.1 that are not 

present in prior versions, this is not NDS related, but a dependency of NetWare 5.1. 

• NICI 1.3.1 Novell International Cryptographic Infrastructure 

• NICIU0 1.3.1 NICI U.S./Canada (128bit) Cryptographic Engine XENG 

• PKIS 2.0.1 Novell Certificate Server v2.01 

• SAS 1.4.0 Secure Authentication Services 

• SPACK 5.0.4 v4.0 Support Pack for NetWare 5 

• TCP/IP running on NetWare 5.1/Enterprise Web Server 

• DNS running (ideal): if not, the name of the NetWare 5.1/Enterprise Web server must be in its 

SYS:ETC\HOSTS file and client hosts file also. 

• Optional: LDAP is a nicety in that you can do LDAP queries to the server (vs. using a browser). 

LDAP is not a requirement 

• Optional: NDS-DAV (discussed later) 

• Optional: 256 MB of RAM on the NetWare 5.1/Enterprise Web Server to use the WebBench tune 

feature for optimal performance of the Web server. 

Note: The Novonyx group recommends this. This greatly increases the available cache size for 

keeping static pages & images. There are also going to be additional instructions in the README 

concerning the optimal settings for running WebBench tests, etc. 

Subprocess 2—Creating Web Folders 

2 

Web Folders install as a namespace (or shell) extension with an icon in My Computer (root object in 

Windows Explorer). This root object is a container for shortcuts to your Web publishing sites. You can use 

Windows Explorer to view, move, copy, rename, delete, create new, sort/group files by properties, and 

view property sheet information for files in a Web Folder depending on your authoring and security 

permissions on the Web server. 

The namespace extension observes the viewing preferences you set in the Folder Options dialog box in 

Windows Explorer. If you choose not to view files with registered system extensions (for example, .dll, 

.drv, .pnf, etc.), files in a Web Folder with one of these extensions are not shown. 

NOTE: Files that generate a Hypertext Markup Language (HTML) view of the folder (for example, scripts 

with a .asp or .cgi extension), and other files that may not be intended to be edited by users (for example, 

executable files with a .exe or .dll extension), may appear in the Web Folders view of a folder. 

Administrators may want to use file system permissions or some other method to prevent editing of these 

files by users 2 . 

Creating Web Folders 

To create a Web Folder, use one of the following methods: 

Method 1: 

In Internet Explorer, click Open on the File menu. 

http://support.microsoft.com/support/kb/articles/Q195/8/51.ASP ) 



3 

In the Open box, type http://server name/folder name, where server name is the name of the appropriate 

server and folder name is the name of the appropriate folder. 

Click the Open As Web Folder check box to select it, and then click OK. 

Method 2: 

In My Computer, double-click Web Folders, and then double-click Add Web Folder. 

In the Type the Location to Add box, type http://server name/folder name, where server name is the 

name of the appropriate server, and folder name is the name of the appropriate folder. And then click Next. 

Type a descriptive name for your Web Folder shortcut, and then click Finish 3 . 

Once Microsoft Office 2000 is installed access My Computer, there you will notice the Web Folders icon. 




Double click the Web folder and it should install the Web folder functionality, this happens only the initial 

time, then a Web folder dialog box is displayed, view Figure below. 

Next, type the location of the server you wish to access folders from and be sure to use an https:// secure 

connection URL to attach to the NetWare 5.1 server, since SSL is installed by default. If you do not know a 

specific location choose the browse button and Internet Explorer (IE) 5.0 will open. This will allow you to 

type the server name either ( http://servername or IP address) or ( https://servername/ or IP address) location 

and the default, or index.html page, will open. See illustration below. 



Once the location is determined through IE 5.0, close the browser and the location is added to the URL 

path, then choose next. A login dialog box appears, see Figure below, asking for username and password 

this is the users NDS username and password. Note: the password is not sent in clear text across the wire, 

because by default SSL is enabled. 



The request is granted if the location is valid and an “Enter the name of this Web Folder:” dialog box 

appears. Enter a name that is descriptive because this is the name that is displayed in the Web Folders, i.e. 

Homedir, then choose Finish. A Web Folder is created in the Web Folders namespace (or shell.) Once the 

resource has been accessed and authenticated with a valid username and password, access to the resource is 

granted without a request to login again, see figure below. 



However, if a different location is accessed, or the user logs out, then a login dialog box will appear. 

Subprocess 3—Accessing Documents and Web 

Folders 

Features of using WebDAV integration with Microsoft Office 2000 are numerous. Great care has been 

taken to make the protocol application-friendly. Existing applications can easily add WebDAV support 

because the protocol is compatible with the common "open, edit and save" style of most applications. This 

feature extends to the Microsoft Office 2000 suite of applications. For example, to save a document to a 

Web folder from within Word or Excel, you simply choose, File, Save and select the Web Folders Icon at 

the bottom of the left hand “Save in:” dialog box. Once the document is saved in a Web folder it is 

available through the WebDAV protocol and accessible to others for collaboration through a web browser, 

given proper rights have been granted. 

Subprocess 4—WebDAV and Home Directory 

(~homedir) 

One of the most requested features customers have asked for is the ~homedir feature. The ~homedir 

feature is similar to a Unix based Web Server’s personal web space feature, in that a user can type 

~username and access their home directory from anywhere on a system. This feature was incorporated into 

previous versions of the NetWare Web Server, but was not available using the Netscape Enterprise Web 

Server. This functionality has been incorporated into the NetWare Enterprise Web Server and utilizes 

Office 2000 Web folder integration. WebDAV provides this functionality through the use of a user’s home 

directory and a public_html subdirectory acting as a pointer for the WebDAV protocol. 



It is required to setup the users home directory in either NWAdmin, ConsoleOne (or through a browser 

using WebDAV, if NDSDAV is enabled.) The users home directory can be either on the server the Web 

Server is on, or a remote server, as long as the properties of the users home directory point to the 

Server_Volume: and the full path of the location, See Figure below. Once a user’s home directory is setup 

and the appropriate directory created, create a public_html subdirectory within the user's directory. There 

needs to be at least one file in this directory, it works best for now if a file is placed here. Support Pack 1 

will hopefully correct this. The user’s home directory can be located anywhere the administrator wishes, as 

long as the home directory attribute of a user points to that location, and under that particular user there is a 

public_html directory with at least one file in it, as mentioned before. The public_html directory is what 

WebDAV uses to locate the https://servername/~homedirectory , for example the admin’s Homedir is 

https://notebook/~admin which corresponds to 

Notebook/sys:novonyx\suitespot\docs\users\admin\public_html if the users home directory is in the Web 

Servers root directory. 

If NDSDAV is enabled the user home directory can be modified through a browser. View the Figure 

below. Note: This can also be done through the Web Servers Admin server and it would look much the 

same as the figure below. 

Notice that the location of the user’s home directory has different path, and is located on the SYS volume 

of the Notebook server instead of the document root of the web server. Since the user’s home directory 

points to that location the admin user can access his Homedir with the same URLs mentioned above, either 

the https://Servername/~admin or https://IPAddress/~admin . 



Subprocess 5—Using NDSDAV 

NDSDAV is Novell’s interesting and novel use of the WebDAV protocol. NDSDAV is also Novell’s way 

of exposing NDS functionality to the WebDAV protocol. 

What is NDSDAV? 

NDSDAV takes the NDS directory and makes it available to the WebDAV protocol. Normally WebDAV 

accesses the file system and not the directory, but NDSDAV accesses the directory in much the same way 

that WebDAV accesses the file system. NDSDAV NDS objects are only visible through the “My 

Network” virtual directory. The “My Network” directory exists in the document root of the Web Server and 

allows a WebDAV user access to NDS objects from their browser. The NDSDAV objects attributes can be 

modified from the browser as well by double clicking the object or right clicking and choosing attributes. 

Changes to the NDS rights and properties can also be accomplished through a browser as well. For 

example, to make a user a trustee of a folder using WebDAV and NDSDAV a document author need only 

to drag another user on top of the folder for which he needs trustee rights and the user is not copied to the 

folder, but is assigned rights to that folder, based on what WebDAV knows of user and folder objects. 

Properties of NDSDAV 

If NDSDAV is enabled an administrator has access to NDS resources, and has the ability to administer 

most attributes of users, groups and organizational units objects. With NDSDAV enabled an administrator 



can add users, modify their rights, change passwords, delete users, create Organizational Units, assign 

trustee rights, modify home directory locations and other common NWAdmin functions. Compared to 

NWAdmin, NDSDAV does not provide all the same functionality, but it does allow an administrator the 

ability too, on the fly, assign trustee rights to an object or folder. Also, NDSDAV allows a document 

creator the ability to assign rights to their documents, using drag and drop. By granting a user the ability to 

assign trustees to their own files and folders extends the ability for that users to share with others and 

collaborate on projects, freeing the administrator to focus on other tasks. 

The Readme.htm document contents are listed below, giving a very good explanation of what each folder’s 

function is and how they are used. 

My Network Folder 

The My Network folder provides a central location on your NetWare server from which you can get to the 

rest of the network resources that you use. Unlike the Network Neighborhood folder seen in Windows that 

exists on the workstation, this folder virtually exists on your NetWare server instead of your workstation; it 

is simply a pointer for when NDSDAV is enabled. This folder is also accessed via industry standard web 

protocols. Because of these special qualities, you can access the My Network folder from any Windows 

workstation that is attached to the public Internet - anywhere in the world. 

Within the My Network folder, you will find your personalized version of the following items: 

Mapped Drive Web Folders 

If your network administrator has set up mapped network drives for you that are normally visible at the 

client, you will be able to see those same directories as web folders within the My Network folder. This 



will allow you to access your corporate applications and data remotely without the need for a Novell client 

on your workstation. 

Please note that Windows and DOS applications that require traditional drive mappings will not of course 

work in this environment. 

Personal Web Publishing Folder 

When your login account was created on your Novell network, your network administrator will normally 

have created a home directory (user directory) for you out on the network. If your network administrator 

has enabled the User Home Directories feature, your My Network folder will contain a link to your 

personal web publishing directory. 

For example, if your home directory is on file://MyServer/Data/Users/Bob , then your personal web 

publishing folder will be called ~BOB and will actually contain all the HTML files that you publish into the 

file://MyServer/Data/Users/Bob/public_html subdirectory. 

Please note that you can control who can access your web publishing folders by dragging and dropping 

users and groups from your NDS directory web folders onto those folders. 

My Directory Tree Web Folder 

This folder allows you to see the contents of your Novell Directory Services tree. In particular, you can see 

all the users and groups that have been defined within your network. To view the properties of any object 

that you can see within the tree, double click its icon within the web folder. 

Note that your network administrator will likely allow you to only modify the properties of your own user 

object and modify rights for your personal web publishing folders. The rights to other users, groups and 

web folders are controlled by the network administrator. 

My Organizational Unit Web Folder 

Your organizational unit web folder contains users that represent all of your colleagues in your department 

as well as any groups of users that your network administrator may have defined. The users and groups you 

find within this folder will also include the special users [public] and [private]. 

Use the users and groups within this web folder to modify the access rights on your web folders or any 

other areas in which the network administrator has given you access control rights. 

Setting up NDSDAV 

To enable NDSDAV change, NDSDAV:False (default) to NDSDAV:True in the webdav.conf file located 

\\Server\Volume\Novonyx\Suitespot\bin\webdav\html\ directory on the server running the NetWare 

Enterprise Web Server. Turning NDSDAV On gives the network the ability to see the “My Network” 

folder and use it as an NDS portal to objects in the tree. 

The “My Network” folder is located in the web servers primary document root directory, by default the 

\\servername\volume\novonyx\suitespot\docs on the physical web server. This is a placeholder for all NDS 

objects. View Figure ? Below. 



Note: the URL http[s]//hostname/~username is a basic Web Server function that works with normal web 

access and the WebDAV protocol, and accesses the username/public_html directory. However, 

http[s]//hostname/My Network/~fullndsname is a feature of NDSDAV and accesses the user’s home 

directory and not the public_html subdirectory. 

Examples of three possible Client/Server scenarios 

• Office 2000 and NetWare 5.1 server and a valid NetWare client 

WebDAV support is built into Office 2000 applications. With NetWare 5.1 and a valid NetWare 

Client 32, then functionality is maximized. WebDAV connectivity is a function of the NetWare 

5.1 server, the NetWare Enterprise Web Server, and the loading of the WebDAV.NLM. 

WebDAV supports the access to resources on a NetWare 5.1 server through a standard HTTP 

browser, either Internet Explorer 5.0 or WebDAV enabled browser and the services being enable 

on the server. Having Office 2000 installed and the use of a valid NetWare 5.1 client to connect to 

a NetWare 5.1 server provides the great advantages over other options available. This option can 

be referred to as the fully functional method seeing as it has all the pieces in place to take 

advantage of the new NetWare 5.1 enhancements and Office 2000 integration. This option allows 

the user to access resources using WebDAV through a compliant browser, as well as, have access 

to network resources that are not available to workstations with no client installed, specifically 

administration. With client 32 connectivity to the network a user and workstation take advantage 

of the resources the network provides. Further an administrator has NWAdmin and ConsoleOne 

capabilities for administration, something that is missing from the other scenarios. Other major 

advantages for having a client installed are, accessing files from applications that do not support 

the WebDAV protocol, drive mappings for running applications and that the Microsoft Windows 

WebDAV implementation is slower. 

• Office 2000 and NetWare 5.1 server and no installed client 



Another option is to have the same NetWare 5.1 server installed and have Microsoft Office 2000 

installed on the workstation, but not have a Microsoft or NetWare client installed on that 

workstation. The user is able to access the resource from a browser and open, edit and save the 

document in it’s original authored application and not have to be formally logged into the 

NetWare 5.1 server with either the Microsoft NetWare Client or Client 32. Currently IPP and 

Internet printing is available using WebDAV and Office 2000. Full administrative capabilities are 

not yet available, due to NWAdmin dependencies for client 32, but in the future advanced 

administration will be extended to include most, if not all, of the functionality of that NWAdmin 

and still not require a client to be installed. This is the vision of the developers of the WebDAV 

protocol and Novell’s use of it. 

• Office 97, IE 5 or other browser and NetWare 5.1 

WebDAV supports the connectivity of a user to a resource even without the Office 2000 products. 

This connectivity is a function of the NetWare 5.1 server, the NetWare Enterprise Web Server, 

and the loading of the WebDAV.NLM. WebDAV supports the access to resources on a NetWare 

5.1 server through a standard HTTP browser, either Microsoft IE 5 or a WebDAV enabled 

browser and the WebDAV services being enabled on the server. With IE 5 installed on a 

workstation the “My Computer” is extended to include Web Folders. The purpose of this is to 

allow the user to have access to the resource and be able to get to the documents, and be able to 

access these documents in their native format from a server. However, since Office 97 applications 

have not been extended to include the Save As Web Folders dialog box, a document will need to 

be placed in a valid Web folder in order for other WebDAV enabled applications to have typical 

Web folder access to them. 

If another browser was installed that was not WebDAV enabled then documents would need to be copied to 

the local workstation in order to be modified in the “creating” application, then saved and placed back on 

the server. This is similar to standard file access, except in a client-based connection the user can modify 

the document in place and can open, edit and save the document from it’s original location. 

With WebDAV the purpose is to allow a workstation without a client the ability to get to a resource and 

have access to documents without being tied to a specific client installation. This is not an ideal scenario, 

but the fact that it is possible is leaps ahead of where we started. 

Troubleshooting 

• Valid IP address 

• DNS/DHCP properly configured 

• PKIS/SAS properly installed and functioning 

• Error log on Enterprise Web Server: /novonyx/suitespot/https-servername/logs/errors. 

• The browser does not have a logout feature, so the only way to change the user is to reboot the 

workstation or logout of the Windows and log back in. 

• Support Pack 1 should address the need to have a single file placed in the Homedir directory for 

proper functionality and should address the creation of the Webdav.pdb file in all WebDAV 

enabled folders, this is a database of the attributes of the WebDAV objects. This is a function of 

the Homedir code and not necessarily a bug in WebDAV, and development is aware of the issue. 

• NDSDAV Note: The Homedir folder is still available once NDSDAV is turned off, what isn’t 

available is the “My Network” folder. The “My Network” folder is only available if NDSDAV is 

turned ON and working. If it is not the virtual directory and the subsequent NDS objects are 

unavailable. (An unexpected error has occurred”) will be displayed if the “My Network” Web 

Folder is attempted to be accessed. 



• Common error messages for Web Folders are available at 


• An in-place upgrade with the Netscape Enterprise Web server 3.0 loaded will need to upgrade to 

the NetWare Enterprise Web Server and be sure to turn WebDAV State to ON. See figure below: 

• The use of the users fully distinguished NDS name is the default however, if you wish to use 

common names, a change must be made in the NetWare Enterprise Web Server. Contexts will 

need to be added to the Global Settings, Configure Directory Services admin page of the Web 

Server that includes the users’ context. Administration of this can become cumbersome if the 

users are spread throughout many OUs, but if a few exist then this is a relatively easy change to 

implement. See figure below. 



Conclusion 

WebDAV integration with Office 2000 applications and the NetWare 5.1 server is part of Novell’s first 

attempt at getting away from the standard “client” that we are all accustomed too. The capabilities that this 

protocol provides are functional, but not complete. The creator’s vision of a “collaborative Internet” has 

begun with the acceptance and more widespread use of this powerful protocol. As more and more 

applications are written to support the WebDAV protocol, more widespread and interesting uses’ will 

immerge for collaborative document creation and sharing. Novell’s own interesting use of the WebDAV 

protocol, NDSDAV, allows for common administrative tasks to be performed, this like the WebDAV 

protocol, is the first attempt at a pure “clientless” administration environment. Novell has taken great 

strides to embrace the changing times to reflect an image of a fully Internet-enabled software company and 

WebDAV integration with NetWare 5.1 and NDSDAV are very good steps in that direction. 

Subprocess 6—Create the WebDAV Report 

Document for the customer how to implement WebDAV. 



Subprocess 7—Review and Deliver WebDAV Report to 

Customer 


The project manager should review your WebDAV report and make any recommendations or suggestions. 

Activity 2—Deliver WebDAV Report 

Deliver WebDAV report to the customer. 



Appendix A—IPX-Dependent Applications 

Worksheet 

Note: This completed worksheet should be included in the documentation (report) that is given to the 

customer. 

1 2 3 4 5 

Application Name Version Running on Server 

(server name) 

Mission 

Critical? 

Y / N Y / N Date 

Available 

IP-Only Upgrade Available? IPX-Depende 

Plan to Upgrade 

to IP Version? 



(no IP-only up 

Will Support

Appendix B—CMD Essentials 

Note: we do not recommend, and actively discourages customer use of CMD servers if at all 

possible. There are many reasons for this, but among them are the NDS overhead issues of storing 

sapsrv.novell information in the SLP scopes, and the significantly reduced number of servers that 

can be placed into a single scope as a result of the size of the sapsrv.novell services entries in the 

SLP database (NDS). 

One of the easiest ways to make NetWare 5.1 interoperable with earlier versions of NetWare is to 

implement NetWare 5.1 over IPX. While this is an easy solution, it is probably not the most 

optimal. Novell is moving away from IPX as the standard communication protocol for NetWare. 

The primary reason most organizations are moving to NetWare 5.1 is to implement its TCP/IPbased 

features. 

We recommend the “dual-stack” approach to migrate to a pure IP environment. This approach 

involves the loading and binding of both the IPX and TCP/IP protocol on the NetWare 5.1 servers 

to provide backward compatibility. Once done, all IPX dependencies on the network are identified 

and removed. Once removed, IPX is then unbound from the servers, and the pure IP environment 

is in place. 

Unfortunately, some clients will not be able to implement this approach for a migration to a pure 

IP environment. There is an immediate need for IP-only clients to be able to use IPX services on 

the network. This can only be done using a Migration Agent that provides a gateway between the 

IP and IPX worlds. Additionally, clients can see benefit in removing the IPX protocol from WAN 

links for increased network performance. This piece can only be accomplished using the Backbone 

Support feature also available with compatibility mode. For these clients, compatibility mode is a 

primary key in the goal of migrating to a pure IP environment. 

Understanding Compatibility Mode Basics 

In order to plan for and design a compatibility mode infrastructure, it is important first to 

understand why technology like compatibility mode is needed. To get this understanding, it is 

important to see how clients and servers communicate in a NetWare environment. Traditionally, 

this communication has been accomplished using IPX as a transport protocol; however, the main 

“language” spoken by NetWare clients and servers is actually something called the NetWare Core 

Protocols (NCP). NCP is actually an abstraction at a higher layer of the OSI model of networking 

that sits above the Network layer, where the communication protocol is actually defined. 

Because NCP exists at a higher layer, the packet is constructed with the necessary NetWare related 

information and passed down to the Network layer, which is responsible for the actual protocol. 

Thus, NCP can pass its information to the IPX stack for IPX communications, or it can pass its 

information to the TCP/IP stack. In NetWare 5.1, that is how NCP communications are able to use 

TCP/IP. NCP is protocol independent. 

Communication between IP-based NetWare 5.1 servers and clients is done over TCP. When a 

client requests services from a server, it creates a TCP packet using a high source port number 

(over 1024). The destination port number for this packet is 524 because this is the port on which 

NetWare 5.1 listens for NCP-based communications. The normal TCP three-way handshake to 

establish a session is initiated, and the client and server begin a normal communication session. 

In a perfect world, all programmers would code their applications to use NCP. Unfortunately, this 

is not the case. Many applications on the market or custom developed make calls directly to the 

SAP protocol or to the IPX stack itself. When the abstraction of NCP is bypassed in such a 

manner, there is no way for the packet to be passed to the TCP/IP stack instead of the IPX stack. 

This is why compatibility mode must exist. In a pure IP environment, these “misbehaving” 



applications are still going to make calls to the IPX stack. A technology had to be created to 

address this. 

This technology is the compatibility mode driver (CMD). CMD is responsible for taking packets 

coming from the IPX stack. Because CMD does not know the calls that were made by the 

application in passing it to the IPX stack, it cannot remove the pertinent information and redirect 

them to NCP; however, it can redirect the entire IPX packet to the TCP/IP stack. This is, in fact, 

what CMD does. The IPX packet is redirected to the TCP/IP stack where it is encapsulated in a 

TCP/IP packet using a UDP header. The packet then goes out on the wire as IP instead of IPX. 

Figure B1 shows how the CMD module interacts with the other components on a NetWare 5.1 

client or server. Once the packet is out on the wire and reaches its destination, the destination host 

begins to process the incoming packet. After unwrapping the TCP/IP components, the destination 

host is left with an IPX packet to process. The IPX packet is redirected by CMD to the IPX stack 

where it is processed and sent up to the higher layers of the OSI model of networking. Thus, CMD 

must be loaded on both the source and destination machines for compatibility mode to function 

properly. 

Protocol 

Interface 

IPX 

CMD 

Redirect 

Libraries 

NCP 

Application 

SAP 

CMD 

Redirect 



IP 

Figure B1. Illustrating CMD redirections. 

SLP 

If the destination machine did not know how to process the IPX packet after unencapsulating it, an 

error condition would have occurred, and the packet would not have been processed. It is critical 

that the IPX stack be loaded on both the servers and clients because it is a necessary component of 

compatibility mode, just as much as CMD being loaded is required. However, once loaded, IPX 

cannot be bound to the network interface. This would defeat the purpose of compatibility mode, as 

IPX would be put out on the wire.

Figure B2 shows the different types of packets that can be put out on the network when clients and 

servers have CMD loaded. Only applications that call the IPX stack directly will produce 

encapsulated packets. These encapsulated packets are UDP packets addressed to port 2645 for 

both source and destination. Behaved applications making use of normal NCP calls will put 

NCP/IP packets out on the wire as discussed previously. 

Figure B3 shows an actual packet trace showing that a particular server will communicate over 

NCP/IP for certain functions while also encapsulating IPX in IP for other functions. In this 

example, the server 172.20.1.18 is using NCP/IP to perform NDS operations; however, the 

encapsulated packets being generated by this server can also be seen. 

Call to IPX 

I 

P 

X 

NCP 

CMD 

Call to NCP 

T 

C 

P 

I 

P 

NCP/IP--TCP port 524 

IPX encapsulated in IP 

IP-CMD Client 

UDP port 2645 

IP-CMD Server 

Figure B2. Traffic patterns with CMD. 



Figure B3. A CMD server uses NCP/IP and encapsulation. 

Loading CMD on Servers and Clients 

As mentioned previously, if there are IPX-dependent applications on a network where only IP is 

allowed on the wire, CMD must be used. CMD must be loaded on all clients and servers where the 

IPX dependencies exist. The modules required for loading CMD on clients and servers come with 

the latest version of the NetWare client and are installed on a NetWare 5.1 server by default. 

To load CMD on the client, it is merely an installation option during the normal installation of the 

client. To install it, choose the Custom installation option. When prompted to install stacks, 

choose the IP with CMD option. This will load the TCP/IP stack, the IPX stack and the CMD 

driver, which acts as a shim for the IPX stack. In this configuration both protocol stacks are 

loaded, but only IP is bound to the network interface on the client. 

There are configuration options that need to be set on the CMD client. These are the CMD 

network number and preferred Migration Agent. They are settable on the CMD driver property 

page. By default, the CMD network number is FFFFFFFD. The need for the CMD network 

number and preferred Migration Agent will be discussed in the section on the Migration Agent. 

Note: It is recommended that the default CMD network number not be used. This will prevent the 

production environment from being affected by a renegade server brought up having the default 

CMD configuration loaded on it. 

For NetWare 5.1 servers, there is an NLM that is loaded to support CMD. This is SCMD.NLM, 

and it stands for Server Compatibility Mode Driver. This module can be loaded on a NetWare 5.0 

or 5.1 box, a NetWare 4.2 box, or a NetWare 4.11 box with at least Service Pack 6 installed. It 

should be noted that a NetWare 4.x box running CMD would always use CMD to communicate 



with other servers. This is because NetWare 4.x boxes cannot support NCP/IP natively. Only 

NetWare 5.x has that capability. 

Note: SCMD.NLM does not come by default with NetWare 4.11. It has been incorporated into the 

service packs. It is recommended the latest version of the service pack be applied to 

NetWare 4.11. 

Note: SCMD.NLM is dependent upon SLP for reasons that will be discussed later. When 

SCMD.NLM is loaded on a NetWare 4.11 or 4.2 box, it is imperative to make sure the latest 

versions of SLP.NLM and SLPTCP.NLM are also installed and loaded on that box. 

After SCMD is loaded for the first time on a NetWare 5.1 box, some new SET parameters become 

available. These parameters can be configured using the SET utility at the server console or by 

using MONITOR. The new parameters can be found under the Communications option. When 

SCMD is installed on a NetWare 4.x box, there are no new SET parameters. Options must be set 

at the command line when the SCMD.NLM module is loaded. 

SCMD does not require any options to load in default mode; however, some advanced features of 

SCMD can only by implemented by using command line switches. Table 1 summarizes some 

useful switches associated with SCMD. 

Switch Description 

/BS, /G, /MA Loads SCMD in Migration Agent/Backbone Support mode 

/NET= Specifies CMD network number 

/PREFIP= Specifies IP address CMD uses on server w/ multiple NICs 

/STAT Displays CMD server statistics 

/NOSLP CMD uses static list to discover other Migration Agents 

Table B1. Useful SCMD.NLM command line switches. 

Note: The /STAT option is used when SCMD is already loaded. At the server console, load 

SCMD.NLM re-entrantly with the /STAT switch. Statistics will be displayed. 

Note: The /NOSLP option is used only when SCMD.NLM is in Migration Agent mode. This 

option does not affect the normal SLP dependencies inherent in CMD. 

When SCMD is loaded on the server, two new SLP enabled services are registered on the 

network. This means that if DAs are being used on the network, two SLP service objects will be 

registered in the NDS scope. The services that are registered are the sapsrv.novell object and the 

cmd.novell object. In the event SCMD is loaded with the /BS, /G, or /MA switch, the types of 

services registered will be mgw.novell instead of cmd.novell. Like all SLP objects, these objects 

will contain the necessary attributes pertaining to the service. 

The reason for these types of SLP objects being registered has to do with the addressing scheme 

necessary for applications that call the IPX stack directly. Service resolution for CMD servers will 

be addressed in the next section. 



Service Resolution with CMD 

Because the IPX dependent applications make calls directly to SAP or the IPX stack, bindery 

information is required on the server. This bindery information refers to the SAP information 

normally found on an IPX network. That is the only type of addressing scheme IPX dependent 

applications know, and CMD has to provide that functionality for the applications since SAP 

information is not available on the wire. 

This particular discussion of service resolution assumes that all nodes on the network are IP nodes 

running CMD for IPX dependent applications. Having both IPX and IP networks with CMD will 

be discussed in the next sections on Migration Agents and Backbone Support. 

When SCMD is loaded on a NetWare 5.1 server, the server will build its own internal SAP table 

to provide bindery information to IPX dependent applications. It populates this table with 

information it learns through SLP. Specifically, the SAP table is built by looking at all SLP 

objects of type sapsrv.novell on the network. When the SCMD module is loaded, the user agent on 

the server makes a service request for all sapsrv.novell objects. How it does this depends upon 

how the user agent is configured to perform SLP service resolution (multicast or DA). The 

information returned from the SLP service request is put into the SAP table. 

Because only CMD servers on the network register SLP objects of type sapsrv.novell, only CMD 

servers will be listed in the SAP tables. NetWare 5.1 servers running pure IP will not be accessible 

to IPX dependent applications running on a CMD server. Figure B4 illustrates the population of 

the CMD server SAP tables. In this diagram, all service agents have already registered their 

services with the DA. The SCMD module will periodically force the user agent to retrieve a list of 

sapsrv.novell objects to build the internal SAP table. Only those servers that have registered a 

sapsrv.novell object will be returned by the DA and entered into the internal SAP table. 

DA 

SA1 w/ CMD SA2 no CMD SA3 w/ CMD 

Bindery Table 

SA1 

SA3 

bindery.novell 

SA1 

SA2 

SA3 

sapsrv.novell 

SA1 

SA3 

SLP SReq 

sapsrv.novell 

sapsrv.novell 

SA1 

SA3 

Bindery Table 

SA2 

cmd.novell 

SA1 

SA3 

sapsrv.novell 

SA1 

SA3 

SLP SReq 

sapsrv.novell 

Bindery Table 

SA1 

SA3 

Figure B4. CMD servers build SAP tables from sapsrv.novell objects. 

Looking at the attributes of the sapsrv.novell object itself sheds light on how the server is able to 

build its internal SAP table with the information provided in the object. The attributes of the 

sapsrv.novell object include the following pieces of information: 

• The protocol of the service (IPX) 



• The internal IPX number (server ID) of the originating server 

• The IPX socket number 

• The SAP type (i.e. type 4 for file server, type 278 for NDS tree, type 26B for time) 

• The IP address of the originating server in hexadecimal format 

• The IP subnet of the originating server in hexadecimal format 

• The name of the originating server 

With all of this information, CMD can build the internal SAP table on the server. Additionally, it 

can also translate the SAP service to an IP address for servers because all of that information is 

included in the sapsrv.novell object. But it is clear that CMD is an SLP dependent module because 

SLP is required to build the internal SAP table. 

Because CMD is dependent upon SLP, all of the rules concerning scoping apply. If servers 

register their sapsrv.novell objects with different scopes, they will not be able to see each other in 

the CMD realm, either. It is wise to register all sapsrv.novell objects with the same scope and have 

servers use that scope to provide seamless compatibility services for the network. 

In order to keep the SAP table current, CMD forces the user agent on the server to make an SLP 

service query for sapsrv.novell objects every five minutes. Thus, there is latency involved in 

bringing up or down CMD servers. When a server is brought up, it may not be visible, from a 

CMD perspective, to other servers for up to five minutes. Conversely, when a CMD server is 

downed, it will not disappear from the other servers’ SAP tables until the next SLP service query 

is sent out. 

To this point, the assumption has been made that all servers and clients are running the CMD 

pieces necessary to provide backward compatibility for IPX dependent applications. In this 

environment, only the IP protocol is allowed on the wire, but there are many instances and 

environments where IPX and IP need to coexist. For example, NetWare clients on an IP segment 

of the network may need to communicate with NetWare servers on an IPX segment. This is not 

possible given the current set of assumptions. However, it is possible when the SCMD module is 

loaded on a NetWare 5.1 server with Migration Agent capabilities enabled. This will be discussed 

in the next section. 

The Migration Agent 

A second feature or operating mode of the SCMD.NLM module on a NetWare 5.1 server is the 

Migration Agent (MA) function. The use of an MA on the network allows IPX clients and servers 

to successfully communicate with IP/CMD clients and servers. Thus, the MA becomes an integral 

part of a migration strategy where IPX and IP need to coexist in an environment for a period of 

time. 

To enable SCMD to function as an MA, SCMD must be loaded with the /G, /BS, or /MA switch. 

The server functioning as an MA must also have IP and IPX bound to its network interfaces. This 

makes sense because the MA actually functions as a gateway between the IP and IPX networks. It 

is not necessary for an MA to have two interfaces to function in that capacity; a server with only 

one network interface can efficiently function as a Migration Agent. 

Adding a Migration Agent to the network adds a bit of complexity to the CMD environment. This 

is because there is a whole set of IPX services that need to become visible to the CMD network 

and vice versa. The key to a successful implementation of a Migration Agent lies in understanding 

the inner workings of the MA and how it is able to facilitate the communication between these 

disparate protocols. 



CMD to MA Communication 

When an MA is introduced to a CMD network, there are a number of new IPX services about 

which the CMD servers need to know. But these services do not exist in SLP. They exist on the 

IPX network itself. The CMD servers must rely upon the MA to obtain bindery information they 

cannot obtain by themselves. Figure B5 illustrates the separate IPX and IP networks. 

IPX Client 

IPX 

RIP/SAP 

Information from 

IPX Device 

Broadcasts 

Migration Agent 

IP/CMD Server FS2 

IP/CMD 

SAP Information 

from SLP 

Registered Services 

IPX Server FS1 IP/CMD Client 

Figure B5. The MA connects the IP and IPX networks. 

In Figure B5, file server FS1 is not a service that will register a sapsrv.novell object with SLP. 

This is because it is not an IP based device with an SLP enabled service to advertise itself. From a 

CMD perspective, FS2 needs to be able to communicate with FS1, but it cannot retrieve bindery 

information about FS1 through SLP. This is where the MA comes into play. 

When an IP/CMD server is brought up, it will try to find an MA on the network either through 

static configuration or through SLP. When it discovers an MA on the network, it will initiate a 

TCP connection with the MA. This connection is established on TCP port 2302, and it will be 

persistent as long as both servers are up. Once this session is established, the MA sends known 

bindery information from itself to the CMD server. In Figure B5, FS2 would establish a TCP 

connection with the MA, and the MA would send bindery information about the IPX network to 

FS2. FS2 populates its internal SAP table with the information the MA sends. 

Once per minute, the Migration Agent will forward changes in its SAP tables to the CMD servers 

that have established TCP connections. This is how the CMD servers are able to keep the 

information contained in their internal bindery tables current. Without this update, the CMD 

servers would time out the information about the legacy IPX network in the bindery tables. 

This is a one-way method of communication in terms of bindery information. The CMD server 

does not send bindery information back to the MA across the established TCP session. The MA 

discovers that information through SLP. Thus, the MA learns about the CMD server through the 

normal 5-minute sapsrv.novell object request SCMD performs. Figure B6 illustrates the exchange 

of bindery information on the CMD network between CMD servers and the MA. 



Once per minute 

RIP/SAP broadcast 


Delta bindery information 

sent from MA to CMD 

TCP port 2302 

session established 

SLP SReq for 

sapsrv.novell objects 

Bindery information from 

CMD Network 


IP/CMD 

Directory Agent 

Figure B6. Bindery information exchange on CMD network. 

In Figure B6, the server FS2 would populate its internal bindery tables with information learned 

from the MA. The Migration Agent would learn about FS2 from its query to the Directory Agent. 

Only when this SLP query is answered will the MA populate its internal bindery tables with 

information about FS2. Once that has been done, FS2 will be advertised on the IPX network when 

the MA does its next RIP/SAP broadcast. 

There are two requirements that must be satisfied before IP/CMD servers and Migration Agents 

will communicate bindery information to one another: 

• The Migration Agent and the CMD server must be in the same SLP scope. If they belong 

to different SLP scopes, they will not be able to see one another. 

• The Migration Agent and the CMD server must be part of the same CMD network. 

If the MA and CMD server are not part of the same CMD network (also known as the virtual IPX 

network), they will not be able to exchange information. From the MA perspective, all of the 

CMD servers belong to a virtual IPX network. That is how it is able to route IPX packets from the 

IPX network to the CMD network. The CMD network is advertised on the IPX segment as a 

normal IPX network that is one hop away from the MA. The MA passes any packets destined for 

the CMD network to the SCMD module, which takes care of the encapsulation and addressing of 

the packet to the CMD server on the CMD network. 

If an IPX client needs services from an IP/CMD server, the Migration Agent will encapsulate that 

packet and send it to the CMD server. Like all encapsulated IPX packets, the packet sent from the 

MA to the CMD server (data traffic) will be sent via a UDP packet utilizing port 2645. All 

encapsulated IPX traffic on the CMD network will use UDP port 2645 packets. 

Note: Migration Agents will only perform the encapsulation of IPX packets in forwarding them to 

the CMD network. They will not translate NCP/IPX packets into NCP/IP packets before 

forwarding them. 



MA to IPX Communication 

Just as the MA is responsible for providing bindery information to CMD servers on the network, it 

is also responsible for advertising services available on the CMD network to the IPX network. 

This advertising of services is accomplished through the normal RIP/SAP broadcasts once per 

minute. But the MA must rely upon SLP to retrieve the SAP information from the CMD network, 

as was shown in Figure B6. 

Once every five minutes, the MA will make an SLP query (using UDP or TCP port 427 packets) 

to find a list of sapsrv.novell objects available on the CMD network. Once it retrieves this 

information, the MA will populate its internal SAP table with the services learned. On the next 

broadcast, any new services learned by the MA about the CMD network will be advertised to the 

IPX network. 

At the same time, the MA also advertises the virtual IPX network (CMD network) to which it is 

connected. This RIP information is required for routing to happen between the IPX segment and 

the CMD segment, which is represented as a virtual IPX network. Thus, the CMD network 

number must be unique to the entire network just as normal IPX network segments must be. 

IPX services need not know the specific address of the Migration Agents on the network because 

RIP takes care of all the routing on the IPX network. As long as the Migration Agent through SAP 

is properly advertising the CMD services, there is no extra configuration required of IPX clients to 

use the MA. The same is not true, however, of the IP/CMD clients. 

Note: HOP counts are added for SAP/RIP broadcasts from MA to CMD based on IP 

distance—not by the physical router distance. MA will add one hop if the CMD server is on the 

same segment, two hops if it is on different segment, and 3 hops if the CMD server is on a 

different IP network (but the same CMD network). Currently there is no parameter to change this 

value. This is an important factor to consider when designing CMD networks. 

IP/CMD Client Communication and Configuration 

Because IP/CMD clients are IP based, there is some client configuration required for MA use. In 

the CMD driver property page, there are two important parameters that can be configured. The 

first parameter is the CMD network number. As with IP/CMD servers, the IP/CMD client must be 

part of the same virtual IPX network the MA is servicing. If it is not, the IP/CMD client will be 

unable to utilize the MA. 

The second configurable parameter is the preferred Migration Agent. There are a number of ways 

for an IP/CMD client to discover Migration Agents on its CMD network: 

• The IP/CMD client can discover Migration Agents through SLP. It can send out an SLP 

query looking for objects of type mgw.novell, which indicate that the Migration Agent 

service is available on the network. 

• The IP/CMD client can obtain Migration Agent information through DHCP. 

• The IP/CMD client can be statically configured to look to a list of Migration Agents 

specified in the property page of the CMD driver at the client. 

When using DHCP to hand out CMD information, Novell has set aside option tags for use. The 

main option tag used to hand out CMD information is option tag 63, which is the same option tag 

for NetWare/IP. The pertinent sub-options of option tag 63 are as follows: 

• 63-12 specifies the CMD network number to which the client belongs. 

• 63-13 specifies the server resolution time. 

• 63-14 specifies the IP addresses of Migration Agents on the network. 



Once the IP/CMD client has discovered the available Migration Agents on the network, its method 

for finding IPX services for its IPX-dependent application changes a little bit. Instead of only 

querying SLP for sapsrv.novell objects, the IP/CMD client will simultaneously query SLP and the 

MA for bindery information. This is how an IP/CMD client is able to obtain the services of an IPX 

only server. Remember that SLP will not return any information about IPX only services; those 

services are available only through the MA. Figure B7 illustrates the query process for finding and 

IPX-only server. 

IPX Client 

IPX 

IPX Server FS1 


Yes FS1 

IP/CMD Client 

IP/CMD 


No FS1 




FS1? 

Figure B7. IP/CMD client queries both SLP and MA for service information. 

To this point, the discussion has been about CMD networks and interoperability with legacy 

services on an IPX network. Another operating mode of SCMD.NLM is to provide connectivity 

between non-contiguous IPX segments on a network. This is called Backbone Support and is a 

feature that can be used to remove IPX traffic from WAN links. 

Backbone Support 

Backbone Support is a popular feature of SCMD.NLM because it allows organizations to remove 

the IPX protocol from WAN links without interrupting end to end IPX services on the network. 

This is because SCMD.NLM servers configured to function, as Backbone Support Migration 

Agents will exchange the necessary RIP/SAP information by encapsulating that IPX information 

in an IP packet. Thus, the packets on the WAN link are IP-only. 

Enabling SCMD.NLM to function in Backbone Support also gives that server the capabilities of 

functioning as a CMD server and as an MA. To enable a server to utilize Backbone Support, 

SCMD.NLM must be loaded with the /G, /MA, or /BS switch at the command line. Additionally, 

the server must be configured to use the NLSP routing protocol (with RIP/SAP compatibility). 

This configuration can be done through INETCFG.NLM. 

Once Backbone Support has been enabled, the server will attempt to find other Backbone Support 

servers. It will do this in one of two ways: 

• The Backbone Support server will query SLP for services of type mgw.novell. 

FS1?

• The Backbone Support server will look to a statically configured list of other Backbone 

Support servers as specified by the Migration Agent List SET parameter. 

Note: If one Backbone Support server is statically configured to look for other Backbone Support 

servers, then all Backbone Support servers on the same CMD network must be statically 

configured to look for other Backbone Support servers. It is an all or nothing proposition. 

Just like CMD servers and Migration Agents, Backbone Support servers must be part of the same 

CMD network in order to communicate and exchange bindery information with one another. 

Backbone Support servers belonging to separate CMD networks will not communicate with each 

other to exchange that information. 

After Backbone Support servers discover one another, they exchange their RIP/SAP information, 

and they will continue to exchange their RIP/SAP information so that services advertised on their 

respective IPX networks will be current. The Migration Agent servers use the NLSP routing 

protocol to exchange route and SAP information between Migration Agents. Figure B8 shows a 

simple example of two Backbone Support servers exchanging RIP/SAP information. 

IPX 

Network 

1 

RIP/SAP info from IPX 

Network 1 encapsulated 

in IP (UDP 2645) 



Server 

Server 

RIP/SAP info from IPX 

Network 2 encapsulated 

in IP (UDP 2645) 

IPX 

Network 

2 

Figure B8. Backbone Support servers exchange RIP/SAP information. 

As noted in Figure B8, the RIP/SAP information from each IPX network is encapsulated in IP 

packets. This exchange of IP packets between the Backbone Support servers is accomplished 

using a UDP packet addressed to port 2645, as all IPX encapsulated traffic is. This figure assumes 

that the Backbone Support servers do belong to the same CMD network. 

The MA to MA Protocol 

When Migration Agents in Backbone Support mode exchange bindery information, this is called 

the MA to MA protocol. There are some special considerations to enabling a number of servers in 

Backbone Support mode because NLSP routing is enabled on the servers. This NLSP routing is 

what facilitates the efficient exchange of bindery information between the non-contiguous IPX 

networks, but there is an overhead cost involved by using NLSP. 

After Migration Agents in Backbone Support mode discover each other, they become NLSP 

neighbors in the virtual IPX network that has been created for CMD. Because these servers are 

NLSP neighbors, they must exchange the normal overhead packets required for NLSP routing. 

These administrative packets (or HELLO packets) are required by NLSP to maintain the NLSP 

routing tables. If the HELLO packets are not received within a specific time out window, the 

NLSP router marks its neighbor as being unavailable. Figure B9 illustrates the NLSP overhead 

packet in an IPX environment. 



NLSP Neighbors 

NLSP2 Up 13 

NLSP3 Up 43 

NLSP4 Up 27 

NLSP1 

NLSP broadcast HELLO 

packet from NLSP1 

NLSP2 


NLSP1 Up 60 

NLSP3 Up 43 

NLSP4 Up 27 


NLSP1 Up 60 

NLSP2 Up 13 

NLSP3 Up 43 

NLSP4 

NLSP3 

Figure B9. The NLSP HELLO packet updates neighbor routing tables. 


NLSP1 Up 60 

NLSP2 Up 13 

NLSP4 Up 27 

In Figure B9, server NLSP1 sends out its HELLO packet to its neighbors via broadcast. The 

neighbor NLSP routers receive this packet and update their tables to reflect the refresh of NLSP1 

as their active neighbor. They update the time to live (TTL) of NLSP1 in their NLSP neighbor 

table. This is shown in bold along with their other neighbors and their TTLs. Should the TTL of an 

NLSP neighbor reach zero, the neighbor will be marked as unavailable, and it cannot be used as a 

route to reach destination services. 

By default NLSP HELLO packets are sent out every 20 seconds by NLSP routers with a multiplier 

of three. This multiplier determines the TTL for the NLSP router in the NLSP neighbor table. This 

makes the default TTL for the neighbor router 60 seconds. By modifying the multiplier and 

HELLO packet interval, the NLSP overhead traffic can be controlled. 

To change the NLSP configuration on a server, the NLSP settings in INETCFG must be modified. 

Under Protocols⇒IPX⇒Expert Configuration Options, the NLSP Convergence Rate parameter 

must be set to Manual. Once done, the actual configuration of the NLSP convergence rate 

parameters can be done through the NLSP Convergence Rate Configuration option on the same 

menu. The parameters that most significantly affect the NLSP convergence rate are as follows: 

• Broadcast Hello Interval—this defines how often NLSP HELLO packets are sent out by 

the NLSP routers. Increasing this value decreases the frequency with which NLSP 

HELLO packets are put out on the wire. 

• Holding Timer Multiplier—this defines the TTL for an NLSP neighbor. Increasing this 

value increases the TTL value for the NLSP neighbor. 

In the example in Figure B9, one packet is required from every server at least every 60 seconds to 

update the NLSP neighbors table on neighbor NLSP routers. Thus, each of the four servers will 

send out a broadcast packet once at least every 60 seconds leading to a minimum total packet 

count of four for NLSP overhead. The HELLO packet is a small packet, and it is much more 

efficient than the server broadcasting its entire RIP/SAP tables once per minute. 

However, because NLSP is an IPX based routing protocol, NLSP packets cannot be placed 

natively on an IP-only segment. Something has to be done to encapsulate the NLSP packets in IP 

and to send them to the NLSP neighbors. Backbone Support is the tool by which this is 

accomplished. When the IPXRTR module on a Backbone Support server passes information the 

HELLO packet to the virtual IPX network, the SCMD module takes over. The NLSP packet is 

encapsulated in IP and sent to all other BS servers on the same virtual CMD network. 



From an NLSP perspective, all Backbone Support servers that belong to the same virtual IPX 

network are NLSP neighbors. This means that all Backbone Support servers must exchange NLSP 

HELLO packets to keep their routing tables updated. If the TTL of the NLSP neighbor reaches 

zero, the route will no longer be available. This will lead to the disappearance of services through 

the IP-only segment of the network. 

SCMD has a lot of work cut out for it in mimicking the NLSP environment. NLSP is a broadcast 

based protocol. IPX encapsulation is not a broadcast protocol. SCMD has the responsibility for 

getting this originally broadcast information to all required destinations. Figure B10 shows how 

SCMD handles this. 

Inside NetWare server 

Migration Agents known 

MA1 

MA2 

MA3 

IPXRTR SCMD 

NLSP HELLO packet 

sent to virtual IPX network 

Encapsulated HELLO 

packet sent to MA1via 

UDP 2645 



UDP 2645 



UDP 2645 

Figure B10. NLSP HELLO packets are encapsulated and individually addressed. 

When the NLSP HELLO packet is passed from the IPXRTR module of the NetWare server to the 

virtual IPX network, SCMD takes over. SCMD takes the HELLO packet, encapsulates it, and 

individually addresses the packet to each known Migration Agent on the same CMD network. For 

the example shown in Figure B10, one NLSP HELLO packet requires three encapsulated packets 

sent across the IP only network to accomplish the update of NLSP neighbor tables. Figure B11 

shows the example from Figure B9 with SCMD. Notice that 3 packets are required to update the 

NLSP neighbor tables instead of the one broadcast packet from Figure B9. 




NLSP2 Up 13 

NLSP3 Up 43 

NLSP4 Up 27 

Encapsulated NLSP 

HELLO packet from 

NLSP1 

NLSP1 w/ SCMD 



NLSP1 

NLSP2 w/ SCMD 



NLSP1 


NLSP1 Up 60 

NLSP3 Up 43 

NLSP4 Up 27 


NLSP1 Up 60 

NLSP2 Up 13 

NLSP3 Up 43 

NLSP4 w/ SCMD 

NLSP3 w/ SCMD 

Figure B11. Updating NLSP tables across the virtual IPX network. 


NLSP1 Up 60 

NLSP2 Up 13 

NLSP4 Up 27 

As the number of Backbone Support servers on the same CMD network increases, the number of 

packets required for NLSP overhead also increases. This needs to be factored into any Backbone 

Support server design. Besides the overhead NLSP traffic, there will also be the normal bindery 

information flowing between the servers as well. But this is where the benefit of NLSP is seen. 

Because NLSP is a link state routing protocol, it only needs to communicate changes in its routing 

tables to its neighbors. Instead of the entire RIP/SAP table of a server being broadcast out on the 

network once per minute, only the changes the router receives will be sent out. This drastically 

reduces the bindery information that needs to pass across the CMD network from Migration Agent 

to Migration Agent because all of them are NLSP neighbors of each other. Therefore the 

encapsulated NLSP traffic on the CMD network due to bindery information exchange is going to 

be much smaller than the amount of RIP/SAP traffic that would have to send on the same wire in 

the normal IPX environment. 

Filtering Considerations with Backbone Support 

Before implementing the MA to MA protocol on a network, it is important to consider the 

implications it may have. The MA to MA protocol is a virtual routing environment that sits on top 

of an existing physical routing environment. It is possible to route information across this virtual 

network that would not normally be permitted across the physical network. 

Figure B12 shows an example where the physical IPX network is intact with a set of routers 

between two IPX network segments. Between these IPX network segments is a router that filters 

SAP information. IPX services on network segment 1 are not visible on network segment 2 and 

vice versa. A Backbone Support server is installed on both network segments, and they discover 

one another through SLP. 



IPX 

Network 

1 


Server1 

IPX filters enabled 

Router 

MA to MA protocol 

exchanges RIP/SAP info 

IPX 

Network 

2 


Server2 

Figure B12. MA to MA protocol can “break” IPX filters. 

Through the MA to MA protocol, IPX network 1 can see service information about IPX network 

2. The RIP/SAP information has come across the virtual IPX network, and the filters on the router 

are of no consequence. The MA to MA protocol has effectively bypassed the physical routing 

environment. If the MA to MA protocol is to be used in an environment, the filtering on the 

physical network needs to be applied to the virtual network. 

Fortunately, this can be done on a NetWare 5.1 server with SCMD. In order for filters to be 

enabled and enforced by a NetWare server, a LAN driver must be loaded. This LAN driver 

represents an interface through which traffic passes. These LAN drivers are loaded and configured 

with INETCFG.NLM. Once configured, FILTCFG.NLM can be loaded to configure filters. In 

FILTCFG.NLM, filters are only created and enforced on interfaces that have been loaded in 

INETCFG.NLM. Thus, SCMD needs to be loaded as a LAN driver before filtering across the 

virtual IPX network can occur. 

The latest version of SCMD, version 2.18g, includes such a LAN driver that will allow the 

enforcement of filters on the virtual IPX network. With this latest version, it is possible to prevent 

the MA to MA protocol from bypassing filters enabled on the physical network. 

CMD Design Points and Best Practices 

In order to propose a relevant CMD design for a client, it is important to apply the principles of 

the technology. As the design plan is being architected, it is critical to distinguish between the 

functional modes of CMD. There are three functional modes for CMD: 

• Compatibility Mode Driver 

• Migration Agent 

• Migration Agent with Backbone Support 

Each one has its own set of design points that need to be discussed. These designs points fall 

directly out of the technology itself, and the continual application of that knowledge by the 

designing consultant will ensure the proposed architecture is the best one for the client. 

To start, there are a couple of best practices to follow when considering the implementation of 

CMD for a protocol migration strategy: 



• The dual stack migration strategy is the Novell recommended method for protocol 

migration. This is because of the inherent complexities and cost surrounding the CMD 

technology. These complexities include its dependence upon the SLP protocol, the 

implementation of a logical routing environment on top of an existing physical routing 

environment for the backbone migration strategy, and the investment in hardware 

required to provide the fault tolerance necessary for most organizations. The use of CMD 

for a protocol migration strategy should be avoided. 

• In the event the client insists upon using CMD in a protocol migration strategy, the 

presence of CMD should be minimized on the network. Propose a hybrid solution where 

CMD is used on a portion of the network while dual stack is implemented for the 

remainder. This will reduce the cost of the migration strategy. 

Design Considerations with Compatibility Mode Driver 

When the Compatibility Mode Driver is used as part of a protocol migration strategy, the strategy 

becomes dependent upon SLP. Thus, the migration strategy is also limited by any limitations 

affecting the SLP protocol. The overriding limitation of SLP version 1 is the 64KB limit in 

payload packet size for a single SLP query. This will greatly impact any design where servers are 

configured to use the Compatibility Mode Driver. For more information on SLP limitations, refer 

to Appendix D, “SLP Design”. 

The critical piece is that a NetWare CMD server or client will use SLP to find bindery type 

information on the network. It will perform an SLP query to find SLP services of type 

sapsrv.novell on the network. As has been shown in Appendix D, “SLP Design”, Novell 

recommends only registering 540 sapsrv.novell objects with a single scope when a directory agent 

is deployed. 

In exceeding this number, the risk of hitting the SLP 64KB limit increases. In the event the 

directory agent has more SLP information to deliver than 64KB, the SLP user agent on the 

NetWare server or client will only receive the first 64KB of information. Any information above 

and beyond the 64KB limit is truncated and not processed by the user agent. Thus, a user agent 

that receives this truncated information will not completely see all available services on the 

network. There will be incompleteness in the CMD environment, which will lead to service 

interruption. 

sapsrv from FS1 



... 


IP/CDM Client 

sapsrv.novell objects 




... 




sapsrv.novell? 

IP/CMD 

Network 

C00FFEE 

64KB of information 

sapsrv.novell object 

registered 

IP/CMD Server 

FS163 

Figure B13. The 64KB SLP limit will affect poorly designed CMD environments. 



Figure B13 illustrates an example of this limitation. In this figure, the client workstation has an 

IPX dependent application, and it is looking to find the server FS163. To resolve this service, the 

client workstation looks to the SLP infrastructure to find a list of sapsrv.novell SLP objects. The 

directory agent returns the list of sapsrv.novell objects, but the list happens to be larger than 

64KB. The first 64KB of the list is returned to the client, but this information does not include 

information regarding FS163. The application on the client workstation experiences a failure 

because it is unable to resolve how to get to the file server FS163. 

Note: The server number 163 for this example was chosen at random. It is not meant to represent 

a specific limit to the number of servers that can register their services with an SLP scope before 

the 64KB ceiling is reached. 

From a design perspective, the number of CMD servers that can register with a single scope before 

the 64KB limit is reached depends upon the number of sapsrv.novell objects being registered by 

each server. NetWare CMD servers will register multiple sapsrv.novell objects. One such object is 

registered for each SAP type the server needs to advertise. For example, a single server will 

commonly register a separate sapsrv.novell object for each of the following services: 

• NDS replica (SAP type 278) 

• File server name (SAP type 4) 

• Time synchronization (SAP type 26B) 

• RCONSOLE (SAP type 107) 

Even though the recommended limit on the number of sapsrv.novell objects in a single scope is 

540, the actual number of physical servers that can register with a single scope is much smaller. 

The average number of sapsrv.novell objects per server at the client site needs to be assessed, and 

the design strategy needs to revolve around that number. For example, if the average number of 

SAPs per server at a client site is 4, then the actual number of physical servers that could register 

with a single SLP scope is 540 ÷ 4, which equals 135. 

Note: Do not propose a design in which the number of servers registering with a single scope 

exceeds the calculated limit. 

However, the number that is calculated does not represent a limit to the number of servers in a 

single CMD network. If a user agent knows of multiple scopes, it will query multiple directory 

agents and retrieve multiple lists of information. Thus, the user agent could query one scope for 

64KB of SLP information and a second scope for another 64KB of SLP information. The user 

agent can combine those separate lists it retrieves and can logically realize a larger set of CMD 

servers than a single SLP scope can deliver. 

Note: A large CMD server environment always requires a greater number of SLP scopes than a 

non-CMD environment. Understand the implications of having a larger number of SLP scopes 

before proposing such a solution. Refer to Appendix D, “SLP Design” for more details. 

Design Considerations with Migration Agent 

Having a CMD infrastructure generally means there will be a Migration Agent available on the 

network for a period of time. This Migration Agent acts as a gateway between the IPX and 

IP/CMD realms of the network. Whenever a solution is proposed with a Migration Agent, refer to 

the previous section, “Design Considerations with Compatibility Mode Driver”, for an initial set 

of design points. Once complete, read this section about design points with the Migration Agent. 

When thinking about the Migration Agent on a network, it can be reduced to the simple logical 

environment shown in Figure B14. However, don’t let the simplicity of this figure be 

overpowering. There could be a large and complex physical networking environment underneath it 

that needs to be and must be considered. 



IPX Client 

IPX 

RIP/SAP 

Information from 

IPX Device 

Broadcasts 



IP/CMD 

SAP Information 

from SLP 

Registered Services 

IPX Server FS1 IP/CMD Client 

Figure B14. The Migration Agent acts as a gateway between the IPX and IP/CMD networks. 

IP/CMD client and servers can only use Migration Agents participating in the same CMD 

network. This leads to two important design considerations when deploying a migration strategy 

that involves the use of Migration Agents: 

• The placement of the Migration Agent on the enterprise network with respect to the other 

devices in the same CMD network. 

• The scalability of the Migration Agent with respect to the number of IPX clients and 

servers that need to connect with IP/CMD devices. 

Migration Agent Placement 

Migration Agents need to be carefully placed on the network in relation to the other devices 

belonging to the same CMD network. As mentioned, even though the IPX and IP/CMD 

environments can be logically represented in a simplistic fashion, there is usually a complex 

physical routing environment existing underneath it. This physical WAN topology will greatly 

impact the placement of the Migration Agent and in effect the logical overlay of the CMD 

network. Take, for example, the scenario shown in Figure B15. 




CMD net C00FFEE 

WAN link passes IPX and 

TCP/IP 

Router Router 

Figure B15. Poor placement of Migration Agents. 

IP/CMD Client 

CMD net C00FFEE 

IPX Server FS1 


CMD net BADBEEF 

In Figure B15, the physical routing environment is shown along with the placement of the IPX and 

IP/CMD devices on the network. There are two Migration Agents on the network; each one 

services a separate CMD network. The Migration Agent servicing the same CMD network as the 

vast majority of CMD devices is located across a WAN link. There are also a large number of IPX 

devices across the WAN link from the Migration Agent. For argument’s sake, IPX and IP are both 

being allowed to propagate across the WAN link from one network segment to the next. 

The IP/CMD client belonging to the CMD network C00FFEE is attempting to connect to file 

server FS1. Because the client is IP/CMD, the only way it can communicate with the server is 

through the Migration Agent associated with its CMD network number. To facilitate this 

communication, it must send its encapsulated IPX packets across the WAN link to the Migration 

Agent servicing the CMD network C00FFEE. From there, the IPX packets are unencapsulated and 

sent back across the WAN link to the file server. This is inefficient. 

Even though the services the IP/CMD client needs are on the same network segment, the client is 

now dependent upon the WAN link to reach them. The local Migration Agent will not help 

because it does not service the same CMD network as the IP/CMD client. The rule of thumb with 

Migration Agent placement is to place them as close to the CMD devices they are servicing. Try to 

avoid placing Migration Agents across WAN links from devices that need them. 

Note: When utilizing Migration Agents, try to avoid having a CMD network span a WAN link. 

This can lead to inefficient communication patterns. 

The best way to avoid this is to carefully look at the WAN diagrams and site maps provided in the 

PFC. Using this information will make the design more relevant to the client’s networking 

environment. 

Migration Agent Scalability 

There are two main functions that need to be considered when discussing Migration Agent 

scalability. These are as follows: 

• Population of the bindery tables on attached CMD servers through the TCP port 2302 

connection. 

• Handling traffic conversion of IPX to IP/CMD (or the reverse) for clients needing to 

access servers. 



As can be seen from the diagram in Figure B15 above, the Migration Agent can easily become a 

bottleneck on the network when such a migration strategy is deployed. It is critical to understand 

the scalability of the Migration Agent so that it does not become a bottleneck that adversely affects 

the performance of the client’s network during the migration process. 

A number of tests were conducted at Novell’s Super Lab on the Migration Agent to determine its 

scalability. For the purposes of the results, refer to Figure B16 as the logical structure of the 

testing environment. There was a single Migration Agent connecting the IPX and IP/CMD 

segments together. 

IPX 

Segment 


IP/CMD 

Segment 

Figure B16. Logical diagram for Super Lab testing environment. 

The complete Super Lab testing results are included in TID 2953926, which can be found at 

http://support.novell.com. The pieces that pertain to the Migration Agent design are also included 

below. 

Test Objective: 

To test the Service population functionality of the MA from the IP/CMD network to the IPX 

network and collect the data for synchronization of these services between these networks. 

Test Results: 

This feature was tested with 500 sap services in the IP/CMD network. More services could not be 

put in the network since SLP can handle only 540 “sapsrv.novell” objects in a single SLP scope. 

With 500 sap services in the network, the MA which periodically (once in 3 minutes) populates 

the IPX router with the services was performing well with no services being dropped. Also the 

CPU utilization on the MA was very low with an average of 1%. The services were synchronized 

across the networks and any change in the IP/CMD network was reflected in the IPX network 

within a maximum time frame of 3 minutes. 


To test the MA-CMD Protocol and collect data regarding the following: 

• Performance of MA1 while handling multiple CMD servers 

• Traffic generated by the MA-CMD protocol (In both SLP modes) 

Test Results: 

This test was carried out in two different SLP modes, with and without the SLPDA in the network. 

Results for both the modes are described below: 

SLP Multicast Mode (without SLP DA): 

In this mode, one MA could handle up to 90 CMD servers at a time. All the CMD servers were 

connected to this one MA and the service/route transfer from the MA to the CMD servers was 

functioning perfectly without any services/routes being dropped. At this time 100+ different CMD 

clients were able to authenticate to the tree through the MA and 100+ IPX clients were able to 

map to 100+ different CMD servers through the MA at the same time. Addition of more CMD 

servers resulted in CMD servers not attaching to the MA since they could not discover the MA 

through SLP. 

SLP DA Mode: 

In this mode, one MA could handle 160+ CMD servers at a time. All the CMD servers were 

connected to this one MA and the service/route transfer from the MA to the CMD servers was 



functioning perfectly without any services/routes being dropped. At this time 100+ different CMD 

clients were able to authenticate to the tree through the MA and 100+ IPX clients were able to 

map to 100+ different CMD servers through the MA at the same time. During this the average 

CPU utilization on the MA was 12%. 


To test the Service population functionality of the MA from the IPX network and collect the data 

for synchronization of the services between the IPX and CMD servers using the MA-CMD 

solution. 

Test Results: 

10,000 services were simulated from the IPX network and the MA could transfer the same to 160+ 

CMD servers without any drops. The services were synchronized between the IPX and CMD 

networks within a span of 5 minutes. The IPX network was made dynamic by bringing down some 

services in the network and bringing them up again. The MA could handle this dynamism in the 

network and transfer the service changes in the IPX network to all the CMD servers. The services 

were synchronized between the IP and the IPX networks within a span of 5 minutes. 


Performance of a CMD server under stress from the IPX network. 

Test Results: 

One CMD server could handle 50+ IPX clients mapping to itself from the IPX network through 

the MA at the same time. The clients could also successfully complete massive data transfers 

(50MB) from the CMD server. The CMD server was also handling 10,000 services, which it had 

learnt from the MA. At this time the average CPU utilization of the CMD server was 20% 

Note: The overriding design consideration with an MA is that it effectively functions as a router. 

As such, it can become a bottleneck in terms of network performance, and it also becomes a single 

point of communications failure unless steps are taken to provide fault tolerance. 

Design Considerations with Backbone Support 

Backbone support is probably the most complicated infrastructure to design because it involves 

placing a logical routing infrastructure on top of an existing physical one. As was earlier shown in 

the section “Backbone Support”, Migration Agents utilizing backbone support mode rely heavily 

upon NLSP for routing information. However, this NLSP environment is a logical routing 

environment built upon an encapsulated IPX network. 

It is critical to understand the NLSP routing protocol to fully understand how Migration Agents set 

up in backbone support mode impact the network. For more information on NLSP itself, refer to 

both the protocol specification and some AppNotes Novell has published. Some important sources 

of information to review are as follows: 

• http://developer.novell.com/devres/langrp/specs.htm 

• http://developer.novell.com/research/appnotes/1995/november/a1frame.htm 

A common reason for using backbone support is to remove the IPX-based RIP/SAP broadcast 

traffic from WAN links to increase the performance of that link. Given that is the stated goal, it is 

imperative to ensure the Migration Agents are actually improving the performance of the link. It is 

possible to propose a design strategy where the Migration Agents actually decrease the 

performance of already congested WAN links. This must obviously be avoided at all costs. 

Note: It is possible to propose a design strategy with backbone support that actually requires more 

traffic for overhead than the existing RIP/SAP broadcast traffic. Every design strategy with 

backbone support must be evaluated to ensure it does not adversely affect WAN link performance. 



The way to evaluate the impact of backbone support on a CMD network is to determine the 

current RIP/SAP traffic on the WAN link and compare it to the overhead traffic required for 

NLSP. Consider the following example where Migration Agents in backbone support are used to 

remove IPX from a set of WAN links on an enterprise network. The general layout of the network 

is illustrated in Figure B17. It is a star network topology with a hub site and 99 remote sites 

connected by WAN links. 

Single CMD Network 

With 100 MA's Using 


MA w/ 

BS 

MA w/ 

BS 

MA w/ 

BS 



... 

MA w/ 

BS 



MA w/ 

BS 

MA w/ 

BS 

Figure B17. A single CMD network with 100 Migration Agents. 

Consider that the reason for deploying the backbone support strategy was to increase the 

performance of the WAN links because they had to support the broadcast of 5000 RIP routes and 

5000 SAP services. Of course, the RIP/SAP broadcast happens once per minute. To assess the 

impact of the old traffic pattern and the new one, look at the traffic for a single WAN link. 

Consider the link connecting the far-left server back to the hub site on the network. 

From an old IPX-based RIP/SAP perspective, the amount of traffic due to service broadcast can be 

easily calculated. For SAP packets, 7 SAP services can fit into a single SAP broadcast packet. 

Each SAP service is 64 bytes in length. Including the necessary overhead for the packet, each SAP 

broadcast packet is 494 bytes in length. With 5000 SAP services being advertised on the network, 

this translates into 5000 ÷ 7 (rounded up) x 494 bytes. This equals 353210 bytes per minute. 

Divide this by 60 to determine the number of bytes per second on the WAN link due to SAP. This 

value is 5887 bytes/sec. 

RIP traffic takes a bit less bandwidth than SAP. For RIP packets, 50 RIP routes can fit into a 

single RIP broadcast packet. Each RIP route is 8 bytes in length. Including the necessary overhead 

for the packet, each RIP broadcast packet is 446 bytes in length. With 5000 RIP routes being 

advertised on the network, this translates into 5000 ÷ 50 (rounded up) x 446 bytes. This equals 

44600 bytes per minute. Divide this by 60 to determine the number of bytes per second on the 

WAN link due to RIP. This value is 743 bytes/sec. 

To recap, the total traffic on a single WAN link due to RIP and SAP broadcast traffic is as 

follows: 

• SAP = 5000 ÷ 7 x 494 ÷ 60 = 5887 bytes/sec 

• RIP = 5000 ÷ 50 x 446 ÷ 60 = 743 bytes/sec

Thus the aggregate amount of traffic on the WAN link due to RIP and SAP is 6630 bytes/sec. This 

is a considerable amount of traffic for slow WAN links. 

Once the existing traffic has been calculated, it is necessary to calculate the traffic that will be 

incurred on the WAN link due the NLSP traffic from backbone support. From the design example, 

there are 100 Migration Agents belonging to the same CMD network. From an NLSP perspective, 

this means that each IPX router believes it has 99 NLSP neighbors. This will impact the traffic 

calculation significantly. 

The calculations that should be conducted involve the steady state of the NLSP environment. 

There is obviously going to be a much larger amount of traffic when the NLSP environment is in 

its initialization state, but after the initialization, the general cost of NLSP is realized in the steady 

state environment. 

When discussing the steady state, there are two types of packets that are sent out on a regular 

basis. They are as follows: 

• NLSP Hello Packet—this packet is an advertisement of an NLSP router to its neighbors 

notifying the neighbors that it is still alive. This packet forces the neighbors to update the 

TTL of the sending NLSP router. By default, NLSP routers will send out NLSP Hello 

packets once every 20 seconds (with jitter to avoid simultaneous broadcast). The NLSP 

designated router for the area sends out NLSP Hello packets once every 10 seconds. 

• NLSP Complete Sequence Number Packet (CSNP)—this packet is sent out by the 

designated router once every 30 seconds. The CSNP is a brief summary of the designated 

router’s link state database, which includes a list of LSP numbers, sequence numbers, and 

checksums. NLSP routers in the area compare their link state database against the CSNP. 

If the router’s information is different than that contained in the CSNP, the router will 

update its link state database from the designated router’s link state database. 

Normally these packets are broadcast based packets; however, in the encapsulated IPX network, 

this information is directed unicast to each neighbor in the environment. As the number of 

Migration Agents with backbone support in a single CMD network increases, the traffic due to 

overhead increases exponentially. 

Given the example illustrated in Figure B17, each Migration Agent has 99 neighbors to whom it 

must send a unicast NLSP Hello packet. In turn, it receives back 99 NLSP Hello packets from its 

neighbors. This all happens within a 20-second period on the network. It is important to 

understand the impact this has on a single WAN link. To calculate the traffic, the size of the NLSP 

Hello packet must be calculated. 

There are two parts to the NLSP Hello packet. One is a fixed length, and the other is a variable 

length part of the packet. The fixed length of the packet consists of packet overhead and the Local 

MTU option. Packet overhead is 27 bytes and the Local MTU option is 6 bytes. In the variable 

length part of the packet, the Area Addresses option can be ignored because it is rarely used. This 

leaves the Neighbors part of the packet. Each neighbor of the NLSP router will be listed in this 

portion of the packet. Each neighbor will occupy 6 bytes of the packet. Since there are 99 

neighbors in the example, the size due to the neighbor list is 594 bytes plus one parity bit for a 

total of 595 bytes. Adding these together, the size of the NLSP Hello packet for the example is 

628 bytes. 

628 bytes would be the normal size of the packet if NLSP were able to operate in a normal IPX 

environment; however, the packet must still be encapsulated in a UDP header. This UDP header 

will add another 48 bytes to the packet size. The total size for each encapsulated NLSP Hello 

packet is 676 bytes. In general, use the following equation to calculate the size of each 

encapsulated NLSP Hello packet in the designed backbone support environment: 

Encapsulated NLSP Hello packet size = 27 + 6 + (6*(# of MA’s – 1) + 1) + 48 



In the example provided, each Migration Agent will see 198 of these packets every 20 seconds. 

This translates into 676 x 198 ÷ 20 bytes per second, which equals 6692 bytes per second due to 

the encapsulated NLSP Hello packet traffic. In general, the way to calculate the total traffic (in 

bytes per second) on a WAN link due to encapsulated NLSP Hello packet traffic is shown by the 

equation below: 

Total NLSP Hello packet traffic = (Encapsulated NLSP Hello packet size) * (# of MA’s – 1) ÷ 

20 

The other piece of overhead traffic due to NLSP is because of the CSNP. The calculation of the 

CSNP packet is not as easy as the NLSP Hello packet. The CSNP also has a fixed and a variable 

length part. In the variable length part there is an option called LSP Entries, which has some 

minimum information about all the Link State Packets (LSPs) in the link state database. The 

packet size will depend upon the number of LSPs in the database. To determine this, take the 

number of RIPs and SAPs on the network, as these are stored in LSPs. If the assumption is made 

that there are 5000 services and 5000 networks in the network, then number of approximate LSPs 

in the link state database can be calculated. 

The fixed part of the LSP packet is 27 bytes, and the LSP packet has a default size of 1024 bytes. 

Therefore, the available space to store RIP and SAP information is 1024 - 27(fixed part) - 20 (IPX 

header), which equals 977 bytes. Each SAP option in the LSP packet will take 64 bytes of space, 

and each route option will occupy 8 bytes of the packet. To store 5000 SAPs and 5000 RIPs 

360000 bytes will be needed (5000*64 + 5000*8). This can be stored in 369 LSPs, which is 

360000 bytes ÷ 977 bytes. Not all SAPs and RIPs will be accommodated in 369 LSPs. Assuming 

this happens, it is safe to assume 400 LSPs will be required to store 5000 services and 5000 routes. 

In general, the number of LSPs required to represent the link state database can be approximated 

by the following equation: 

Number of LSPs = ((# of SAPs x 64) + (# of RIPs x 8)) ÷ 977 

Increase that value by 10% to account for not every LSP being fully packed with RIP and SAP 

information. 

Once the number of LSPs has been approximated, the CSNP size can be calculated. Each LSP 

option will occupy 16 bytes. In most cases all the LSP information can be contained in one CSNP 

packet; however, the MTU limit will be exceeded, which means the CSNP may be broken up into 

multiple packets on the wire. This possibility needs to be calculated. To do this, take the size of 

the CSNP on the wire, which is 1500 bytes, and determine the fixed packet information. The 

header information and fixed part of the CSNP requires 81 bytes. 33 bytes are for the fixed part of 

the CSNP; 48 bytes are for the header information. This leaves 1419 bytes to store LSP summary 

information in the CSNP. 1419 bytes can fit information about 88 LSPs. This is calculated by 

1419 ÷ 16. Take the total number of LSPs representing the link state database and divide it by the 

number of LSPs that can be represented in a physical packet. The number calculated represents the 

number of physical packets required to transmit the CSNP on the wire: 

# of packets to transmit CSNP= (# of LSPs in link state database) ÷ 88 

Each physical packet for the CSNP will use 1500 bytes of bandwidth. To calculate the amount of 

bandwidth due to the CSNP on a WAN link, use the following equation: 

CSNP bandwidth = 1500 x (# of packets to transmit CSNP) ÷ 30 

For the current design example, 400 LSPs are required for the link state database. The bandwidth 

required for the CSNP is 1500 x 5, which equals 7500 bytes. This happens once every 30 seconds, 

so the bandwidth equals 250 bytes/second. 



Note: This is the bandwidth required to transmit the CSNP from the designated router to a single 

Migration Agent on the network. To get the aggregate bandwidth required for the entire network 

to transmit the CSNP, multiply the CSNP bandwidth from above by the number of Migration 

Agents on the network. 

Therefore, the steady state NLSP traffic for the design example is calculated by adding the traffic 

from the NLSP Hello packet and the traffic from the transmission of the CSNP: 

Total steady state NLSP traffic = NLSP Hello traffic + CSNP transmission traffic 

For the design example, the total steady state NLSP traffic is 6692 + 250, which equals 6942 

bytes/second. Comparing this to the amount of current RIP/SAP traffic (6630 bytes/second), the 

new backbone support design actually incurs more overhead traffic than the original IPX 

environment. This is obviously a poor design. 

The point to remember is this comparison of information accounts only for the steady state of 

NLSP. It does not address the following NLSP issues, which will impact the amount of traffic on 

the network: 

• The NLSP initialization state will place more of a load on the network; however, it is 

temporary. Once the steady state is reached, the system exhibits a behavior that closely 

resembles that of the above study. 

• The traffic incurred by a dynamically changing network. The study does not address the 

normal delta traffic in an NLSP environment. 

• The normal update of the link state database. Once every 2 hours, the designated router 

will send its complete link state database to its neighbors. Normally, this is accomplished 

through broadcasting the database, but in the CMD environment the broadcast packet 

becomes multiple unicast directed packets. 

• The client SLP traffic required every 5 minutes for the Migration Agent to locate other 

Migration Agents on the network. Depending upon scope size, this could contribute to 

the amount of traffic on the WAN link. 

The designated router is responsible for a lot of the NLSP overhead required maintaining the 

routing environment. It is recommended that the designated router be at a hub site on the 

enterprise network. This is because the designated router for the NLSP neighborhood is 

responsible for generating and disseminating a large amount of information. The area of the 

network that holds the designated router is going to see more traffic due to NLSP overhead than 

areas that hold a subordinate NLSP router (in this case a Migration Agent). 

Of course, the example described here illustrates the need to minimize the number of Migration 

Agents on the same CMD network. This can be accomplished through the regionalization of CMD 

networks on the existing physical routing structure. For more information about deploying 

regional CMD networks, refer to the article “Removing IPX from WAN Segments During an 

Upgrade to NetWare 5: A Case Study”, which can be found in the September 1999 issue of 

AppNotes. It can also be found at the following URL: 

• http://developer.novell.com/research/appnotes/1999/septembe/a4frame.htm 

In the future, Migration Agents will also be able to handle multiple CMD networks. Instead of 

having Migration Agents share a common IPX segment to exchange bindery information, the 

Migration Agent will be able to do it internally. This will reduce the amount of hardware required 

to implement a regional CMD network approach. 

The most important thing to consider in proposing a backbone support infrastructure is the impact 

it will have on the network. The design must use the information gathered in the PFC to provide a 

relevant solution to the environment. Some other important points to consider are as follows: 



• Migration Agents in backbone support mode effectively act as IPX routers. From a 

communications point of view, they also become a point of failure. If the physical router 

is up but the Migration Agent is not available, clients dependent upon that Migration 

Agent will not be able to connect to non-contiguous IPX portions of the network. 

• The impact of the virtual NLSP routing environment may be more severe than initially 

calculated. If the designated router for the CMD network is located across a slow WAN 

link from all of its neighbors, the slow WAN link will bear a large brunt of the NLSP 

overhead traffic. Also, if the physical routing environment resembles the one illustrated 

in Figure B18, there may be links that are more affected by the NLSP overhead traffic 

than others. 

• The design and implementation of a backbone support structure requires a high cost in 

development, configuration, and maintenance. The resulting infrastructure built must 

improve the performance of the WAN links for the client, or the implementation of such 

a structure is not worth the investment. 





Router 

Router 

Router Router 



Router 

Router 





Figure B18. Sections of the physical WAN environment may carry more NLSP overhead traffic than 

others. 

In Figure B18, the section of the physical WAN infrastructure between the two central routers will 

bear the brunt of NLSP overhead traffic more than the leaf network segments where the Migration 

Agents are located. This must be factored into any backbone support design. It is critical to look at 

the WAN and site maps provided by the client before designing the backbone support 


Note: One driving force behind the removal of IPX from WAN links is to increase link 

performance through the elimination of RIP/SAP overhead traffic. Given this, the backbone 

support design with NLSP must reduce that original overhead traffic by at least 50% for the design 

to be effective. If this figure cannot be reached, implement the dual stack migration strategy.

Appendix C—ACU Client Deployment 

Other good resources are: 

• TID 2942060 “Automatic Client Upgrade” 

• Search http://support.novell.com under keyword ACU 

• http://www.novell.com/coolsolutions/zenworks/features/a_basics_acu_zw.html “How to 

do an ACU using NCIMan” 

Novell’s Automatic Client Upgrade (ACU) provides a way to automatically upgrade to the latest 

Novell Client software without a visit to each workstation. ACU is a process that is initiated by a 

“switch” available with the Novell client software setup programs, i.e.: 

• SETUP.EXE /ACU (Windows 9x) 

• SETUPNW.EXE /ACU (Windows NT) 

• INSTALL.EXE /ACU (DOS/Windows 3.x). 

NCIMan ( N ovell C lient I nstall Man ager) is a GUI-based utility that can be used for creating 

Windows 9x or Windows NT UNATTEND.TXT files for use with the ACU process; there is no 

NCIMan for DOS/Windows 3.x. NCIMan ships with the ZENworks 1.0+ Client software. Prior 

to NCIMan, the UNATTEND.TXT file was manually created and/or edited from a sample 

UNATTEND.TXT file. The goal of the UNATTEND.TXT file is to set configuration options and 

answers to client installation questions, so that the user is not prompted for this information. 



ACU Configuration Steps 

The following tasks will help you to ensure an orderly upgrade of the client software. The 

completed charts and appropriate login script(s) can be given to the customer as part of their 

report. 

Task 1: Determine and document which client software/version the customer is currently running 

that needs to be upgraded and whether or not this current client software is Bindery- or NDSbased, 

which in turn determines the login script to use for ACU commands. 

Current Client Version NDS-Based Bindery-Based Login Script to use 

for ACU 

Commands 

Novell Client for 

Windows 95/98 


Windows NT 


DOS/Windows 

Microsoft Client 

Virtual Loadable 

Modules (VLMs) 

NETx 

Other 

• If current clients are Bindery-based, the ACU commands go in the system login script 

(SYS:PUBLIC\NET$LOG.DAT). The ACU commands could go into user login scripts, 

(SYS:MAIL\) but this requires a lot of administrative effort. 

• If current clients are NDS-based, the ACU commands go into either a container or profile 

login script. The ACU commands could go into user login scripts, but this requires a lot 

of administrative effort. 



Task 2: Determine and document which version of the client software will be installed using the 

ACU. This task determines whether or not NCIMan can be used. For the latest client versions, 

please refer to one of these sites: 

Client to be Installed 

with ACU 


Windows 9x 


Windows NT/2000 


DOS/Windows 3.x 

Other 

• http://support.novell.com – minimum patch list 

• http://www.novell.com/download 

• http://support.novell.com/Ftp/Updates/nw/nwclients/Date0.html 

Version NCIMan Can Be Used Comments 

• If you are upgrading to the Novell Client for Windows 9x 2.5+ -- NCIMan can be used. 

• If you are upgrading to the Novell Client for Windows NT 4.3+ (which only runs on 

Windows NT 4.0+) -- NCIMan can be used. 

• If you are upgrading to the Novell Client for Windows NT 4.11b (which only runs on 

Windows NT 3.51) -- NCIMan cannot be used. In this case, you will need to manually 

create the UNATTEND.TXT file. 

• If you are upgrading to the Client for DOS/Windows 3.x 2.5+ -- NCIMan cannot be used. 

. In this case, you will need to manually create the UNATTEND.TXT file. 



Task 3: Preliminary Tasks Before Performing an ACU 

• Login to a server as Admin or a user with Admin equivalence. You will need to have 

sufficient rights to copy files and to modify login scripts. 

• On the appropriate NetWare server(s), create a client directory and copy the latest client 

software, e.g.: 

• SYS:PUBLIC\CLIENT\WIN95 

• SYS:PUBLIC\CLIENT\WINNT 

• Copy the *.CAB files to the appropriate directories. 

• Ensure that users who are scheduled for automatic upgrades have Read and File Scan file 

system rights to the appropriate directories. 

• Determine the appropriate parameters that should go into the UNATTEND.TXT file. 

Use the on-line help that ships with the Novell client software for a listing or the on-line 

help from NCIMan. In addition to the customized settings necessary for your 

environment (e.g., Preferred Server, Preferred Tree, Name Context, etc.), it is recommend 

that your UNATTEND.TXT file(s) install the following components for Windows NT: 

• Workstation Manager component (Workstation Manager 1.1) 

• Workstation Manager allows you to use Policy Package objects to manage your users and 

workstations via ZENworks and NDS. 

• NAL component (also known as the NAL NT Service Process) 

• The NAL NT Service Process allows NAL to distribute software without having the users 

be members of the NT Administrators group. When it is successfully installed, it will 

show up as an NT Process on the NT workstation. It is a one-time installation process on 

the NT workstations. 

• Checking the NWSETUP.INI File for Windows 9x 

• SETUP.EXE reads a configuration file named NWSETUP.INI to get information such as 

where the drivers will be copied to during the installation. NWSETUP.INI is located in 

the same directory as SETUP.EXE. The ACU uses the portion of NWSETUP.INI 

displayed below to determine if the workstation should be upgraded: 

• [ClientVersion] 

Version=0.1.0.0 

• There are four fields that can be used to identify the version of the client running on a 

workstation: MajorVersion, MinorVersion, Revision, and Level. These are specified 

under the [ClientVersion] heading in the format: Version=x.x.x.x. 

• Registry Settings for Windows 9x 

If you have already installed the IntranetWare Client for Windows 95 (or later), you will 

see keys corresponding to the Level, Major Version, Minor Version and Revision 

specified in the NWSETUP.INI file. 

These keys are found in the path HKEY_LOCAL_MACHINE | Network | Novell | 

System Config | Install | Client Version, as shown in the following sample screen. 

Level 0x00000000 (0) 

Major Version 0x00000000 (0) 

Minor Version 0x00000001 (1) 

Revision 0x00000000 (0) 

Note: REGEDIT lists the same four version fields as are found in the NWSETUP.INI 

file, only here they are in alphabetical order and the values are specified in both 

hexadecimal and decimal notation. 

SETUP.EXE compares the values in the Registry with the values in NWSETUP.INI to 

determine whether the ACU process should run. The ACU process runs only when 



SETUP.EXE determines that the values in the Registry either do not exist or contain 

values less than those in the NWSETUP.INI file. 

If the values were set as shown in the previous two screen shots, the ACU process would 

not run because the Registry contains the same values in the Client Version fields as are 

specified in NWSETUP.INI (0.1.0.0 in both places). If you have newer files that need to 

be installed on this workstation, you need to change either the values in the Registry or 

those in the NWSETUP.INI file so that the version in NWSETUP.INI is greater than the 

corresponding version in the Registry. For example, 1.1.1.1 is greater than 1.1.1.0, and 

1.1.2.0 is greater than 1.1.1.9999. 

When the ACU finishes, it changes the settings in the Registry to match those in the 

NWSETUP.INI file. After the workstation is rebooted and the login script is processed 

again, the ACU will not be run because SETUP.EXE detects that the Registry now 

contains the same settings as NWSETUP.INI. 



Task 4: Using ACU to Upgrade the Novell Client for Windows NT 4.10-4.11 

Note: This task assumes that the customer’s current client is the Novell Client for Windows NT 

4.10 or 4.11. If the customer’s current client is not 4.10 or 4.11, go to Task 5. 

Note: You cannot use NCIMan to create/edit the UNATTEND.TXT file with this client (4.10- 

4.11). 

Caution: After the Novell Client for Windows NT 4.10-4.11 software has been upgraded, the 

new clients will not read any of the “old” NT Configuration objects that may be in place; 

therefore, you will need to have ZENworks installed and user policy package objects set up in the 

tree prior to upgrading the client software so that the “workstation manager” feature is not 

disrupted. Here is the scenario: 

• The Novell Client for Windows NT versions 4.3+ cannot access Workstation Manager 

1.0 objects. (Workstation Manager was a component of the Novell Client for Windows 

NT 4.10-4.11 software.) These 4.3+ clients can only access the ZENworks 1.0+ 

Dynamic Local User (DLU) Policy (aka Workstation Manager 1.1 objects). 

• The Novell Client for Windows NT versions 4.10-4.11 cannot access the ZENworks 1.0+ 

Dynamic Local User (DLU) Policy (aka Workstation Manager 1.1 objects). These clients 

can only access Workstation Manager 1.0 objects, which are enabled as part of the Novell 

Client for Windows NT versions 4.10-4.11. 

With Windows NT clients, security comes into play in that the workstation that is to be upgraded 

requires appropriate rights to install the client software. 

Q: Do the users have local NT Workstation Administrator rights? 

Yes: Nothing special as far as security goes needs to be done, since the users already have 

local NT Workstation Administrator rights to upgrade their client software. 

Process: 

• Manually create (or copy and edit the sample) UNATTEND.TXT file that will be 

“read” by the ACU process. 

• Place the UNATTEND.TXT file in a location on the network where users have Read 

and File Scan rights, e.g., SYS:PUBLIC\ACU. 

• Mark the Enable Automatic Client Upgrade box of the Client Configuration object. 

• In the Alternate Login Script Location box, specify the UNATTEND.TXT file that 

you just created. Note: This field is required; you will get an error message if this 

field is not filled in. 

Note: You must use the older NWAdmnNT utility for creating and managing NT 

Configuration objects - not NWAdmn32. 

No: Two different possibilities and associated solutions: 

(1) Users who have the Novell Client for Windows NT 4.10 or 4.11 and have 

Workstation Manager 1.0 installed with the appropriate Trusted Tree. 

In this scenario, an ACU is possible even if the users don’t have administrative rights 

to the NT Workstation. This is accomplished by using the Client Upgrade property 

of the NT Configuration object. With this option enabled, the Novell Client for 

Windows NT creates a temporary account with administrative rights on the NT 

Workstation and it uses this account to run the client installation program. Once the 



installation is complete, the NT Workstation is rebooted and the user then logs in 

normally. 

Process: 

• Manually create (or copy and edit the sample) UNATTEND.TXT file that will be 

“read” by the ACU process. 



• Mark the Enable Automatic Client Upgrade box of the Client Configuration object. 

• In the Alternate Login Script Location box, specify the UNATTEND.TXT file that 

you just created. Note: This field is required; you will get an error message if this 

field is not filled in. 

Note: You must use the older NWAdmnNT utility for creating and managing NT 

Configuration objects - not NWAdmn32. 

(2) Users who have the Novell Client for Windows NT 4.10 or 4.11 but do not have 

Workstation Manager 1.0 installed and are not members of the local NT 

Administrators group. Additionally, these NT workstations are not part of an NT 

Server Domain. 

In this case, the update to the Novell Client for Windows NT will require a visit to 

the desktop. This is because installing Workstation Manager requires NT 

Workstation Administrator rights and there is no automatic way to make the user a 

member of the NT Administrators group. 

POSSIBLE WORK-AROUNDS TO TEST OUT: 

• There is a way to enable the workstation manager. The 4.11 client has a policy 

template to enable the workstation manager and to set the tree name. I think the 

name of the file is NWNT.ADM and is located in the admin directory. Create a 

NWCONFIG.POL file with POLEDIT and copy the file to the 

SYS:PUBLIC\WINNT directory of the default servers and all logged-in clients 

have workstation manager enabled. 

• Use NAL and the NAL NT Service Process to distribute the client software. 

This assumes the NAL NT Service Process is not dependent upon a client 

version 

• A Microsoft or third party utility (such as SU) that temporarily gives users 

administrative privileges. 

Available Switches for SETUPNW.EXE include: 

• /? Displays list of available switches 

• /ACU Automatic Client Upgrade 

• /U Use default UNATTEND.TXT file 

• /U: 

• /W: Trusted Tree - to enable Workstation Manager 



Task 5: Using ACU and NCIMan to Upgrade to the Novell Client for Windows NT 4.3+ 

Note: This task assumes that the customer’s current client is the Novell Client for Windows NT 

4.3+. If the customer’s current client is not 4.3+, go back to Task 4. 

Note: You can use NCIMan to create/edit the UNATTEND.TXT file with this client (4.3+). 

With Windows NT clients, security comes into play in that the workstation that is to be upgraded 

requires appropriate rights to install the client software. 

Q: Do the users have local NT Workstation Administrator rights? 

Yes: Nothing special as far as security goes needs to be done, since the users already have 

local NT Workstation Administrator rights to upgrade their client software. 

Process: 

• Use NCIMan to create the appropriate UNATTEND.TXT file. 



• Go to “Update Login Scripts”. 

No: This can be done with the new ZENworks Policy Package by scheduling 

SETUPNW.EXE to run with a “System” or an “Unsecure System” impersonation. 

Process: 

• Open a WINNT User Policy Package (or a WINNT Workstation Policy Package) 

• Click on the “Add action...” button, type “NT Client ACU” and click on the “Create” 

button 

• Double click on the “NT Client ACU” policy you just created and then click on the 

“Details” button 

• Select “Unsecure System” in the Impersonation drop down list. Unsecure System 

allows system rights for installation yet gives screen prompts for installation progress 

and user intervention if needed. 

• Choose the “Items” tab and then click on the “Add...” button 

• Enter the path to the executable in the “Name” field, e.g.: 

• \\servername\SYS\Public\Client\Winnt\i386\setupnw.exe 

• Enter any startup options in the “Parameters” field, e.g.: 

• /ACU /U:unattend.txt 

• Choose the “Schedule” tab to specify when you want the client update to occur, e.g.: 

• Executed when the user logs in 

• Note: Disable the use of the “Default package schedule” in this case 

• Choose the “Advanced” tab to specify any other options, e.g.: “Disable the action 

after completion” and “Reboot after completion” 


Now, the next time the user logs in, SETUPNW.EXE will execute with administrative 

rights to the NT Workstation. When the installation is done, the NT Workstation will be 

rebooted and the user will log in normally. 



ANOTHER SOLUTION TO TEST OUT: 

• Use NAL and the NAL NT Service Process to distribute the client software. 

Available Switches for SETUPNW.EXE include: 


• /ACU (Automatic Client Upgrade) 

• /U Use default UNATTEND.TXT file 

• /U: 

• /W:Trusted Tree - to enable Workstation Manager 



Task 6: Using ACU and NCIMan to Upgrade to the Novell Client for Windows 9x 2.5+ 

Note: This task assumes that the customer’s current client is the Novell Client for Windows 9x 

2.5+. 

Note: You can use NCIMan to create/edit the UNATTEND.TXT file with this client. 

With Windows 9x clients, security is not an issue for installing the client software. 

Process: 

• Use NCIMan to create the appropriate UNATTEND.TXT file. 

• Place the UNATTEND.TXT file in a location on the network where users have Read and 

File Scan rights, e.g., SYS:PUBLIC\ACU. 


Available switches for SETUP.EXE include: 


• /ACU Automatic Client Upgrade 

• /NCF No Cab Fix - The fix to prevent the copying of CAB files will not be applied 

• /RB Roll Back - to previous Client if Client installation fails 

• /U: 



Task 7: Using ACU to Upgrade to the Novell Client for DOS/Windows 3.x 2.5+ 

Note: This task assumes that the customer’s current client is the Novell Client for DOS/Windows 

3.x 2.5+. 

Note: You cannot use NCIMan to create/edit the UNATTEND.TXT file with the DOS/Windows 

3.x client. 

With DOS/Windows 3.x clients, security is not an issue for installing the client software. 

Process: 

• Manually create (or copy and edit the sample) UNATTEND.TXT file that will be “read” 

by the ACU process. 

• Place the UNATTEND.TXT file in a location on the network where users have Read and 

File Scan rights, e.g., SYS:PUBLIC\ACU. 


Note: This login script does not contain commands for determining the DOS/Windows 

3.x clients. 



“ Update Login Scripts ” 

A simplified example follows, showing the key components necessary. Testing in the lab 

environment will be required for the customer’s specific needs. 

Note: This login script was placed in this order for readability purposes; it may not execute as 

written. 

REM The following is the OS or Platform Check for Windows NT 

REM Check to see if a Novell Client is currently installed: 

IF “%OS” = “WINNT” THEN GOTO WINNTC32 

END 

WINNTC32: 

REM The following should be one line in your Login Script: 

@\\zensrvr\sys\public\client\winnt\i386\SETUPNW.EXE /ACU 

/U:\\zensrvr\sys\public\client\winnt\i386\nls\english\UNATTEND.TXT 

EXIT 

REM Check to see if a Microsoft Client is currently installed: 

IF = “Windows_NT” THEN GOTO WINNTMSC 

END 

WINNTMSC: 

MAP L:=zensrvr\sys:public\client\winnt\i386 

DRIVE L 

#SETUPNW.EXE /ACU /U:L:\nls\english\UNATTEND.TXT 

EXIT 

REM The following is the OS or Platform Check for Windows 98 


IF "%OS" = "WIN98" THEN GOTO W98C32 

END 

W98C32: 


@\\zensrvr\sys\public\client\win98\ibm_enu\SETUP.EXE /ACU /NCF 

/U:\\zensrvr\sys\public\client\win98\ibm_enu\UNATTEND.TXT 

EXIT 


IF = "C:\WINDOWS" OR = "C:\WIN98" THEN GOTO 

MSCLIENT98 

END 

MSCLIENT98: 

MAP Y:=ZENSRVR\SYS:PUBLIC\CLIENT\WIN98\IBM_ENU 

DRIVE Y 


#SETUP.EXE /ACU /NCF 


EXIT 



REM The following is the OS or Platform Check for Windows 95" 


IF "%OS" = "WIN95" THEN GOTO W95C32 

END 

W95C32: 


@\\zensrvr\sys\public\client\win95\ibm_enu\SETUP.EXE /ACU /NCF 


EXIT 


IF = "C:\WINDOWS" OR = "C:\WIN95" THEN GOTO 

MSCLIENT95 

END 

MSCLIENT95: 

MAP Y:=ZENSRVR\SYS:PUBLIC\CLIENT\WIN95\IBM_ENU 

DRIVE Y 


#SETUP.EXE /ACU /NCF 


EXIT 

REM This checks for Windows 3.x platform 

IF PLATFORM "WIN" THEN BEGIN 

WRITE "This is not Windows 95-98 or Windows NT" 

WRITE "This is Windows 3.x" 

WRITE "You are seeing this because you are not using a" 

WRITE "supported desktop operating system" 

WRITE "Please call your network administrator or the help" 

WRITE "desk and report this message" 

PAUSE 

END 

EXIT 



Upgrading to 32-Bit ODI Drivers 

You can use ACU to automate an upgrade from a 16-bit LAN driver configuration to a 32-bit ODI 

driver. Here are the steps: 

• With a text editor, open the NWSETUP.INI file (located in the same directory as the 

Windows 9x client software) 

(portion of the nwsetup.ini) 

[INF Files] 

1=NWClient.inf 

2=NWTrans.inf 

3=ODINSUP.inf 

4=NE3200.inf 

;5=NE2000.inf 

;6=NE15_21.inf 

;7=NE2.inf 

Find the line under the [INF Files] heading that corresponds to your network adapter. For 

example, if you have a 3Com EtherLink III adapter, the line is: 

;19=ODI3COM.inf 

Remove the semicolon (;) from the line. This causes SETUP.EXE to copy that INF file to 

the C:\WINDOWS\INF directory, where it can be used to install and configure the 32-bit 

ODI driver. 

• Copy the 32-bit driver *.LAN file (such as 3C5X9.LAN) to the ACU install directory. 

Add the “/o” command line parameter to the login script command that calls SETUP, as 

in the following example: 

#\\prv-client\sys\public\client\c32win95\ setup.exe /acu /o 

The “/o” parameter instructs SETUP to override the NDIS default and will install the 

IntranetWare Client with a 32-bit ODI driver. 



Appendix D—SLP 

A Detailed Overview of SLP 

Note: You can proceed to the “SLP Design” section if you are already familiar with SLP. 

Before proposing any SLP infrastructure design, it is important to fully understand the SLP 

standard, how Novell has implemented that standard, and the impact SLP will have on a large 

network environment. This information follows: 

Service Location Protocol (SLP) 

In the IPX realm, services are advertised on a periodic basis through the use of the service 

advertisement protocol (SAP). This protocol is broadcast out on the network once per minute by 

all services on the network. The reason for this is so services are aware of all other services on the 

network dynamically. Address tables for services are not statically configured on a per server basis 

as it drastically increases the administrative overhead for large networks. 

Large networks have problems with IPX because of this dynamic discovery of information. With 

thousands of IPX-based services on the network, the amount of network bandwidth used by this 

service advertisement becomes significant. This is a major drawback to the scalability of IPX and 

SAP on a corporate network. 

The TCP/IP protocol suite itself does not have a mechanism for the advertisement of services. IP 

hosts generally learn about other IP hosts through statically configured files. This is not an 

acceptable solution in NetWare 5.1 for the discovery of services, as customers have become 

accustomed to the dynamic discovery mechanisms of IPX and SAP. Fortunately, there is an IPbased 

mechanism of dynamic service resolution based upon an IETF standard. That mechanism is 

the Service Location Protocol (SLP). 

To draw a crude analogy, SLP is to IP networks what SAP is to IPX networks. IP-based clients 

and servers on the network can find out about all other services on the network through SLP 

queries. But unlike SAP, SLP has some properties that make it a more attractive service location 

protocol: 

• SLP is a passive protocol, which is unlike the active SAP protocol. SAP forces itself out 

on the wire once per minute to advertise services. SLP is found on the wire only when 

user agents need to retrieve a list of available services on the network. 

• SLP is a pull technology, whereas SAP is a push technology. Pull technologies lend 

themselves better to the tailoring and customization of queries than push technologies. 

This provides for much more efficient use of network bandwidth because a pull 

technology like SLP places only useful information on the wire. A push technology like 

SAP tries to place all information needed for any query on the wire, whether it is truly 

needed or not. 

But this better technology comes at a cost. That cost is either an administrative cost or a network 

bandwidth cost. SLP can use different types of TCP/IP packets to facilitate a service resolution 

infrastructure. There are three types of packets in TCP/IP that can be used for communication 

between hosts. They are as follows: 

• Unicast—this is a directed packet between two hosts on the network. The packet is 

addressed specifically to the destination host. All other hosts on the network that see the 

packet ignore it. 



• Broadcast—this is a general packet destined for all hosts on the same network as the 

sending host. Every host on the same network must process the packet. Broadcast storms 

can affect machine performance because CPU cycles must be spent processing the 

packets coming into the host. 

• Multicast—this packet is designed to reach a group of hosts on the network. There is a 

reserved range of IP addresses whose first octet ranges from 224 to 239. These addresses 

are multicast addresses, which is a way to logically identify a group of hosts on the 

network. Hosts on the network join the group upon booting, and when a packet is 

addressed to a specific multicast address, all members of the multicast group receive the 

packet. Non-members that see the packet ignore it. 

For SLP to work without any administrative overhead as SAP currently does, multicast must be 

enabled on the network to facilitate communications between user and service agents. If multicast 

is not an option, then a directory agent must be configured for the network, and the service agents 

on the network must be configured to find the directory agent. While multicast is the “out of the 

box” method of communication for SLP, it may not be the most efficient solution for a given 

environment. The inner workings of SLP will be discussed in the next sections. 

When Is SLP Required on a Network? 

When a pure IP NetWare environment is achieved, both clients and servers need a method for 

discovering services on a network. There are a number of ways that these services can be resolved, 

and many people choose to use a combination of service resolution mechanisms. The service 

mechanisms that can be used in a pure IP NetWare environment are as follows: 

• NWHOSTS file—the NWHOSTS file functions in the same manner the normal TCP/IP 

HOSTS file does. All IP addresses of all machines on the network are stored in this file, 

which is located locally on each workstation and server. This is not the optimal method 

for service resolution as this file needs to be updated and distributed every time there is a 

new machine added to the network or an existing machine’s address is modified. 

• Domain Name Service (DNS)—machines can use DNS to resolve fully qualified 

hostnames to IP addresses. Thus, a client attempting to map a drive to fs1.ey.com would 

resolve that address against the DNS servers. Once the address was resolved, the 

workstation would attempt to connect to the server defined by that IP address. 

• Dynamic Host Control Protocol (DHCP)—DHCP can be used to disseminate preferred 

server or preferred tree information to workstations. No resolution of services is 

necessary upon initial login because the IP address to which the workstation is 

connecting is already known. 

• Novell Directory Services (NDS)—NDS can be used as a service resolution mechanism. 

Once a workstation has been authenticated to the NDS tree, the user can walk to the NDS 

tree to find services available on the network. This process is accomplished through NDS 

and its tree walking capabilities; no extra configuration is required on the client. 

• Service Location Protocol (SLP)—as has already been mentioned SLP is an excellent 

method of service discovery in a pure IP NetWare environment. Once configured, the 

infrastructure needs a minimal amount of care and administration to function properly. 

Since all of these service resolution mechanisms are available, it is a logical question to ask, “Why 

is SLP needed in an enterprise network?” There are a number of reasons why SLP is 

recommended (and in some cases required) for large environments. They are listed below: 

• Efficiency of Directory Services—In the experiences Novell has had with large scale 

implementations of NetWare 5.1, it has been shown that DS runs more efficiently with an 

SLP infrastructure in place that servers can use for service resolution. 

• Short Name Resolution—if users are accustomed to using only the server’s name to 

access services on the network, this is called short name resolution. For instance, if a user 

were mapping a drive to the SYS volume of FS1 using Universal Naming Convention 



(UNC), the syntax would look like \\FS1\SYS. Because only the short name of the server 

is specified, this is an SLP dependent function if no other short name resolution protocol, 

such as DNS or SAP, is available. Without an SLP infrastructure in place, the drive 

mapping operation would fail. 

• Browsing—if users are accustomed to finding network resources through such utilities as 

Network Neighborhood, this is called a network browse function. For instance, if a user 

would access a server by double clicking on Network Neighborhood->Entire Network- 

>NetWare Services->NetWare Servers, this is an SLP dependent function if no other 

short name resolution protocol, such as IPX or SAP, is available. Without an SLP 

infrastructure in place, this browsing capability would be lost. 

• Compatibility Mode—for organizations that are migrating from an IPX environment to a 

pure IP environment, there are different migration paths available. One of those migration 

strategies is to use the Compatibility Mode Driver provided by Novell to allow machines 

that are strictly using the IP protocol to communicate with machines and applications 

using only the IPX protocol for NetWare services. If this migration strategy is chosen, the 

Compatibility Mode Driver is SLP dependent. Without an SLP infrastructure in place, the 

Compatibility Mode Driver would not work properly. 

For a lot of organizations, short name resolution and browsing are functional requirements in a 

pure IP environment. A number will also make use of the compatibility mode driver as a migration 

strategy to achieve a pure IP environment. For these reasons, a comprehensive, robust SLP 

infrastructure is required. At the same time, DS will be much more efficient because it will have 

an SLP infrastructure to use. Even in a dual stack configuration, an SLP infrastructure will 

improve the performance of the client and facilitate the preference of the IP protocol. 

Note: A design criterion for NDS was to make it not dependent upon SLP. An SLP infrastructure 

will make NDS more efficient. However, there may be other services that are dependent upon 

SLP. For that reason, Novell recommends that an SLP infrastructure be implemented for all 

environments where IP is the preferred protocol. 

Understanding SLP Basics 

As mentioned previously, SLP is an open standard defined by the IETF. For more detailed 

information on SLP including advanced theory and packet construct information, please refer to 

RFC 2165 on the IETF web site, http://www.ietf.org/. 

There are three main components to the SLP methodology. The required components in an SLP 

network are the user agent and the service agent. The directory agent (optional) is a useful 

construct that must be implemented on an enterprise network for scalability and efficiency. 

Without the directory agent, the overhead traffic generated by a large number of multicast queries 

would adversely affect the performance of the network. 

The Service Agent (SA) 

The service agent is responsible for the advertisement of service attributes and configuration. 

When an SLP-enabled service comes up on a machine, it makes itself known to the SLP service 

agent, which also must be loaded. The service registers necessary attribute and configuration 

information with the service agent. It is the service agent’s responsibility to advertise this 

information when SLP queries from user agents are received. The SA will also register the service 

information with any directory agents it recognizes on the network. 

The “service agent” is not synonymous with “server.” Service agents can exist on any box. For 

example, if a NetWare client has an SLP-enabled service loaded on it, a service agent is required 

on the workstation to advertise this service. 



The User Agent (UA) 

The user agent is responsible for retrieving information about service attributes and configuration 

available on the network. When an application needs a list of services, an SLP request is sent out 

to retrieve the available service information. This request can be sent to the SAs or DAs that exist 

on the network. 

The “user agent” is not synonymous with “workstation.” User agents can exist on any box. For 

example, NetWare servers need to advertise network services and also need to periodically 

retrieve lists of network services. The user agent is the responsible party for acquiring those lists 

of network resources. Thus, NetWare 5.1 servers have both SLP service agents and user agents 

running on them simultaneously. 

Default SLP Communications 

The default method of SLP communication, which is explained in this section, is heavily 

dependent upon multicast. This strategy works well for the small network, but it does not scale 

well in an enterprise environment, especially a large and complex one. This is because when a 

large number of service agents become members of the multicast group, a significant portion of 

the network bandwidth can be taken up by user agent multicast traffic and service agent responses. 

While the traffic will be less than the RIP/SAP broadcast traffic, it can still impede network 

throughput. 

On a network without directory agents, user and service agents use multicast to find each other. 

This is the general method of communication for SLP. When a service agent comes up for the first 

time, it will multicast out to the network using an IGMP packet addressed to 224.0.1.22. This is a 

join request so that any multicast-enabled routers on the network will add the service to their 

membership lists. This is how the routers on the network know how to forward the SLP queries 

from user agents on the network to the service agents registered with the multicast group. 

When a user agent needs to retrieve a list of services in the absence of a directory agent, it 

multicasts out on the same address looking for service agents. The service agents, listening on the 

multicast address, will unicast an SLP packet back to the requesting user agent with a list of the 

services requested. Only those service agents that have information to send back will send a 

unicast packet back to the service agent. This exchange of service information is shown in Figure 

D1 and can be verified using any packet sniffing utility. Figure D2 shows a sample packet trace 

taken from a pure IP network with only user and service agents. 

All of the packets shown logically in Figure D1 are SLP packets. SLP packets can be identified 

because they are TCP/IP based and addressed to port 427. SLP supports both UDP and TCP 

connectivity. UDP is the preferred method of transmission for SLP because it is more efficient 

from a network perspective. However, the connection oriented TCP communication is established 

when bulk transfer of information is required. In Novell’s implementation of SLP, the initial SLP 

packet is sent out as a UDP packet. If the response comes back as a UDP packet with the overflow 

bit set, as often happens when retrieving a list of SAPSRV.novell SLP objects, a TCP session is 

established to transfer the list of services. 



User Agent 

requests services 

Unicast SLP packet 

addressed to original host 

Multicast SLP packet 

addressed to 224.0.1.22 



Service Agent 

has service; reply is unicast 

Service Agent 

does not have service; 

no reply 

Service Agent 

has service; reply is unicast 

Figure D1. Using SLP multicast to discover services. 

There is a limit to the amount of information that can be returned in a single SLP service request. 

This limit is 64KB of information. Any information above 64KB is truncated and not seen by the 

user agent. This is a limitation arising from the SLP RFC itself and not from Novell’s 

implementation. According to the RFC, the information pertaining to the length in the SLP header 

packet is 16 bits. This translates into the 64KB limitation. In SLP version 2 (defined in RFC 

2608), the length information in the header has been expanded to 24 bits. This will allow for the 

return of over 15MB of service information from a single request. Novell has implemented SLP 

version 1 in NetWare 5.1, and implementation of SLP version 2 is expected soon. For the purposes 

of this document, assume SLP version 1 as the underlying technology unless explicitly noted 

otherwise. 

Figure D2 shows the traffic pattern of a NetWare 5.1 server using the default SLP communication 

mechanism and a client requesting a list of SLP services. The server boot process in this example 

puts 23 packets of IP data out on the network. The figure shows the IGMP packets addressed to 

the service agent multicast address. This is from the service agent on the server registering itself 

with the multicast group. The user agent on the server then follows with a set of service requests 

itself. The SLP Service Request packets in the screen capture shows this. 

Some packets of interest are packets 4 and 11 in the screen capture. These packets show that the 

user agent on the NetWare 5.1 server is looking for a directory agent on the network. The 

directory agent will be discussed in more detail in the next section. 

Packets 24 through 26 show the multicast lookup mechanism for a user agent on the client. In 

packet 24, the user agent is multicasting for a particular SLP service (in this case the 

bindery.novell service). In packet 25, the NetWare 5.1 server, with IP address 4.3.1.119, responds 

to the client with the information requested. The user agent on the client then sends out another 

multicast packet to the network. This packet is required as part of the RFC. It represents the 

convergence algorithm used to discover all services connected to the original SLP request. 



Figure D2. A packet trace illustrating default SLP communication. 

Because the user agent wants to find all instances of the service on the network, it makes an initial 

query to the service agent multicast address. After the user agent receives responses back to the 

request, it sends out another multicast packet looking for the same service; however, this packet 

includes a previous responder list. Thus, packet 26 includes the IP address of the service agent that 

has already responded. This is why a second response from the NetWare 5.1 server is not seen on 

the network. 

Only when there are no new responses is the request designated “complete.” Because there were 

no additional service agents on the network that could respond to the user agent’s request, the 

service list is complete, and the user agent makes no more queries to the network for the original 

request. The convergence algorithm will wait 3 seconds before marking the process complete. All 

information gained from the network at this point is passed back to the requesting application. 

There are other methods of discovering service information on a network that do not involve the 

heavy use of multicast. These methods deploy the directory agent, and it will be discussed in the 

next section. 

The Directory Agent 

The directory agent is the optional component of the SLP infrastructure architecture; however, it is 

probably the most useful in an enterprise network environment. As shown in the previous section, 

SLP is a passive protocol driven by user agent requests and service agent registrations. When a 

user agent sends a query to the network, all service agents holding pertinent information must 

respond. Thus, the user agent is getting service information from many different nodes on the 

network. With a directory agent on the network, the user agent will get service information from a 

limited number of nodes. 



The directory agent basically acts as a central repository of SLP service information. All service 

agents that come up on the network register their list of services with the directory agent. All user 

agents making use of directory agents direct their requests to the directory agent instead of making 

the request through a general multicast packet. This makes for more efficient use of the network 

bandwidth because packets are directed unicast packets instead of multicast. Also, traffic can be 

isolated based upon the physical network topology instead of having to enable multicast packets 

end to end on the network. 

Directory Agent Basics 

In the presence of a directory agent on the network, the communications behavior of user and 

service agents on the network changes drastically. Instead of relying heavily upon multicast for the 

discovery and resolution of services, they rely upon the directory agent. This makes 

communications more efficient, but raises the question of how the user and service agents discover 

the directory agents on the network. 

User and service agents on the network can discover directory agents on the network in one of 

three ways: 

• Through multicast addressed packets. 

• Through configuration information received through DHCP. 

• Through static configuration. 

Discovery Through Multicast 

The first method of directory agent discovery is discovery through multicast. If multicast is 

enabled on a network, then this is a good option for the dynamic discovery of directory agents. 

Multicasting for directory agents happens only once per user and service agent upon loading and 

once per directory agent upon loading. 

When a directory agent is loaded on a machine configured for multicast discovery, it sends out an 

IGMP multicast request to join the directory agent multicast group. The address for this multicast 

group is 224.0.1.35. By joining this group, routers will be able to forward service request packets 

to the directory agents on the network. Joining the multicast group is a required function if service 

and user agents are going to discover directory agents on the network through multicast. 



Figure D3. Packet trace showing the loading of a directory agent. 

Figure D3 shows the packet trace from loading a directory agent on a NetWare 5.1 server. The 

IGMP packets for the multicast group registration are shown in addition to a multicast directory 

agent advertisement. Packet 3 is a periodic packet sent out by the directory agent to ensure the 

activation of the directory agent on boxes running a service agent. This is called the “directory 

agent heartbeat packet”. The interval for distribution of this packet is configurable. By default, this 

packet is sent out once every 3 hours. 

When SLP user and service agents load on boxes configured to discover directory agents through 

multicast, they will perform a multicast request to the directory agent multicast address. The 

directory agents on the network will respond to the request using a unicast packet. Once the 

directory agent has been “activated” by the user or service agent, that directory agent is used for 

all SLP service requests. The user or service agent will no longer use multicast to discover 

services on the network. Figure D4 shows the general traffic pattern for a network configured to 

discover directory agents through multicast. 

From the user agent perspective, the directory agent that first responds to the multicast request for 

a given scope will be the primary DA for that scope. This means that all future SLP queries will be 

sent to that DA through a unicast SLP packet. In the event the primary DA for a user agent is 

unavailable, the user agent will then try the next DA in the list for that particular scope. Scoping 

itself will be discussed later in this document. 



DA List 

DA1 

DA2 

DA3 





Multicast SLP packet 

User or Service Agent 

addressed to 224.0.1.35 

Looks for Directory 

Agent 



DA1 

Directory Agent responds 

DA2 


DA3 


Figure D4. Discovering directory agents through multicast. 

In Figure D4, the user or service agent looks for the directory agent through multicast. In this 

example, all three DAs respond to the initial multicast packet with DA1’s packet getting to the 

requesting agent first. DA2 and DA3’s packets follow this. This makes DA1 the primary DA for 

the user or service agent. In the event DA1 is unavailable, the agent will attempt to contact the DA 

again based upon the SLP Retry Count parameter. If all of these retries fail, the agent marks the 

DA as “inactive”. The agent then moves to the next active DA on its known list and tries it. In this 

case, the agent will attempt to retrieve the list of services from DA2. Furthermore, if both DA1 

and DA2 are unavailable (as determined through the above process), the agent will attempt to 

retrieve the list of services from the next active DA on the network, DA3. 

Once the agent has established the DA list, all subsequent SLP service requests are directed to the 

DAs through a unicast SLP packet. This reduces the amount of multicast traffic on the network as 

compared to the default SLP communications method. 

Discovery Through DHCP 

Information about directory agents can also be disseminated through the Dynamic Host Control 

Protocol (DHCP). There are two DHCP option tags that can be used to dynamically deliver DA 

configuration information. They are DHCP options 78 and 79. Option 78 allows the DHCP client 

to obtain directory agent address information. Option 79 allows the DHCP client to obtain SLP 

scope information. 

Once the DA address is configured through DHCP, the agent should not use multicast to discover 

directory agents on the network. This is because the IP address of the directory agent is already 

present and has been “discovered”. 

Both NetWare clients and NetWare servers can use DHCP to obtain directory agent and SLP 

scope information. The client will obtain an IP address at the same time. The NetWare server will 



make a DHCP request to a DHCP server to retrieve option tag information, but it will not get an IP 

address from a DHCP server. NetWare servers still must have statically configured IP addresses. 

Discovery Through Static Configuration 

The final method of DA discovery is through static configuration. This method and the DHCP 

method mentioned previously are the most scalable ways to implement SLP. With static 

configuration, the addresses of the DAs on the network are manually entered so agents can make 

use of the information. With static configuration of DAs, all multicast traffic can be removed from 

the network because agents will not multicast to discover directory agents on the network, and 

through the use of directory agents, user agents will not multicast to retrieve SLP service 

information. They will use directed unicast SLP packets. 

Static configuration of agents is accomplished rather simply in the NetWare environment. On the 

NetWare 5.1 server, there is a file called SLP.CFG contained in the SYS:ETC directory. This is 

the file used to hard code directory agent information. To specify a directory agent in this file, the 

format used is the following: 

DA IPV4, 

There can be any number of addresses contained in the SLP.CFG file. For each directory agent 

listed, the service agent will register with that directory agent. However, the user agent on the 

server will only use the first activated directory agent in the list to retrieve SLP service 

information. Thus, a service agent may register with numerous directory agents; however, service 

resolution will only be done against a single DA. Of course, the fail-over mechanisms described 

above exist so that if the primary directory agent is not available, the user agent will look to the 

next directory agent configured in the static list. 

Currently, it is possible to use fully qualified DNS names in the SLP.CFG file to specify directory 

agents; however, only the first directory agent specified in the list can be identified in such a 

manner. This is a limitation of the WINSOCK module on the NetWare 5.0 server, and it is 

expected to be fixed with Support Pack 3 and with the shipping code of NetWare 5.1. 

For the NetWare 5.1 client, static information for the preferred directory agents on the network is 

set in the Novell client's property page through the Network control panel. The directory 

information and SLP scope information can be set through the Service Location tab found on this 

page. 

Setting Directory Agent Discovery Mechanisms 

How agents discover directory agents on the network can be set on a per machine basis. For 

instance, one client workstation might use multicast to discover directory agents on the network 

while another might be statically configured. For consistency’s sake and easier administration, it is 

generally a good idea to have the same discovery mechanism for all agents, but it is flexible 

depending upon the environment. 

To force a NetWare 5.1 server to discover directory agents through one or more of the three 

mechanisms, a SET parameter is used. This SET parameter is the SET SLP DA DISCOVERY 

OPTIONS parameter. It is executed at the server console or can also be set through MONITOR 

under the Service Location Protocol option. Some common values for this SET parameter are 

shown in Table 1. 

Parameter Value Description 

1 Discover DAs through multicast. 



2 Discover DAs through DHCP. 

4 Discover DAs through static configuration. 

8 Disable dynamic discovery when DHCP or static files are present. 

Table D1. Common values for the SET SLP DA DISCOVERY OPTIONS parameter. 

It should be noted that the SET SLP DA DISCOVERY OPTIONS parameter setting is based upon 

a bit comparison test. If the least significant bit of the parameter is set to 1, the server will attempt 

to discover directory agents through multicast. If the second least significant bit of the parameter is 

set to 1, the server will attempt to discover directory agents through DHCP. The server can be set 

to use multiple methods of directory agent discovery by performing a bit-wise Boolean OR of the 

desired valued. Thus, if both multicast discovery and static discovery are desired for a 

NetWare 5.1 server, the calculation of the value would be as follows: 

00000001 Discovery through multicast 

00000100 Discovery through static configuration 

00000101 Discovery through multicast and static configuration 

Converting that number back to decimal, the SET SLP DA DISCOVERY OPTIONS parameter 

would be set to 5 to achieve directory agent discover through both multicast and static 

configuration. 

For the client, the configuration is a bit simpler. In the property’s page of the Novell client, there is 

a place to specify the address of the directory agent. There is also a check box labeled “Static”. 

When this box is checked, the client only discovers DA information through static configuration. 

When unchecked, the client will use both multicast and static configuration. Figure D5 shows the 

Service Location property page of the Windows NT NetWare client. In this figure, there has been 

one DA specified in the configured list, and the Static box has been checked. This means that if 

the sole DA in this list is unavailable, the client will not be able to retrieve any SLP information 

from the network. 

Note: Both IP addresses and DNS names can be used to specify directory agents in the NetWare 

95/98 client. Using DNS names will facilitate easier administration of the SLP infrastructure from 

the client perspective. 

This is important information to consider because disabling an agent from using a specific means 

of directory agent discovery can adversely affect performance if directory agents are unavailable. 

Enabling multiple methods of discovery will provide a fault tolerance. 



Figure D5. Setting directory agent discovery mechanisms on the Windows NT NetWare client. 

The Service Registration Process 

When directory agents are enabled and service agents are configured to use the directory agents, 

the service agents must register their services with the directory agent. The service agent registers 

all SLP enabled services on the box with the directory agent. When the directory agent receives 

this information, it sends back an acknowledgement to the service agent indicating the services 

have been registered. 

When the service agent registers a service, it attaches an associated time-to-live (TTL) to the 

service. This is the lifetime of the service. When the DA receives the service, it looks at the 

service’s TTL and begins a count down based upon the time since the service was registered. Once 

the TTL gets to zero, the service is no longer valid, and the DA will not advertise the service 

anymore. It is the responsibility of the service agent to re-register the service with the directory 

agent before the TTL of the service expires. If the service agent fails to do so, an interruption in 

service can occur because the service will no longer be advertised. 

There are different types of services registered by Novell service agents based upon the different 

types of services required in the Novell environment. Some of the more common services seen in 

Novell’s implementation of SLP are summarized in Table 2. 

Service Type Description 



NDAP.novell Contains information regarding NDS tree partitions. Required for NDS tree walking and 

partition resolution. 

Bindery.novell Contains information regarding server names. Required for short name to IP address 

resolution. 

SAPSRV.novell Contains information pertaining to SAP. Required for compatibility mode and bindery 

information resolution. 

SRS.novell Contains information pertaining to the Service Registry Services agent of NDPS. 

Required for NDPS SRS services. 

RMS.novell Contains information pertaining to the Resource Management Services agent of NDPS. 

Required for NDPS RMS services. 

MGW.novell Contains information pertaining to Migration Agents on the network. Required for 

compatibility mode. 

CMD.novell Contains information pertaining to Compatibility Mode servers. Required for 

compatibility mode. 

Table D2. Novell SLP Service types. 

Additionally, SLP services are referred to using Universal Resource Locator (URL) notation. This 

is a construct from the RFC. For example, the URL for a NetWare 5.1 server named FS1 would be 

the following: 

service:bindery.novell:///FS1 

This URL describes an SLP service of type bindery.novell with the name ATLA_NDS1_US. 

There are three forward slashes in the URL for an UNSCOPED service. A scoped service could be 

seen through a packet trace, and the URL for a scoped service would include the scope name 

between the second and third slashes. 

The default TTL for Novell service agents is 3600 seconds (or one hour). This is a configurable 

parameter that is set on the service agent. Issuing the following command at the server console 

will set the TTL for all services registered by that service agent: 

SET SLP SA DEFAULT LIFETIME = 

The value for this parameter can be between 129 seconds and 65535 seconds. Care should be 

taken in how this value is set. Too small of a TTL can lead to increased network traffic as service 

agents will need to contact directory agents more frequently to reregister services. Too large of a 

TTL can lead to the advertisement of services that are no longer available because of a server 

ABEND. 

Service agents will also register services with all directory agents of which it has knowledge. 

Thus, if the service agent knows of five directory agents, it will place five separate registration 

requests—one for each DA. While good for fault tolerance, having too many DAs for each service 

agent can lead to increased network traffic due to SLP overhead. 



When a directory agent receives a registration request, it will create an entry for the service in its 

own database. This entry will contain the name of the service, the type of service, the attributes of 

the service, and the TTL. As mentioned previously, it will send back an acknowledgement to the 

service agent that the service has been registered. Figure D6 shows the summarized registration 

process. 

DA List 

DA1 

DA2 

Service Agent 1 

Service registration using 

unicast SLP packet 



Directory Agent creates 

entry for services 

registered 

ACK 

Service List 

SA1 

SA2 



DA1 

Unicast SLP request for 

list of services 

ACK 

User Agent 

DA2 

Service List 

SA1 

Unicast SLP response 

Services Learned 

SA1 

SA2 



ACK 

Directory Agent creates 

entry for services 

registered 

Figure D6. Summary of the service registration process. 

Service Agent 2 

There are some important pieces to note in Figure D6. First, without a method for directory agent 

to directory agent synchronization, the list of services retrieved by a user agent is directly 

dependent upon the directory agent used for the lookup. If the user agent in Figure D6 had looked 

to DA2 to find a list of SLP services, it would only know about SA1. Second, after the DA 

discovery process, all SLP transactions are accomplished using directed unicast SLP packets. 

There is no multicast in the resolution of services when a directory agent is used. 

Service agents are also supposed to de-register their services if they are no longer available. When 

a service de-registers with a DA, the DA will no longer advertise the service to user agents. 

NetWare servers that are brought down gracefully will send a de-registration packet to the DA to 

remove the service. The service agent will make unicast SLP requests to known directory agents 

on the network to accomplish this de-registration. Each notified DA processes this packet and sets 

the time to live (TTL) of the service to zero, indicating it should no longer be advertised. 

Understanding Novell’s Implementation of the DA 

While the RFC defining the Service Location Protocol is very clear with regard to the user agent 

and service agent, there are some areas of interpretation left open with regard to the directory 

agent. For instance, the RFC indicates the methods by which the directory agent can communicate 

with the service and user agents; however, it does not address the issue of directory agent to 

directory agent synchronization. It also does not address the structure of the database used by the 

directory agent to store SLP information. There is room for interpretation. 

Novell has one of the best object oriented, distributed databases on the market that already takes 

care of such critical issues as synchronization. The choice was made in the development of 

Novell’s implementation of SLP to use Novell Directory Services (NDS) as the backend for an 

DA List 

DA1

SLP object data store and a method of DA to DA synchronization. It fits right into the strategy 

surrounding NDS and definitely plays to its features and benefits. So the question remains, “How 

did Novell implement their version of the directory agent?” 

The communication between user, service, and directory agents works as previously described in 

this document. However, when a DA gets a service registration from a service agent, it goes 

through a process to create an object in its local SLP cache as well as creating or modifying an 

object in NDS to update the service. When a directory agent is loaded, there is stored 

configuration information in NDS for that DA. This configuration information includes on which 

NetWare file server the DA is running and what scope the DA is servicing. Scopes will be 

discussed later in this document in the section titled “Scoping”. 

For each scope defined on the network, an SLP Scope Unit object is defined within NDS. Also in 

NDS, each DA object is configured to service a particular set of scopes. When the Novell DA 

receives an SLP service registration, it checks its local SLP cache. From there one of two things 

can happen: 

• If the service does not exist in the local SLP cache, an entry is created for the service with 

the attributes defined in the registration packet. The directory agent then creates an NDS 

SLP service object in each scope for which it is responsible. 

• If the service already exists in the local SLP cache, the entry is modified in the local SLP 

cache. The directory agent then also modifies the NDS SLP service object in all scopes 

the DA serves. 

When a DA modifies the NDS SLP service object, it triggers an NDS synchronization event. The 

synchronization trigger forces all replicas of the partition containing the NDS SLP service objects 

to exchange information to make the partition consistent. The other DAs on the network see the 

NDS synchronization event and reread the SLP service information from NDS to update their 

local SLP caches. Figure D7 illustrates the registration of an SLP service and the propagation of 

that information through NDS to other DAs on the network. 

DA receives service 

registration from a 

service agent 

DA sends ACK to SA 



DA2 

DA1 DA3 

1. DA creates (modifies) 

object in local SLP cache 


SA1 

4. DA sees sync event 

and reads NDS for new 

SLP service object info 

3. NDS partition sync 

event is triggered 


SLP service object in NDS 




SA1 

Figure D7. DA to DA synchronization. 

4. DA sees sync event 

and reads NDS for new 

SLP service object info 




SA1

The NDS SLP service objects contained in each scope reflect the SLP information for the entire 

network. This is because service agents belonging to the same scope do not necessarily have to 

register with all DAs servicing their scope. As seen in Figure D7, the SA only needs to register 

with the one DA. Assuming that all the DAs are in the same scope and all DAs hold a replica of 

the partition containing the NDS SLP service objects, the other DAs on the network will learn of 

the service without the service agent having to directly register via SLP. 

This is a method to isolate SLP registration traffic. Service agents need only register with the local 

DA. NDS synchronization will take care of propagating that registration to the other DAs 

servicing the SLP scope. The result is that any user agent on the network can retrieve the same list 

of SLP services regardless of which DA it queries. 

Using this scheme, NDS becomes the central repository of SLP service information for the 

network. The SLP information can be seen directly in NDS through such administration tools as 

NetWare Administrator. Figure D8 shows how the scope object looks in NDS along with the SLP 

service objects. For the NDS tree shown in Figure D8, there is one scope (UNSCOPED) and one 

NetWare 5.1 server in the tree holding a replica of the single partition. 

Figure D8. Viewing SLP service objects in NetWare Administrator. 

The information seen in NetWare Administrator at this level only displays the URL of the SLP 

service object. In Figure D8 there are only two SLP service objects. One is of type bindery.novell. 

The other is of type NDAP.novell. Notice that in NetWare Administrator the types have been 

changed from periods to underscores. This is to prevent confusion with fully qualified NDS 

names; however, when user agents request SLP information of a particular type, the query is 

addressed to the dotted name, such as bindery.novell. 



It is possible to drill down deeper into the service object to see the attribute information. By 

double clicking on the SLP service object in NetWare Administrator, more information is 

displayed. It is shown in Figure D9. 

Figure D9. Viewing SLP service object attribute information in NetWare Administrator. 

Figure D9 displays a plethora of information about the SLP service object. The type of the object 

is displayed (NDAP.novell) along with the TTL for the object (3600 seconds). The official URL 

of the object is also shown along with the attribute information. The attribute information is going 

to be different for each type of object because certain services require attribute information that 

others do not; however, some of the information is common between types. 

Some useful information to know about the NDAP.novell service type has to deal with addressing 

and type information. Every NDAP.novell object contains information about an NDS partition 

including the addresses of all servers holding replicas of the partition. This can be seen in Figure 

D9. Under the svcaddr-ws attribute of the DEMO partition, three addresses are displayed. The first 

address (2-1-6) defines the address as a TCP address followed by the IP address in hexadecimal 

form (04030177). The second address (6-2-1000) defines the address as an IPX address followed 

by the internal IPX number of the server (08922DF1), and the third address (2-2-17) defines the 

address as a UDP address along with the IP address of the server in hexadecimal form (04030177). 

This addressing scheme defined here for the NDAP.novell object is the same for the 

bindery.novell object. This is how short name resolution is accomplished. When the user agent 

requests a type of service from the directory agent to find a server (using the bindery.novell type 

request), the user agent gets back a list of addresses associated with the server. It then decodes the 

information as above to determine how it can reach the desired destination. 

When a service agent de-registers with a Novell directory agent, the DA does not remove the 

service from NDS or its local SLP cache. It simply marks the TTL of the object to zero. This 

prevents the DA from advertising the service to user agents, but when the service reregisters itself 

in the future, the overhead of object creation in cache and NDS is not incurred. The TTL of the 

object is just renewed. This method of SLP object management creates efficiency in registration 

and de-registration of SLP services. 

Because the DA makes a lot of modifications to NDS, the partition containing SLP service objects 

becomes a very active partition. SLP object registration leads to increased NDS traffic, which will 

have an impact upon the network. However, this traffic is not severe compared to the RIP/SAP 

broadcast traffic required in the IPX realm. It is recommended that the SLP scope containers be 

made their own partitions. Those partitions should also only reside upon directory agents. There is 

no worry if information in that partition gets lost because it is easily recreated by setting up a DA 

and letting service agents register again. 

Scoping 

Throughout the document, the term “scope” has been used repeatedly, but it has not been well 

explained. Scoping is a method of organizing SLP information on a network so that only certain 

subsets of SLP data are available to user agents on the network. It is also a method to provide 

scalability in the SLP environment because scopes that are too large become inefficient. 



User agents, service agents, and directory agents can all belong to a set of scopes. A user agent on 

a NetWare client belonging to a single scope will only request services from scopes that it knows 

of and no others. Likewise, if a DA is set to service a scope and the NetWare client user agent is 

configured to get services from a different scope, the user agent will not be able to retrieve lists of 

services from the DA. The user agent, service agent, and directory agent (if used) must belong to 

the same scope for service resolution through SLP to be successful. 

Figure D10 shows an example where the service agent and directory agent belong to the same 

scope but the NetWare client user agent does not. In this example, the service agent will be able to 

successfully register its service with the DA because they do belong to the same scope. However, 

the user agent is configured with the address of DA, and it needs to find the service registered by 

the service agent. It will not be able to find the service because the DA will ignore the SLP query 

from the user agent since it is a query for a different scope. 

Service Agent belonging 

to Scope 1 



SA1 

Service Registration 

Service Request 

Acknowledgement 

DA1 servicing 

Scope 1 

Figure D10. Example of scoping. 

User Agent belonging 

to Scope 2 and configured 

with address of DA1 

The user agent on the NetWare 5.1 server functions a bit differently than the user agent on the 

NetWare client. On the NetWare 5.1 server, the SET SLP SCOPE LIST parameter determines 

which scopes the service agent registers its services. This parameter does not affect the server’s 

user agent. The server’s user agent will query and retrieve lists of services from all SLP scopes 

about which it is aware. Thus, if the SET SLP SCOPE LIST parameter is set to SCOPE1 and the 

NetWare server knows of DA’s servicing both SCOPE1 and SCOPE2, the service agent will 

register the services with only SCOPE1. However, the server will know about SLP services 

registered with SCOPE1 and SCOPE2. 

Fortunately, user, service, and directory agents can belong to an unlimited number of scopes. 

When a service agent belongs to multiple scopes, it will register with DAs in each one of those 

scopes. When a user agent belongs to multiple scopes, it will keep an active primary DA for each 

scope. When it sends out SLP service request packets, it will send out a request for each scope to 

which it belongs. That way, it is ensured to get back a list of all services matching its request from 

all scopes to which it belongs. 

It should be noted that scoping is not hierarchical. DAs in one scope cannot query DAs in another 

scope on behalf of a client request. The user agent can only retrieve SLP service information from 

scopes to which it belongs. This is an important note to keep in mind because it is a method by 

which service filtering can be implemented. If it is desirable to have a set of clients unable to see a 

set of services, the user agents for the clients and the service agents for the services should belong 

to different scopes. This will prevent the user agents from resolving those services through SLP. 

In version 1 of the SLP RFC, the default scope for all services is a scope called “UNSCOPED”. 

All service agents that discover directory agents serving the UNSCOPED scope must register with 

that scope even if they are already scoped. Thus, if a service agent configured to use Scope1 finds 

a directory agent servicing the UNSCOPED scope, it must register with the DA servicing Scope1 

and the DA servicing the UNSCOPED scope. This will create two SLP service objects in 

NDS—one object in each scope. 

The default of the UNSCOPED scope is going to change with SLP version 2, and it is not 

recommended that the UNSCOPED scope be used. In SLP version 2, all user and service agents 



must be configured to have a scope. With SLP version 1, an empty string represents the 

UNSCOPED scope. When the SLP infrastructure is eventually upgraded to version 2, all servers 

and workstations with empty scope lists will not function properly. Thus, starting with a defined 

scope even if the network is only going to use a single scope is a good idea for a number of 

reasons: 

• It will prevent a lot of administrative work for when SLP v2 is implemented. The 

UNSCOPED scope will have to be modified to a defined scope wherever it exists. 

• It prevents renegade SLP services from registering with production directory agents. 

Thus, if someone brings up a test NetWare 5 box on the network, the service will not be 

seen by anyone through SLP unless steps are taken to configure the test box with a scope. 

From a Novell implementation standpoint, an SLP scope unit object must be created in NDS for 

each scope that will be implemented. The DA server objects also need to be configured in NDS to 

service a particular scope or scopes. Once the configuration is done in NDS, then the service and 

user agents must be configured to look to a specific scope or scopes. This is accomplished on a 

NetWare 5.1 server using the SET SLP SCOPE LIST parameter. This command can be issued at 

the console or through MONITOR. 

The SLP SCOPE LIST is a comma-delimited list specifying the list of scopes for the service 

agent. On a NetWare client the scope list is specified through the NetWare client property pages. 

Figure D5 displays the page where scopes are configured on the Windows NT client. Both user 

and service agents can belong to an unlimited number of scopes, but it is rare that a large number 

of scopes will be needed in any given environment unless CMD technology is being used. 

It is also possible to redirect specific service types to specific scopes. This is done in the SLP.CFG 

file and requires NetWare 5.0 Support Pack 3 or NetWare 5.1. Service redirection is handled as 

follows: 

Register Service Type “ndap.novell” To Scope “Global,XRegion” 

Register Service Type “mgw.novell” To Scope “Global,XRegion” 

Note: “xREGION” is the region in which the server exists. As shown, a service can be sent to 

multiple scopes by using a comma-delimited list. 

To maintain the server’s scope list registrations when redirecting services, those same scopes must 

also be included in the SLP.CFG redirection. The redirection in SLP.CFG takes precedence over 

any parameters specified in the SET SLP SCOPE LIST parameter. 

The general rule is this, Unfiltered services will go into all of the scopes in the servers SLP scope 

list. Filtered services will only go into the scopes they were told to go into, regardless of the scope 

list. 

Note: Any change to the scope redirection in the SLP.CFG file requires a server restart before 

changes take affect. For this reason you probably want to have your SLP design solidified before 

you begin the upgrade process. 

SLP Troubleshooting Tools 

It is useful to have a set of tools that can aid in the troubleshooting of SLP problems that may arise 

on the network. With NetWare, there are two basic types of boxes—NetWare clients and NetWare 

servers. The troubleshooting tools between the boxes are different. Because NetWare file servers 

generally house user, service, and directory agents, there are more aggressive tools to help 

troubleshoot SLP problems. There is a tool for the NetWare client to display SLP information, but 

it is not as detailed as the tools that can be used on the NetWare servers. 



NetWare Client SLP Tools 

The main tool that can be used to help solve SLP problems on the NetWare client is 

SLPINFO.EXE. This tool, run from a command prompt, will display SLP configuration 

information about the client. This tool is included in both the Windows 95/98 client and the 

Windows NT client. The Windows 95/98 client displays all SLP configuration information when 

SLPINFO.EXE is executed. The Windows NT client has a set of parameters that can be used to 

display specific information. This information is summarized in Table 3. 

Switch Description 

/D Displays information about known directory agents 

/C, /O Displays configured parameter settings 

/T Displays configured timer values 

/S Displays known SLP scopes 

/I Displays local interface information 

/A, /ALL Displays all options listed above 

/H, /HELP Displays the help screen 

Table D3. Command line options for Windows NT SLPINFO.EXE 

NetWare Server SLP Tools 

Because NetWare servers do most of the SLP work, there are more tools to help troubleshoot SLP 

problems. Most of these tools are run at the server console, but some information can be captured 

to text files for later review and examination. These tools won’t necessarily identify an SLP 

problem outright, but they will provide the information necessary to trace the cause of the problem 

so it can be corrected. 

DISPLAY SLP DA 

The first tool is a console command called DISPLAY SLP DA, and it does exactly that. It displays 

the directory agents known to the server. When this command is issued at the console, it displays 

information in a specific format: 

::: 

This is very useful information because the server may have marked a directory agent as being 

inactive, which could be the reason the server is unable to resolve any services. Also, the directory 

agent discovery method is shown. If multicast is not intended to be a method of discovery and it 

appears on this screen, steps need to be taken to determine why the server is multicasting for 

directory agent discovery. 



DISPLAY SLP SERVICES 

Another useful tool for troubleshooting SLP problems is the DISPLAY SLP SERVICES utility. 

This is another console command that is executed at the server prompt. When issued, it shows the 

list of SLP services known by that server. If the server is configured to use multicast to discover 

SLP services, this command will send out an SLP service request to find all services on the 

network. If the server is configured to use a DA, an SLP service request will be sent to the DA for 

a list of SLP services. It is a useful utility because it can help determine exactly what type of 

information the DA on the network is returning. This is also a good way to get a glimpse of the 

DA’s local SLP object cache, if the command is issued from the console of the DA and it is 

configured to look to itself. 

If the server is configured to use a DA and this command is issued, the information displayed 

comes from the first active DA for each scope. The DAs queried by this command can be 

determined by viewing the information returned by the DISPLAY SLP DA command. The first 

active DAs for each scope are the DAs returning information in the DISPLAY SLP SERVICES 

command. 

There are some command line parameters available with the DISPLAY SLP SERVICES utility 

that allows for a filtered view of the SLP services on the network. The command line syntax for 

the utility is as follows: 

DISPLAY SLP SERVICES [//] 

For instance, to display only NDS partitions on the network, the command DISPLAY SLP 

SERVICES NDAP.novell would be issued from the server prompt. The same thing can be done 

for service types in a particular scope or service types that fit a specific predicate query. 

DISPLAY SLP ATTRIBUTES 

The DISPLAY SLP ATTRIBUTES command is another console-based command executed at the 

server prompt. This command requires an SLP URL as an argument and returns all of the attribute 

information associated with that URL. It is the same type of information that can be seen by 

opening up an SLP service object in NetWare Administrator. But if NetWare Administrator is not 

readily available, this command provides an easy way of retrieving attribute information. 

For example, if the attributes of the [Root] partition of the Novell tree were needed, the following 

console command could be executed from a NetWare 5 server on the network: 

DISPLAY SLP ATTRIBUTES service:ndap.novell:///NOVELL. 

In this example, the final period is required because it is part of the service URL. It denotes a fully 

qualified partition name in the NDS tree. 

SET SLP DEBUG 

The SLP debug utility is a SET parameter that can be executed from the server console or set in 

MONITOR. This utility will bring up another screen on the server that will show SLP information 

based upon the value to which the SET parameter is set. As SLP traffic that fits the parameter 

setting is generated or received, it is logged to the screen on the server. In this manner, the SLP 

communications between boxes can be monitored. This utility is most effective if run on a 

directory agent because service registrations and de-registrations can be seen along with NDS 

updates and user agent service requests. 

Some useful values for the SET parameter are summarized in Table 4. The value determines what 

type of SLP traffic is logged to the screen. It is important to have the correct type of information 

displayed when attempting to solve a problem. For example, if there is a problem with services 



eing registered in NDS, but the value is not set to display API information, no useful information 

will be logged to the screen. 

Parameter Value Description 

1 Display basic SLP communication information 

2 Display SLP transport information 

4 Display SLP API calls (including DA calls to NDS) 

16 Display SLP errors 

32 Display service agent/directory agent traffic 

64 Display user agent/directory agent traffic 

Table D4. Useful SET SLP DEBUG parameter values. 

Like the SET SLP DA DISCOVERY OPTIONS parameter, the SET SLP DEBUG parameter is 

based upon a bit comparison test. Performing a bit-wise Boolean OR of the desired settings can 

allow for multiple logging options. Thus, to provide a debug output of all of options summarized 

in Table 4, the value would be set to the following: 

00000001 Communications 

00000010 Transport 

00000100 API 

00010000 Errors 

00100000 SA 

01000000 UA_DA 

01110111 Log all above services 

When that binary number is converted back to decimal, the value for the SET SLP DEBUG 

parameter is 119. 

It is more useful to have the information logged to a file rather than scrolling continuously on a 

server screen. This can be done for the SET SLP DEBUG command. At the server console 

prompt, type the following: 

SLP OPEN 

This command will open a file at the root of the SYS: volume to which the SLP debug information 

will be logged. When enough information has been captured, issue the following command at the 

console prompt: 

SLP CLOSE 



Once this command has been executed, the file will be closed, and it can be opened with any text 

editor for further examination. This is incredibly useful for debugging SLP problems because the 

actual communications between agents can be seen using the debug command. 



Novell’s SLP Design Recommendations 

Note: Please see the previous section “A Detailed Overview of SLP” if you are not familiar with 

SLP. 

This SLP Design section will discuss and provide design guidelines for implementing an SLP 

infrastructure. The intention here is to provide a discussion of design issues and criteria and to 

provide simple and complex design examples with the understanding that hybridization or other 

moderation of these designs is expected -- based upon the design criteria for each unique 

environment. 

In order to complete an SLP design the following information will be needed: 

• The WAN/Major Site Bubble Diagrams collected in the PFC, including link speeds 

• The Technical Assessment/Impact Study 

• NDS Diagrams and Partition/Replica matrix 

• Information on the number and location of intended CMD servers 

• If there are already NetWare 5.0 servers on the network, gather the documentation for 

how SLP is currently set up. 

In any customer site that is using TCP/IP for NetWare 5.x servers, an SLP infrastructure will be 

required. It is critical to design an effective SLP infrastructure that will minimize the amount 

traffic required for service resolution. 

The SLP design strategy will be affected by the protocol migration strategy chosen to move an 

organization from IPX to IP. 

In general, the SLP infrastructure is going to be used by two sets of machines. Those sets are 

NetWare 5.x servers and NetWare clients on the network. NetWare 5.x servers will need to make 

use of the SLP infrastructure. NetWare clients can accomplish service resolution through a number 

of mechanisms, which include DNS queries and NDS tree walking. To determine how much the 

clients are going to depend on the SLP infrastructure, ask the following questions: 

1. Does the customer want browsing or dynamic discovery of network resources (for example, 

using Entire Network through Network Neighborhood to see services on the network)? 

This functionality is what many NetWare (IPX) users are accustomed to and is 

accomplished with SAP. SLP gives IP-based clients the same functionality. 

If this type of browsing is not required, go to question 2. 

If browsing is required: 

• Should users be able to browse for all network resources available on the 

network? Yes / No 

• If browsing is required but users do not need to browse for all network 

resources, then document the segments users are on and the segments 

where the resources are located 



2. Does the customer need short name resolution (SNR) for things like using a NetWare 

server’s name in a login script (e.g., MAP G:=FS1\SYS:DATA)? 

Yes / No 

Note: This login script format is not possible in a pure IP environment without SLP or DNS 

to provide the SNR. Alternatively, the fully qualified NDS name of the object can be 

specified. This will cause the login script to use treewalking instead of a general service 

resolution. 

If SNR is not required (and dynamic discovery is also not required), users must be provided 

with NDS names, DNS names, or IP addresses to get to their needed resources. 

Additionally, you must ensure that all login scripts do not use SNR and that applications do 

not make API calls to SNR (as NWADMN32 does). 

The following are additional considerations in the event that client workstations are not 

going to be using an SLP infrastructure for service resolution: 

• In any size environment, leaving multicast on the local segments is OK as 

long as the number of NetWare servers is 20-30. In the event the primary 

service resolution mechanism is unavailable, the clients will be able to use 

multicast to access local services. 

Four ways to approach implementing SLP 

Options 1 through 3 are derived from RFC 2165. Option 4 is a hybrid solution from Novell IS&T 

for very large customers with extensive WAN links and, as you will see, uses components of 

options 1 through 3. 

There can, of course, be variations within all four options. The options as explained here are to get 

you started. 

Registered scope will be used here to refer to a scope created within NWAdmn32. 

Option 1 

Option 1 

Option 2 

Option 3 

Option 4 

"Hybrid" of 1-3 

Low Scaleability High Scaleability 

Figure D12. Scalability vs. Ease of Implementing SLP. 

This option is intended for small LAN environments (20-30 NetWare 5.1 servers) that are routing 

multicast. It uses only SAs and UAs (no DAs; therefore no scoping). There is zero configuration 



and zero administration since all NetWare 5.1 servers are SAs (automatically) and all clients are 

UAs (automatically). Additionally, since multicast is being routed, all UAs will ask all SAs on the 

LAN for their services; therefore, UAs (clients) will dynamically discover all IP services on the 

LAN without any configuration. 

Router 

Supports Multicast 

SA SA SA 

SA SA SA 

Figure D13. Option 1: Implementing SLP in a small LAN environment. 

Note: The 20-30 UA-to-SA ratio is a general Novell guideline and depends upon available 

bandwidth. 

Option 1 is zero-maintenance, but will not scale well, so it will only suffice in small LAN 

environments. 

Option 2 

This option is intended for larger LAN or smaller WAN environments that are not routing 

multicast. With this option, DAs will be created for the following two situations: 

• Segments where there are 20-30 SAs that a UA could contact (referred to here as the 

UA’s multicast radius). On these segments, DAs are being used to “scale” SAs. 

• Two segments connected by a router where multicast is not routed and the two segments 

require services on the other side of the router. Example: 



UA

SA SA SA UA UA SA SA 

SA UA UA 

DA 

O=Novell 

Unscoped scope 

DA 

O=Novell 

Unscoped scope 



Router 

No Multicast 

Figure D14. Option 2: Implementing SLP in a large LAN or small WAN environment. 

Since the DAs on each side of the router point to the same unscoped scope object in NDS, UAs on 

both sides of the router will see all services. 

This example does not use registered scopes; rather, DAs will be left associated with the unscoped 

scope (to reduce configuration). Since all DAs register their services in the unscoped scope, all 

DAs will contain all services on the network; therefore, all clients will dynamically discover all 

services on the network (as in option 1). Notice that for this to work, the DAs on both sides of the 

router must be “pointing” to the same unscoped scope. Because multicast is not configured on the 

WAN link the each DA should have the other DA listed in its SLP.CFG configuration file or the 

DA objects must be in the same context so that NDS based discovery of the DAs can take place. 

The SLP.CFG file is found in the SYS:\ETC directory and the format for listing DAs in this file is 

as follows: 

DA IPV4, 

Option 2 is more scaleable than option 1. Option 2, however, needs more configuration than 

option 1. 

Option 3 

This option is intended for large WAN environments where multicast is not routed. This option 

uses DAs and registered scopes everywhere (i.e. it is a fully scoped configuration regardless of 

whether there are 20-30 SAs on a segment). This is because all of the registered scopes associated 

with each DA will be replicated to all other sites where there are DAs. As a general rule, either an 

unscoped scope is used or registered scopes are used. Novell does not recommend mixing these 

types of scopes, and in general, if multiple scopes were desirable an unscoped scope would be 

inappropriate anyway. With the advent of SLP version 2, the unscoped scope will be replaced with 

a default scope. For this reason, Novell Support does not recommend the use of the unscoped 

scope, but recommends that customers configure a global registered scope instead. Option 3, 

assumes that the company wants to provide global browsing for all services on the network (much 

like clients are used to in the IPX world with SAP). However, instead of using a single global 

scope, this customer was large enough, and the WAN links were fast enough to support this 

configuration.

Dallas 

DA 

DAL-SLPDA --> DAL-SCOPE 

replica: 

 

Router 

Backbone 

No multicast 

Router 

Router 

DA 

Toronto 

TOR-SLPDA --> TOR-SCOPE 

replica: 

 

Figure D15. Option 3: Implementing SLP in a large WAN environment. 



DA 

Seattle 

SEA-SLPDA --> SEA-SCOPE 

replica: 

 

Note: All DAs register themselves with the unscoped scope, too. In this example, an unscoped 

scope is not configured. Additionally, 

• Scopes must be defined with unique names across the network. Novell recommends 

standard naming conventions for DAs and scopes. An example is shown in the figure 

above. 

• DAs must be configured to support these scopes (through NWAdmn32). 

• A DA can service multiple scopes, as shown above. 

• SAs must be fully scoped using the SET SLP SCOPE LIST parameter. 

• Option 3 scales well to large WAN environments (unlike Options 1 and 2). However, 

Option 3 requires creating a fully-scoped SLP environment (which in turn requires more 

maintenance than options 1 and 2). 

Option 4 

This is our general recommendation. As you will see, it is a hybrid of the above three options. You 

use SAs for “local” discovery and use DNS for “global” discovery.

Router 

SLPDA - SRegion,Global 

DNS - syd.abc.com 

dal-fs1 

dal-fs2 

No multicast No multicast 

Backbone 

Multicast 

Sydney 

Dallas 

Multicast 

Router 

SLPDA - DRegion,Global 

DNS - dal.abc.com 

syd-fs1 

syd-fs2 

Figure D16. Option 4: Novell’s general recommendation for implementing SLP—a hybrid of Options 

1-3. 

Register “essential” services in DNS so they can be accessed from anywhere in the company. For 

example, suppose that users in Sydney consistently access a server in Dallas. You would register 

this Dallas server in Sydney’s DNS. Without DNS, users would have to use the IP Address or 

NDS tree walking to get to these “essential” services. 

Another variation on this approach is to use the regional SLP design in option 3 and redirect 

services that should be globally available to a Global scope. As seen in the diagram above, the 

local DAs serve the regional scope “xRegion” and the “Global” scope. There is no unscoped 

scope. 

Scope filtering, or redirection requires NW5SP3 or later. Redirection and global scoping is 

accomplished as follows: 

• All servers in DRegion have the following lines in their SLP.CFG file: 

• Register Service Type “ndap.novell” To Scope “DRegion,Global” 

• Register Service Type “mgw.novell” To Scope “DRegion,Global” 

• Static entries for “essential” services that need to be globally visible may also be added to 

the global scope. 

• The Local DA is also listed as “DA IPV4, “ on all SAs in the 

DRegion. 

• The DRegion DA has the remote DA/s listed in its SLP.CFG file. 

• These settings are modified for each region to reflect the local region. 

All of the DAs serve their local regional scope and the global scope. All servers have their “SLP 

SA Default Lifetime” set to something greater than 3600 seconds (1hour), the maximum being 

65535 seconds (18+hours), to reduce the frequency of service updates. All servers have their 

“SLP Scope List” set to “xRegion”, where x is the local region designator (in this case S or D). 

The “SLP Scope List” parameter tells the SAs where to register all of their services. You will 

note that the redirected services are told to register with both the local regional scope and the 

global scope. This is because redirected services register only with the scopes they are told to 

register with regardless of the scope list. 



By combining this kind of configuration with the DNS configuration previously discussed, it is 

possible to provide users on this network with the highest level of scalability, reliability and fault 

tolerance possible. Providing Short Name Resolution (SNR) through both SLP and DNS, Global 

essential services through both SLP and DNS, and all other services through NDS and FQDN 

DNS names or IP addresses. 

Note: These types of configurations are obviously more administratively intense and should 

therefore be planned well in advance to allow implementation before and during the upgrade 

process. It should also be obvious that very large installations, customers with wide spread CMD 

implementations, and customers who don’t want global service visibility are the only customers 

who would need these kinds of configurations. 



Consideration and Impact of CMD on Scoping 

The Compatibility Mode Driver (CMD) was written to provide a mechanism for “hiding” IPX 

from the wire, while providing backward compatibility with applications and physical devices that 

have dependencies on the IPX protocol. CMD is intended to be a temporary, intermediary between 

the IPX and IP worlds. CMD provides three different services. These are: 

• Software compatibility for applications with IPX dependencies. 

• Protocol Gateway for physical translation between IP and IPX devices. (Migration Agent 

Mode (MA) ) 

• Backbone support for automatic, self configuring, tunneling of IPX traffic between 

Protocol Gateways. This functionality is provided automatically between MAs on the 

same CMD network. 

Because CMD’s function is to provide backward compatibility for IPX dependent applications and 

devices, it pumps the IPX SAPs advertised by the servers with the SCMD.NLM loaded on them 

into the SLP scope(s) the servers are configured to register with. This has a very significant impact 

on scoping and your SLP infrastructure design. Basically, the SAP information is quite large and 

because of the 64 KB response packet limitation in the SLP v1 RFC (discussed above in the 

section “A Detailed Overview of SLP”), widespread use of CMD can result in the need to create 

many more scopes than would otherwise be necessary. 

Widespread use of CMD (not Novell’s recommended approach) will require far more scopes to be 

configured than would otherwise be necessary. Once a certain threshold has been crossed, 

regarding the number of scopes in global use and amount of NDS replication traffic, a non-global, 

more regional approach, to SLP design is in order. 



NDS Design Considerations for SLP 

Because SLP DAs store their services information in NDS, SLP’s impact on the NDS architecture 

must be taken into consideration when designing an SLP infrastructure. Most traditional NDS 

design rules apply to this architecture such as: 

• The need to minimize the number of replicas of a partition while still providing fault 

tolerance. 

• The need to minimize the amount of synchronization traffic crossing WAN links. 

• The need to manage the number of NDS objects per partition. 

• The need to place services close to the primary consumer. 

• The need to decentralize services and push them out to the Major Sites/Regions for fault 

tolerance 

The customer’s WAN Hub and Major Site network diagrams are used to determine the Hub points 

where SLP Directory Agents will be most effective and to minimize the number of Directory 

Agents required. 

The diagram below describes the recommended NDS architecture for SLP services. The SLP- 

Management container off of the root of the tree contains the DA objects and if an unscoped or 

global scope configuration is being used it contains the unscoped or global scope(s). The 

placement of the Global SLP-Management container in the tree is flexible and should consider the 

following: 

• The need to easily distinguish the Global SLP-Management container from other SLP- 

Management containers. 

• The need to minimize the number of Subordinate reference replicas. 

• The need to secure the container. 

If a scoped configuration is being used, then the SLP-Management container off of the root of the 

tree contains the DA objects and the Global services scope(s). The global service scope(s) should 

contain the services that need to be made globally available. In addition to the global scope, 

regional scopes need to be created at each WAN hub/major site for services that should be made 

available to users in an SLP region. These regional scopes are held in SLP-Management 

containers that are under the container for the WAN hub region/site they serve. 

In general Novell recommends the use of SLP for dynamic location of local services, and NDS 

and/or DNS for location of non-local services. 

In the scenario below, we assume five candidate locations for SLP Directory Agents. You will be 

using the customers WAN/Major site bubble diagrams collected during the Pre-Flight Checklist 

(PFC) for this purpose. We determined that there were five major points in this scenario where 

SLP Directory Agents could be placed. Three of these sites were WAN Hub sites and two were 

Major sites containing large numbers of users and servers. 



SLP-Management 

containers at the WAN 

hubs and Major sites are 

only used if a scoped 

configuration is used. If an 

unscoped or global 

configuration is used then 

these SLP-Management 

containers would not 

exist. Note that DAs are 

still listed at the global 

SLP-Management level. 

This is done because the 

latest versions of SLP will 

allow NDS based SLP 

Directory Agent discovery. 

WAN Site Hub 1 1 


Local Scope 

General SLP/NDS Design 

WAN Hub 2 


Local Scope 

Org. Name 

[ROOT] (Sample_Tree) 

The SLP-Management Container 

should contain the Directory Agent 

(DA) and unscoped or global SLP 

Scope Objects. This partition should 

be replicated to all DA Servers. This 


should not represent a problem 

provided that these scopes are 

relatively small, or adequate WAN 

resoursces exist to handle the 

replication traffic, and/or the "SLP 

SA Default Lifetime" is increased in 

order to reduce the frequency of 

DA Objects Un-Scope or 

updates to the SLP scope database. 

Global Scope Objects 

State/locality 1 State/locality 2 

Site 3 

WAN Hub 3 


Local Scope 

Major Site 1 


Local Scope 

Figure D11. General SLP/NDS design. 

Grey areas indicate 

partition boundaries 

State/locality 3 

Major Site 2 


Local Scope 

The SLPDA.NLM should never be loaded on a server unless the Scope Unit object and 

Directory Agent object the server will service have already been created. Never accept the default 

configuration offered by the SLPDA.NLM. In general the Scope Unit object should be created 

first then the DA object. This is because when you create the DA object you need to associate it 

back to the server that will host the DA and the Scope(s) it will service. Of course it is not possible 

to make this association if the Scope Unit has not been created yet. 

Note: CMD will not take SAP information from a legacy IPX segment and place them in the SLP 

scope. Only SLP enabled servers with CMD loaded on them will register their SAP information. 

As a result of the 64KB limitation, it becomes necessary to create multiple scopes when certain 

service entry counts are exceeded. In general SLP service queries are for a specific type of service 

such as “ndap.novell”, or “bindery.novell”. This means that the number of services of each type 

that may live in a single SLP scope is limited to the number that will fit in the 64KB response 

packet. This number is variable depending on the length of certain variables such as SAP names, 

server names, and partition names. The average number of each service type that may be placed in 

a single scope without overflowing the SLP response packet are as follows: 

• The Bindery.Novell service - 700 to 1100 depending on the length of server names. 

• The NDAP.Novell service - Around 1200 depending on the length of partition names. 

• The MGW.Novell service - Around 1200. 



• The Sapsrv.Novell service - No more than 540. Calculations based on SCMD engineering 

testing. 

As you can see, if the use of CMD is wide spread, and the average number of SAPs advertised by 

each CMD server is: 

• 4, the maximum number of CMD servers per scope is about 135. 





This issue is being addressed by SLP version 2; However, because SLP V2 is still in draft RFC 

mode and we will not implement this until it is an official RFC, we do not expect support for SLP 

v2 until late Q2 to Q3 of 2000. If service counts do become a problem at a large customer site you 

can start to use multiple scopes and DA's to get around this. For now, the applications using SLP 

have been getting around this issue by making service requests as explicit as possible. 

Minimizing the Number of SLP Scopes 

It will be important to minimize the number of SLP scopes in any environment. The reasons for 

this are as follows: 

• Reduction in overhead traffic from User Agents (UA). 

• Reduction in overhead traffic from Server Agents (SA). 

• Minimizing client configuration requirements. 

• Minimizing server configuration requirements. 

• Mitigating between good NDS design practices, and good SLP design practices. 

When User Agents (UAs) request services, the UAs on clients will place a packet on the wire for 

the unscoped scope and every scope it is configured to talk to. Server UAs will place a packet on 

the wire for the unscoped scope and every scope they know about, in search of a service. If more 

than one DA serves a scope, the server UA will query only the first active DA it knows about for 

each scope it knows about. Under these circumstances it could obviously be detrimental to create a 

large number of DAs without a real need to do so. 

The more scopes you create the more likely clients will need to query multiple scopes to find the 

services they need. If a customer wants to provide global short service name resolution through 

SLP, the larger the number of scopes, the more information is required in the clients scope list for 

clients to browse for services globally with SLP. Clients must be either manually configured with 

each scope and DA they need to talk to, or they need to be served this information from a DHCP 

server, or they need to discover these things dynamically through the use of multicast. Of course 

in most environments, multicast is not an option due to concern voiced by data communications 

staff for it and its limited ability to scale an SLP architecture. DHCP provides the next least 

administratively intense way to configure client UAs. This method requires the customer’s DHCP 

server options table to be extensible or that they implement Novell’s DHCP server that ships with 

NetWare 5.1. Other automated methods for configuring a client’s DA and scope information could 

include the use of “reg” files, the Novell Automatic client Upgrade (ACU) or ZEN’s Workstation 

Manager scheduled tasks. Finally, this information could be configured manually on each client 

machine. 

The more granular your SLP environment is, the more likely it is that servers will need to live in 

and register services in more than one scope. The more scopes a server must register with or 

query, the more SLP traffic it must generate each time it attempts to resolve or register a service 

name. 



While it is good practice to reduce the number of scopes wherever practicable there are times 

when best NDS design practices and best SLP design practices may be in direct conflict. Such as: 

• When replicating the SLP scopes partition to multiple DAs would unnecessarily increase 

the number of replicas in the replica ring. 

• When replication traffic would place detrimental loads on WAN links. 

• When the number of objects in an SLP scope is larger than prudent based on standard 

issues such as: 

• The speed of the hardware servicing the replica ring. 

• The speed of WAN links 

• The frequency of updates that trigger synchronization events. 

In these cases the consultant must weigh the issues and make the best determination possible with 

the information available whether or not it is advisable to create additional scopes. 



A Global SLP Design Example 

The following is an example of a global SLP design. This particular customer wanted all services 

to be available to their users through SLP. They are using the recommended dual stack approach 

to protocol migration, which eliminated the need to do extensive scoping for CMD servers. 

The WAN/Major Site Bubble diagram below shows that the Customer network can be reduced to 

a straightforward model for the design of an SLP infrastructure. The network is basically broken 

up by geographical region. Each of these regions contains a hub site, and the regional office sites 

radiate out from the respective hub site. These regional office sites are connected back to the hub 

sites through WAN links. These WAN links are generally of T-1 speed, although some are faster 

(DS-3) and some are slower (512, 256, and 56KB). Generally speaking, a non T-1 speed WAN 

link is the exception rather than the rule. 

A redundant DS-3 cloud connects the hub sites to one another. This provides for robust and fast 

connectivity between geographic regions that also happens to be fault tolerant. In the event the 

link through one cloud is not available, the sites are able to connect through the second cloud. 

While the links between the hub sites are redundant, the WAN links connecting hub sites to 

regional offices are not redundant. In the event one of those WAN links is down, the regional 

office will not be able to connect to the rest of the Customer network. 

The diagram below represents the customer network in its reduced form. From this diagram, the 

general network traffic flow can also be deduced. For any communications to travel between 

regional offices, the traffic must come out through at least one frame relay cloud before reaching 

its final destination. Figure D17 only shows how the hub sites are connected to one another. The 

regional office sites are connected to their hub sites through the local Frame Relay cloud on the 

diagram. 



FR to 

satelite 

offices 

FR to 

satelite 

offices 

FR to 

satelite 

offices 

H-Region 

Hub 

Atlanta 

Hub 

G-Region 

Hub 

FR to 

satelite 

offices 

B-Region 

Hub 

Frame Relay (FR) 

DS-3 

Cloud 

Los Angeles 

Hub 

FR to 

satelite 

offices 

Chicago 

Hub 

E-Region 

Hub 

FR to 

satelite 

offices 

D-Region 

Hub 

FR to 

satelite 

offices 

Figure D17. Hub sites are connected to one another through a Frame Relay cloud. 

FR to 

satelite 

offices 

The general user workflow on the network is also an important thing to consider. About 70% of 

the users at this customer are mobile and need to access their resources from anywhere on the 

network. However, those users that are not mobile generally use the network resources in their 

local offices. This workflow pattern needs to be supported in a pure IP environment, and SLP will 

help the customer accomplish that through a global service resolution environment. 

Now that the functional requirements have been defined and the physical network topology has 

been detailed, it is time to dive deeper into the SLP design. 

Designing the SLP Infrastructure Plan 

The key behind developing a long range SLP infrastructure plan is to minimize the amount of 

overhead traffic required to maintain the SLP infrastructure while staying true to the functional 

requirements of the organization. For convenience, the functional requirements of the customer 

with respect to the SLP infrastructure are listed below: 

• Currently, all services on the network are visible to all users. There is no filtering of SAP 

services on the network. This availability of services must be preserved in a pure IP 

environment. 

• Users are accustomed to browsing the network to find network resources. Because users 

are still in bindery mode, they are not aware of NDS or its hierarchical structure. The 

ability to browse the network independently of NDS to find network resources must be 

preserved in a pure IP environment. 

• The ability to use multicast addressed packets on WAN links as a method of service 

resolution is currently not permitted; however, if an appropriate business case can be 

shown as to why multicast addressed packets are needed, that policy may be changed. 



• The service resolution infrastructure must be fault tolerant. This infrastructure must 

provide a single fail-over mechanism for fault tolerance. In the event the enterprise 

service resolution infrastructure fails, clients must still be able to at least connect to their 

local file servers. 

• The service resolution infrastructure must be scalable to meet the needs of the customer 

in the future. It should be able to accommodate a transition to a pure IP environment as 

well as leave room for growth. 

While easy to design an SLP infrastructure that meets these functional requirements, it is a bit 

more of a task to design one that will not adversely affect the performance of the corporate 

network. 

There will effectively be two phases to the rollout of the SLP infrastructure to this customer. The 

first phase will be to the NetWare 5.1 servers on the network themselves to facilitate server to 

server communication. Even for this first phase of the rollout, the infrastructure must be designed 

with the second phase in mind to ensure it is scalable and robust. The second phase of the SLP 

infrastructure rollout deals with the client workstations themselves using the infrastructure for 

service resolution. 

Note: The rollout of the SLP infrastructure to the client workstations cannot be accomplished until 

the latest version of the NetWare client is installed on those machines. This client contains the 

SLP user agent necessary to make use of the SLP infrastructure. 

Phase I—Server to Server Communication 

The implementation of the long-range SLP infrastructure is going to be very similar to option 3 

discussed earlier, but as you will see some hybridization will occur. The configuration is going to 

be different to reflect different numbers of scopes and directory agents for the network, but the 

tools used to configure the environment are exactly the same as previously discussed. 

SLP Infrastructure Overview 

The SLP infrastructure will need to be able to accommodate 530+ servers on customer network. 

Keeping an eye to the future, the infrastructure will also need to be able to service the SLP queries 

of 30,000+ potential users on the network. The key to the whole infrastructure is going to be the 

directory agents. There need to be enough directory agents on the network in strategic locations to 

service the SLP infrastructure but not so many as to clog the network with SLP overhead traffic. 

Note: Because the directory agents are key to the SLP infrastructure, the boxes chosen to serve 

this function should be robust. They should have a fast processor, a large amount of memory, and 

good bandwidth to the network. Additionally, these servers should be lightly loaded servers; their 

primary function should be serving SLP information to the network. 

For the customer’s environment, three directory agents should be sufficient to handle the SLP 

infrastructure, given those servers are dedicated to that function. Those servers should be placed at 

major hub sites on the corporate network for a number of reasons: 

• Because the hub sites are connected to one another at DS-3 speeds, the DS 

synchronization traffic required for SLP would be most efficient. Placing directory agents 

at regional office sites might begin to tax the T-1 lines connecting those offices to the 

corporate network. 

• The hub sites are centrally located on the corporate network. Service registrations and 

service requests from clients need only go to the central hub sites. They do not need to 

traverse multiple WAN links to reach their destination. 



From a scoping perspective, one scope is not going to be sufficient for the number of servers on 

the customer’s network. Multiple scopes are going to be required, and they should be custom 

scopes. The UNSCOPED scope should not be used. The number of scopes required should also be 

minimized to reduce the amount of SLP traffic on the network for service resolution. 

In initial discussions with the customer staff, three scopes were considered based upon the time 

zones in the United States. However, after reviewing the data, it is evident that two scopes would 

be more efficient. The number of servers on the customer network would be split evenly between 

these two scopes, which means that each scope will hold the SLP service registrations for roughly 

265 servers. This provides much room for growth while minimizing the required traffic for SLP 

overhead. 

Each of the three directory agents on the network will service both SLP scopes; however, each 

server on the network will only register with a single scope. The DA objects will be located in a 

single container for NDS based DA discovery between the directory agents (requires NW5SP3 or 

later). This will ensure that all servers will be able to see all partitions in the NDS tree. This will 

maintain tree connectivity and integrity. 

Scope1 

ndap.novell 1 

ndap.novell 5 

ndap.novell 6 

FS1 

FS5 

FS6 

FS6 

Scope1 

ndap.novell 6 

FS5 

Scope1 

ndap.novell 5 

SReg 

FS1 

Scope1 

ndap.novell 1 

DA3 Services 

Scope1 

Scope2 

SReg 

DA1 Services 

Scope1 

Scope2 

WAN 

FS2 

Scope2 

ndap.novell 2 

DA2 Services 

Scope1 

Scope2 

Figure D18. Sample SLP infrastructure. 

Scope2 

ndap.novell 2 

ndap.novell 3 

ndap.novell 4 

FS2 

FS3 

FS4 

FS3 

Scope2 

ndap.novell 3 

SReg 

FS4 

Scope2 

ndap.novell 4 

Figure D18 illustrates how this setup would function. In this figure, each of the NetWare 5.1 

servers belongs to a single scope and registers its SLP services with a directory agent on the 

network. Only those servers registering with a particular scope are “seen” by the other servers 

belonging to that scope. This is acceptable because even though the “ndap.novell” services are 

split between the two global scopes, servers will be able to resolve NDS information because the 

UA on servers will query all scopes it knows about, and its DA will be serving both (all) scopes. 

For fault tolerance, it is a good idea to have each NetWare 5.1 server register its services with two 

of the three directory agents on the network. The DS synchronization process will ensure the 

directory agent that is left out of this direct service registration process will still get the necessary 

SLP information. This balances required fault tolerance in service registration with minimizing 

SLP overhead traffic. 



Selecting the Directory Agents 

The directory agents chosen to serve the SLP infrastructure should be selected based upon a 

number of criteria. The hardware configuration is important as well as the machines physical 

location on the corporate network. At this customer, the logical choices for directory agents are the 

DS master servers. In discussions with the customer’s staff, the following three servers are going 

to be recommended to function as directory agents: 

• ATLA_NDS1_US 

• CHIC_NDS1_US 

• LOSA_NDS1_US 

These servers are well distributed on the network. These three servers will provide fault tolerance 

for the SLP infrastructure. In the rollout of the second phase, client workstations should prefer to 

use the directory agent that is closest to them, although this is not going to always be guaranteed. 

Two scopes will need to be created to service the customers SLP infrastructure. The names for 

these scopes are not critical; however, they should be easy to remember. The scope names should 

be similar to one another in terms of a naming standard. In the event that more scopes are needed, 

adding another scope is an easy thing to do; however, it will require manual reconfiguration of the 

user agents to make use of the new scope. The following are recommended scope names for this 

customer: 

• SLP_SCOPE1_US 

• SLP_SCOPE2_US 

Configuring the Directory Agents 

After the directory agents have been selected and the scopes decided, it is a matter of setting up 

the directory agent infrastructure. This is mostly accomplished through NetWare Administrator. 

Objects need to be created in the NDS tree to house the SLP information that will be registered by 

service agents on the network. The following objects will need to be created in the customer’s 

NDS tree: 

• 2 SLP Scope Unit objects to represent SLP_SCOPE1_US and SLP_SCOPE2_US. 

• 3 SLP Directory Agent objects to represent ATLA_NDS1_US, CHIC_NDS1_US, and 

LOSA_NDS1_US. 

A more appropriate place for these objects will also need to be created in the NDS tree. Each of 

the 2 SLP Scope Unit objects will be made into its own partition. These partitions should exist in 

an area of the tree where the number of subordinate references to them is minimized. A new 

organizational unit should be created beneath the selected context to house the SLP information 

for the NDS tree. This organizational unit can be called SLP, which would reflect its function in 

the tree. 

Figure D19 illustrates how the NDS objects pertaining to SLP would look in the NDS tree. 



Figure D19. SLP objects in an NDS tree. 

Figures D20 and D21 show the details of the SLP Scope Unit objects. Note the value of the Scope 

Name field is SLP_SCOPE1_US. This is the location where the actual SLP scope value is set. 

Also, all directory agents service each scope. This is shown by the Serviced by fields in the 

figures. 

Figures D22 through D27 show detailed information about the directory agent objects themselves. 

Note that the value for the cache limit is 2048KB, or 2MB. This should be sufficient to hold the 

necessary SLP service information for the 2 scopes. 

Figure D20. Configuration information for the SLP_SCOPE1_US Scope Unit object. 



Figure D21. Configuration information for the SLP_SCOPE2_US Scope Unit object. 

In the NDS tree, the SLP Directory Agent objects would need to be associated with NCP server 

objects. Clicking on the browse button to the right of the Host Server field will accomplish this. 

The scopes serviced by the directory agent are configured from the SLP Scope Unit property page. 

To allow the directory agent to service a scope, click on the Add button and find the SLP Scope 

Unit object in the NDS tree. 



Figure D22. Configuration tab property page for the ATLA_NDS1_US_SLPDA NDS object. 

Figure D23. SLP Scope Units property page for the ATLA_NDS1_US_SLPDA NDS object. 



Figure D24. Configuration tab property page for the CHIC_NDS1_US_SLPDA NDS object. 

Figure D25. SLP Scope Units property page for the CHIC_NDS1_US_SLPDA NDS object. 



Figure D26. Configuration tab property page for the LOSA_NDS1_US_SLPDA NDS object. 

Figure D27. SLP Scope Units property page for the LOSA_NDS1_US_SLPDA NDS object. 

From a partitioning and replication perspective, all directory agents should have a copy of the 

partition/s that contain the SLP information. This will facilitate the efficient exchange of SLP 

information through NDS. Because this partition becomes an active partition, only directory 

agents should hold a copy of the partition. At this customer, new partitions should be created out 



of the SLP_SCOPE1_US and SLP_SCOPE2_US SLP Scope Unit objects. Because these objects 

are container objects within NDS, they can be their own partitions. 

This new partition/s should have replicas placed on the ATLA_NDS1_US, CHIC_NDS1_US, and 

LOSA_NDS1_US servers because they are the servers functioning as directory agents. There 

could be some resultant subordinate references because of the partitioning and replication strategy 

used at the customer, but those subordinate references should not adversely affect the performance 

of NDS. The partitioning and replication strategy can be reviewed and modified to minimize the 

number of subordinate references present for these partitions. 

Directory Agent Service Agent Configuration 

Once the configuration of the SLP infrastructure has been completed in NDS, the service agent 

pieces on the directory agents need to be configured. This is a straightforward procedure that 

involves setting some parameters through the server console or modifying configuration files. 

Because multicast is not supported across the WAN we will need to be sure the DAs can discover 

each other. This will be accomplished by statically pointing the DAs at each other by modifying 

the SLP.CFG file in the servers’ SYS:ETC directories. If the NetWare 5.0 Support Pack 3 or later 

is applied, this can be accomplished through NDS provided all of the DA objects are stored in the 

same NDS context. 

The text below shows a sample SLP.CFG file for the directory agents at this customer. There is 

one thing to note here. With the application of the NetWare 5.0 Support Pack 3 and later, fully 

qualified DNS names can be used to refer to the directory agents on the network. IP addresses will 

also work. 

;This is a sample of the SLP configuration file. 

;Two types of entries can be made: 1)DA entries, 2)SA Register Filters 

; 

;The DA entry allows static configuration of a known DA. This would be used when 

;the DA is out of multicast range (or multicast is not supported) and DHCP is ;not 

being used to configure the DA. 

;The static DA configuration format is as follows ‘DA , ’. 

;The first word must be “DA”. The Addr Type is the address type. Currently, only 

;IPv4 has been defined. IPv6 will be defined in the future. The Addr is the IP 

;Address specified. NW5SP3 or later will also support FQDN DNS names. 

; 

;The following is an example of a static DA. 

;DA IPV4, 130.1.1.1 

; 

;The SA Register Filter would be used when the administrator wanted all services 

;of a specific type to be mapped to specific scope/s. For example, the 

;administrator wants all “LPR” printers mapped to scopes “print” and “a-region”. 

;The format is as follows: ‘REGISTER TYPE ““ to SCOPE ““’. 

;The parser will look for REGISTER, TYPE and SCOPE as keywords followed by a 

;double quote on a single line. Multiple scopes are defined with a comma 

;delimited list. Example: 

; 

;REGISTER TYPE “lpr” to SCOPE “print,a-region” 

; 

;The last line in the file must contain a carriage return and line feed. A 

;semicolon specifies a comment. 

; 

DA IPV4, atla-nds1-us.abc.com 

DA IPV4, chic-nds1-us.abc.com 

DA IPV4, losa-nds1-us.abc.com 



Besides modifying the SLP.CFG file, there need to be two other modifications made at the server 

consoles of the directory agents: 

The SLP Scope List parameter needs to be set. In MONITOR, select Server Parameters->Service 

Location Protocol. In the parameters that appear, set the SLP Scope List to SLP_SCOPE1_US, 

SLP_SCOPE2_US. 

The SLP SA Default Lifetime parameter needs to be modified on all NetWare 5.1 servers. In 

MONITOR, select Server Parameters->Service Location Protocol. In the parameters that appear, 

set the SLP SA Default Lifetime to something greater than the default of 3600 seconds (one hour). 

Two to four hours would be a good place to start, and depending on stability and performance, this 

may be increased to a maximum of 65535 seconds (18+ hours). 

Those modifications will allow the directory agent to register its services with both scopes. It also 

changes the default registration time on all servers from one hour to two or more hours. This 

means that the services available on these servers will only need to update their service TTLs once 

every two or more hours, which will reduce the amount of SLP overhead traffic. 

Note: When modifying the value of the SLP Scope List or SLP SA Default Lifetime parameter, 

the server must be rebooted in order for the modification to take effect. 

After the modifications have been made and the server has been rebooted. Issue the following 

command from the server console of the directory agent: 

SLPDA 

Additionally, the AUTOEXEC.NCF file on the Directory Agent servers should be modified to 

load the SLPDA.NLM when the server boots. This will ensure the directory agent will be 

available in the event the server is rebooted. 

Configuring the Remaining NetWare 5.1 Boxes 

Outside of the three directory agents on the network, there will be 530 or more servers that will 

need to be configured to use the SLP infrastructure. There are three modifications that will need to 

be made per server to allow it to participate in the SLP infrastructure. They are as follows: 

• The SLP.CFG file on each server must be modified to specify the directory agents that 

server will use for service registration and service resolution. 

• The SLP Scope List needs to be set on each server. 

• The SLP SA Default Lifetime parameter needs to be set to 7200 or greater. This will 

require service re-registration once every two or more hours instead of once every hour. 

Before these modifications are made the list of servers needs to be assessed and examined. The 

servers need to be divided into two groups; these two groups will represent the two scopes that 

have been defined for the SLP infrastructure. The servers that need to be included in both groups 

are the NDS master servers on the customer network. 

Additionally, servers should be grouped in terms of the directory agents they will be using for 

service registration and service resolution. This is not as critical as the scope division described 

above, but there should be a good balance between the available directory agents on the network. 

SLP_SCOPE1_US Servers 

The servers that are chosen to be part of the SLP_SCOPE1_US scope should be configured in the 

following manner: 



• The SLP.CFG file must be modified to reflect two of the directory agents on the network. 

• The SLP Scope List must be set to the value SLP_SCOPE1_US. 

• The SLP SA Default Lifetime parameter must be set to 7200. 

SLP_SCOPE2_US Servers 

The servers that are chosen to be part of the SLP_SCOPE2_US scope should be configured in the 

following manner: 

• The SLP.CFG file must be modified to reflect two of the directory agents on the network. 

• The SLP Scope List must be set to the value SLP_SCOPE2_US. 

• The SLP SA Default Lifetime parameter must be set to 7200. 

Note: Any time SLP scope or default lifetime parameters are modified on a server, it must be 

rebooted for the changes to take effect. 

Once the modifications have been made to the servers and they have been rebooted, they will be 

able to participate in the SLP infrastructure. When all servers have been configured, phase one of 

the SLP infrastructure rollout is complete. All NetWare 5.1 servers will be taking advantage of a 

fault-tolerant, robust service resolution mechanism. 

Impact of SLP Overhead Traffic 

It is important to look at the impact of the overhead traffic necessary to maintain the SLP 

infrastructure on the network. To reiterate the general equations that are used to calculate this 

traffic, the average amount of traffic on the network over the course of the default service lifetime 

is calculated as follows: 

(# of servers) x (avg. # of SLP registrations/server) x (avg. bandwidth/registration) 

The average number of registrations per server can be calculated as follows: 

(avg. # of SLP services/server) x (# of configured DAs/service) x (# of configured scopes) 

From the information gathered about the customer network, there are 536 servers on the network 

that will eventually participate in the SLP infrastructure. The average bandwidth required per 

service registration is 400 bytes. The average number of SLP services per server is seven, the 

number of configured directory agents per server is two, and the number of configured scopes 

from the infrastructure design is one (with the possible exception of the directory agent servers). 

Given these figures, the amount of traffic over the course of the default service lifetime (two 

hours) required to maintain the SLP infrastructure is about 2.86MB. Again, this is an aggregate 

value that is spread across the entire network with each directory agent seeing about one third of 

this traffic. 

To reiterate, this traffic is due to SLP overhead alone. It does not factor in the increased traffic due 

to NDS synchronization. Nor does it account for any SLP service resolution queries required by 

the servers on the network. However, across an enterprise network with a large amount of 

bandwidth, 2.86MB of data spread across the network every two hours is an acceptable amount of 

overhead for a service infrastructure. 

Phase II—SLP for Client Workstations 

The most difficult piece of setting up the SLP infrastructure really occurs in phase one. Once all of 

the SLP services on the network have been registered with the directory agents, the client 

workstations can query the directory agents and retrieve complete lists of available SLP services 



on the network. The only thing that is really required for the client workstations to make use of the 

SLP infrastructure is the installation of the latest version of the NetWare client. 

Configuring the Client Workstation 

There are a number of ways a client workstation can resolve services on the network. Because this 

customer requires short name resolution and browsing of network resources, client workstations 

are going to need to utilize the SLP infrastructure. The other methods of service resolution can still 

be used, but SLP should be the primary method of service resolution on the network. 

After the latest NetWare client has been installed on the client workstation, it will attempt to use 

the SLP infrastructure by default. This can be verified in the property pages of the Novell client. 

To see these property pages, go into the Network applet on Windows 95/98/NT. Enter the property 

pages of the Novell client. Once there, select the Protocol Preferences tab. On that property page, 

the various methods of name resolution are displayed, as shown in Figure D28. 

Figure D28. The Novell client property pages on Windows NT. 

For the client to use the SLP infrastructure, the box to the left of SLP must be checked. It will also 

make the client more efficient if unused name resolution mechanisms are unchecked. For instance, 

if DNS is not going to be used as a method of name resolution for NetWare client services, the 

box to the left of DNS should be unchecked. This will not affect normal DNS name resolution for 

general IP-based applications, such as Netscape. 



There are some other parameters that need to be configured for the clients to be able to use the 

SLP infrastructure that was set up in phase one. Because the customer is not using multicast as a 

discovery mechanism for directory agents, the directory agent addresses must be statically 

configured at the client. With this, the SLP Scope List for the clients must also be modified. This 

is accomplished through the Service Location tab, which is shown in Figure D29. 

In the Service Location tab, there are places to specify the Scope List and the Directory Agent 

List. The Directory Agent List can hold either the IP addresses of the directory agents on the 

network, or it can hold the fully qualified DNS names of the directory agents. The Scope List 

specifies to which scopes the client workstation belongs. As can be seen in Figure D29, the client 

workstation belongs to both the SLP_SCOPE1_US and SLP_SCOPE2_US scopes. The reason for 

this will be explained. The check in the Static box means the client is statically configured. 

Figure D29. The Service Location property page of the Windows NT Novell client. 

As was shown in the previous section, the servers available on the network have been split into 

two separate scopes. If the client belonged to a single scope, it would only be able to see those 

servers that also belonged to that scope. Effectively, the client would only be able to see one half 

of the servers on the network. This does not fit this customer’s functional requirements of the SLP 

infrastructure; however, making the client a member of both scopes will allow the client to see all 

of the servers on the network. 

For fault tolerance, all directory agents on the network are listed in the Directory Agent List. In the 

event the client’s primary directory agent is unavailable, it will attempt to use the next one on the 

list. Thus, all directory agents will need to have failed or the WAN link connecting the regional 



office to the hub site will have to have been severed for the client to be unable to resolve SLP 

services. 

The one drawback to this phase of the rollout is that the client workstations need to be manually 

configured because this customer cannot make use of DHCP or ZENworks to automate the rollout 

of the SLP information. However, if a tool is available that will allow the network administrators 

to make Windows registry modifications remotely, these modifications can be automated. Novell 

strongly urges the automation of as much of this configuration as possible within a given 

computing environment. 

Modeling Client Service Resolution Traffic 

While it is straightforward to configure the client workstations to use the SLP infrastructure, it is 

important to understand how the clients are actually using the infrastructure for service resolution. 

In the event there are performance problems, this insight will aid in the problem resolution. 

When a client first boots up, it will attempt to find its preferred tree or preferred server. To do this, 

it will issue an SLP service request looking for a list of services available on the network. Before 

actually sending out the SLP queries, the workstation will have determined its primary directory 

agents on the network. A primary directory agent will be specified for each of the workstation’s 

SLP scopes. 

In the case of the customer’s SLP infrastructure, the client workstation will look to its static list of 

available directory agents. It will attempt to activate each one of those directory agents 

simultaneously. The first directory agent to respond will be considered the “primary” directory 

agent. Subsequent replies will cause the workstation to mark the directory agent as “active”, but it 

will not submit queries to those directory agents unless the primary directory agent is unavailable 

or the query is to a scope that can only be serviced by another directory agent. 

This process is repeated for each of the workstation’s SLP scopes. Thus, each client workstation 

will have two primary directory agents. One primary directory agent will be designated for 

SLP_SCOPE1_US, and one primary directory agent will be designated for SLP_SCOPE2_US. 

The primary directory agents for each scope may be the same or it may be different. For instance, 

CHIC_NDS1_US may be a workstation’s primary directory agent for SLP_SCOPE1_US while 

ATLA_NDS1_US may be a workstation’s primary directory agent for SLP_SCOPE2_US. It all 

depends upon the network latency and quickness of response on the part of the directory agents on 

the network. 

When a query for SLP services is requested, such as the one to resolve the preferred tree or 

preferred server, the workstation will send a query to each of its primary directory agents. Thus, 

for each service resolution, the SLP user agent on the workstation really makes two separate 

queries to each scope, collates the results, and passes the information back to the requesting 

application (Figure D30). 

One important fact to glean from Figure D30 is that all SLP service requests must cross at least 

one WAN link to get to a directory agent. In the event the WAN link is not available, there will 

not be any global service resolution from SLP. As will be explained in the next section, clients 

will still be able to access local NetWare services. But network browsing will not be available 

until the WAN link connection is restored. 



Primary DA 

SLP_SCOPE1_US 

Hub site 

Frame Relay 

DS-3 

Hub site 

Primary DA 

SLP_SCOPE2_US 

Hub site 



Frame Relay 

(Regional) 



Regional office 

Figure D30. Sample SLP service resolution process for the SLP infrastructure. 

Desktop System 

In the event the primary directory agent is not available, the client will wait for a response based 

upon the Wait Before Giving Up On DA timer. By default, this value is 5 seconds. Once the client 

deems the DA unreachable, the client will attempt to contact the next active DA for that scope in 

its list. 

The client workstation will cache information it receives about services through SLP. The Cache 

SLP Replies timer on the workstation determines the amount of time this information is kept. By 

default, this value is 1 minute. The default values for these settings should be acceptable for the 

customer’s SLP infrastructure. 

WAN Link Failures and Client Fault Tolerance 

By looking at Figure D30, it is clear to see the SLP infrastructure is dependent upon the WAN 

links at this customer. While the DS-3 backbone connecting the hub sites is redundant, the WAN 

links connecting the regional offices back to the hub sites are not. Additionally, the clients are 

dependent upon SLP to find their preferred server or preferred tree. How will the clients be able to 

connect to their local file server in the event of a WAN link failure? 

There are two states that need to be addressed to completely answer this question, but the baseline 

is that the clients and local servers will fall back to the default method of SLP communication. 

They will begin to use multicast to find the services that are local to them. This means that 

multicast must be enabled on a per regional office basis. No multicast needs to cross the WAN 

links when they are active, but all machines need to participate in a local multicast infrastructure 

in the event the SLP infrastructure is unavailable due to a WAN link failure. 

How the client workstation will respond to this WAN link failure is dependent upon the state of 

the client. There are two scenarios, and they are listed below: 



• The client workstation is booted after the WAN link failure. 

• The client workstation was using the SLP infrastructure before the WAN link failure. 

In the event the client workstation is booted after the WAN link failure, the machine will come up 

as normal. It will attempt to activate the directory agents listed in its statically configured list; 

however, they will not be activated because the WAN link is down. After the activation process 

fails, the client workstation will use the normal multicast method of SLP communication, as 

described in the section “Default SLP Communications,” to find any services that are local to it. 

This is the final fail-over mechanism for SLP. 

In the event the client workstation was using the SLP infrastructure before the WAN link failure, 

the machine may not experience any difficulties unless the user attempts to access a network 

resource not on the local LAN. Only if an SLP query is sent from the client to the directory agents 

after the WAN link failure will there be a delay in services. The client workstation will attempt to 

contact its primary DA for each scope and fail after five seconds. It will then attempt to contact the 

next active DA in the list, which will also fail after five seconds. Finally, it will attempt to contact 

the final active DA in the list, which again will fail after five seconds. After that, it will use the 

normal multicast method of SLP communication to find any services that are local to it. Because 

each client workstation has three configured directory agents, the time out period should be 15 

seconds before reverting to multicast. 

Once the WAN link connectivity has been restored, the client workstations should eventually 

reactivate their directory agents. However, to quickly facilitate this reactivation, reboot the 

workstations. 

SLP Infrastructure Room for Growth 

With this SLP infrastructure, the customer will have room for growth and scalability. There are 

two main ways that the SLP infrastructure can be impacted in the future at this customer. They are 

as follows: 

• A large number of NetWare 5.1 servers are added to the network. Because they will need 

to register and resolve services, they will need to participate in the SLP infrastructure. 

• The number of SLP services advertised per server increases. This can be the result of 

deploying Migration Agents on the network as part of an IPX to pure IP migration 

strategy. 

In either one of these scenarios, it can be shown that the designed SLP infrastructure can handle 

the growth. Because of the limitation of SLP version 1, only 400 to 500 servers should be included 

in any single SLP scope. This number drops drastically if CMD is used. After the initial 

deployment of phase one, each scope will house roughly 270 servers. This leaves room for growth 

of up to another 150 servers per scope. Thus, the customer’s network can grow by up to 300 

additional servers before the SLP infrastructure needs to be modified. 

If more SLP services per server require advertisement on the network, there will be no problem. 

The only impact that increase will have will be on the amount of SLP overhead traffic required to 

maintain the SLP infrastructure. That can be easily calculated based upon the equations that were 

provided earlier in this document. 

For the first scenario, the increase of 300 servers on the network participating in the SLP 

infrastructure will increase the amount of required SLP overhead traffic to approximately 4.54MB 

of traffic. Again, this is an aggregate amount of traffic spread across the entire network once every 

two or more hours, depending on the value of the “SA Default Lifetime” parameter. 

In the second scenario, the increase of advertised SLP services will increase the amount of 

required SLP overhead traffic. The amount that this traffic will increase depends upon the number 

of new SLP services being advertised. Taking the example of the Migration Agent, the average 



number of SLP services being advertised per server will increase from seven to ten. This translates 

into approximately 4.09MB of traffic once every two or more hours, depending on the value of the 

“SA Default Lifetime” parameter. 

If it came to pass that both scenarios occurred in the customer’s environment, there would be an 

increase in the amount of required SLP overhead traffic. Running 850 servers at 10 SLP services 

per server through the equations, the amount of traffic due to SLP overhead would be 

approximately 6.48MB every two or more hours, depending on the value of the “SA Default 

Lifetime” parameter. 

These are numbers that are easily handled by the corporate network at this customer. There is 

definitely room for growth with the current design strategy. In the event that the customer does 

outgrow their current SLP infrastructure, it is fairly easy to scale it to accommodate the new 

demand. 

There are two ways that the customer may grow that would impact the SLP infrastructure. They 

are as follows: 

• The client load becomes too great for the three directory agents on the network. 

• There is a large influx of servers and more than the recommended number of servers is 

registered within the two SLP scopes. 

The SLP infrastructure is scalable so that these new demands can be met; however, it will require 

a significant amount of reconfiguration on the servers and clients. Should the client load become 

too great for the current number of directory agents on the network, another directory agent can be 

added to the network. This addition would have the following impact on the customer’s network: 

• The amount of traffic due to NDS synchronization traffic would increase because an 

additional replica of the SLP partition would be added to the replica ring. 

• The NetWare 5.1 servers on the network would have to be reconfigured so the load from 

their service registrations is distributed evenly across the four directory agents. 

• The NetWare clients would have to be reconfigured to make use of the new directory 

agent on the network. 

If the customer acquires a large number of new NetWare 5.1 servers, it may exceed the 

recommended number of servers registering per SLP scope. In the event the current scoping 

environment is obsolete, another scope can be added to the SLP infrastructure. Servers can be 

redistributed to the new scope so that any design limitations are met. Adding an additional scope 

would have the following impact on the customer’s network: 

• The amount of traffic due to NDS synchronization traffic would increase because there 

would be a new partition that needed to synchronize on a frequent basis. 

• The NetWare 5.1 servers on the network would have to be reconfigured so they can make 

use of the new scope. This means that the directory agents and NDS master servers would 

have to belong to all scopes. 

• The NetWare clients would have to be reconfigured to become a member of the new 

scope. This is required for end-to-end browsing and short name resolution on the 

network. 

While there would be a large amount of administrative overhead required adding a new directory 

agent or new scope to the SLP infrastructure, the infrastructure is scalable. However, this really 

should not be needed for a long time, as there is plenty of room to grow with the current SLP 

infrastructure design. 



Conclusion 

This example provides detail about the SLP technology and how Novell has implemented it with 

respect to NetWare 5.1. Additionally, it proposes a long-range SLP infrastructure design that 

fulfills the customer’s functional requirements set down: 

• All services on the network will be visible to all users using the SLP infrastructure. This 

availability of services will be preserved in a pure IP environment. 

• The ability to browse the network independently of NDS to find network resources will 

be preserved in a pure IP environment through the SLP infrastructure. 

• Multicast will not been used to implement the SLP infrastructure on the enterprise 

network. Multicast will only be used in the event of a WAN link failure, and it will be 

used only on the regional office segments. It will not be used across WAN links. 

• The service resolution infrastructure will be fault tolerant. This infrastructure will provide 

at least a single fail-over mechanism for fault tolerance. In the event the enterprise 

service resolution infrastructure fails, clients will still be able to at least connect to their 

local file servers. 

• The service resolution infrastructure will be scalable to meet the needs of the customer in 

the future. It will be able to accommodate a transition to a pure IP environment as well as 

leave room for growth. 

With the proposed SLP infrastructure, the customer will have a solid cornerstone upon which they 

can build a powerful and robust NetWare computing environment based upon the TCP/IP 

protocol. 

When Not to Use a Global SLP Design 

This section will discuss when the Global approach to SLP design may not be appropriate. 

Wan Link Constraints 

The customer may not have sufficient bandwidth to support a global approach to SLP. This may 

necessitate a look at the overhead demands of the SLP infrastructure and the current loading of 

their WAN links to determine if the SLP infrastructure proposed would place more overhead on 

the WAN than the service resolution protocols being replaced. 

NDS Synchronization Traffic 

This goes back to the WAN link constraints with regard to replication of scope partitions across 

WAN links. It adds the concern of whether or not it is prudent from an NDS design perspective to 

replicate across WAN links, and must take the size of the scopes being replicated, the speed of the 

replica ring hardware, and the speed of the WAN links into consideration. 

UA, SA, DA, and Client Traffic 

A global approach to SLP means that client UAs will be sending multiple request packets to every 

scope in the network. This may put unnecessary traffic on the WAN that could be managed more 

effectively with a regional approach to SLP design. 

The SA on NetWare 5.1 servers will query every scope known to them to find services. In a global 

approach all servers know all scopes. This may put unnecessary overhead on the network. It may 

be more prudent to create a very limited global scope and regional scopes so that SAs limit the 

number of scopes they query, and queries to the global scopes only return results when the 

services they are looking for are in that scope. 



DAs will know about all DAs and therefore all scopes so all DAs will query all scopes when their 

UAs look for services. This is true in all approaches to SLP, so the amount of overhead traffic is 

directly proportional to the number of scopes in the network. 

64KB SLP Response Packet Size Limit 

Depending on the size of the customer’s network and/or the amount of CMD servers in the 

environment, you may run up against the 64 KB single response packet limitation of SLPv1. This 

may necessitate the implementation of more regional scopes, this would increase SLP overhead 

traffic if consideration were not given to regionalizing the SLP traffic and limiting the number of 

globally available scopes. 

CMD Requirements for Scoping 

The number of CMD servers in the network and the average number of SAPs advertised by each 

CMD server can drastically limit the number of servers per SLP scope. This means that the 

number of scopes can increase drastically as a result. This may necessitate the implementation of 

more regional scopes, this would increase SLP overhead traffic if consideration were not given to 

regionalizing the SLP traffic and limiting the number of globally available scopes. 

Need to Limit Service Visibility 

If the customer is currently filtering SAP services in order to limit service visibility, then a 

regional, or service visibility area approach may need to be taken in order to accommodate the 

customers design goals and criteria for their SLP environment. 



A Regional SLP Design Example 

This section will focus on a customer whose needs indicated that a regional approach to SLP was 

in order. This section will not include the comprehensive technical information given earlier. If 

you do not understand the concepts being laid out in this section, you should return to the 

beginning of this section and review the technical information supplied in the preceding sections. 

The Customer Environment 

This section will explore the customer’s environment and the criteria upon which the design 

decisions are made. 

WAN Environment 

The customer’s WAN diagrams (Figure D31) show that they have over 800 sites connected by 

Frame Relay to three major hub sites. These three hub sites are connected in a linear fashion and 

there is no redundancy in the WAN backbone of the environment or at connected sites. The vast 

majority of the satellite sites are connected via Frame links that are 28.8kbps CIR with a 56kbpsclock 

rate. The hub sites are connected via T-1 clocked, 256kbps CIR Frame circuits. None of the 

circuits are compressed. 

~266 56k FR 28.8 CIR 

Mixed NWIP,IPX 

NWIP 

DSS 

Hub Site 

Region B 

no multicast 

~266 regional sites 

~86 servers 

Proposed CMD Region 

no multicast 

T-1 FR 256k CIR 

IP Only 

~266 56k FR 28.8 CIR 


NWIP 

DSS 

Hub Site 

Region A 


~173 servers 

Proposed CMD Regions 

T-1 FR 256k CIR 

IP Only 



~266 56k FR 28.8 CIR 


Figure D31. Customer WAN diagram with Proposed CMD Region 

no multicast 

NWIP 

DSS 

Hub Site 

Region C 

no multicast 


~86 servers 

Proposed CMD Region 

This customer has NWIP in their environment. DSS servers are located at each of the three major 

hub sites. Some satellite sites have forwarding gateways, some are NWIP sites and some are IPX 

only sites (correctional facilities) where IP traffic (for Internet access) is not allowed. The use of

NWIP will make it necessary to implement Migration Agents (MA) and CMD servers to maintain 

full connectivity during the migration process. 

Multicast is not supported even between LAN segments on the same physical site. 

The top level NDS has been designed to represent the WAN architecture, which facilitates the SLP 

infrastructure design. 

The Customer has about 400 NetWare servers in their entire environment. 

They currently do not use DHCP. All IP configuration on the clients is manual. 

LAN Environment 

The vast majority of this customer’s satellite offices consist of single server, or client only sites. 

Many of these sites have no need to communicate with other sites. The links are there for 

administrative purposes, client connectivity from non-server sites, and for the occasional user who 

in fact does connect to other sites. In spite of this scenario, many sites have severely congested 

WAN links. This is mainly due to the use of terminal emulators, and congestion in the FR provider 

network, not NetWare traffic. 

User Environment 

The majority, if not all, of the clients use the Novell client software. Little or none of them use 

Microsoft networking. ZENworks is not in use in the environment. They currently do not use 

DHCP. All IP configuration on the clients is manual. 

Design Goals and Criteria 

We have established that the customer’s offices do not need the global browsing capabilities 

provided with SAP or global SLP designs. It is therefore unnecessary to place the overhead of a 

global SLP design on the customer’s slow network links. 

The speed and congestion of some links and of the Frame Relay service provider’s network 

preclude requiring users to make requests to several global scopes. 

The lack of a multicast environment means servers and clients both will need to be statically 

configured. 

The use of NWIP will require the setup of Migration Agents. 

To outline, the customer’s objectives are as follows: 

• Provide local short name resolution. 

• Minimize the number of scopes. 

• Minimize NDS synchronization across WAN links. 

• Minimize SLP overhead traffic across WAN links. 

• Provide an SLP architecture to support the Migration Agent architecture. 

• Provide the ability for a select few individuals to do global SLP browsing. 



Limitations and Considerations 

The primary considerations driving this architecture are the severely constrained and slow 

bandwidth WAN circuits. This absolutely necessitates minimization of the NDS sync. and SLP 

overhead traffic. 

Secondly, the SLP architecture was required because of the intended CMD servers in the 

environment. The NWIP architecture is very sensitive to the creation of routing loops so a 

carefully crafted SLP architecture is necessary to support the CMD architecture and the Migration 

Agents until the upgrade process is complete. 

Finally, the use of CMD in the environment precludes the creation of large scopes and requires a 

minimum of 4 scopes based on an average number of 4 to 5 SAPs per CMD server. 

Phase I—SLP Infrastructure Design 

This section will outline the actual design that was derived from the information collected above. 

NDS Design 

Figure D32 shows how the SLP NDS Information was integrated into the customer’s existing 

NDS Infrastructure. 



Org. Name 

State/locality 1 

B-Region Hub 


B-Region Scope 

Regional SLP/NDS Design 

[ROOT] (Sample_Tree) 


DA Objects Global Scope 

Object 

A-Region Hub 


A1-Region 

Scope 

A2-Region 

Scope 

Grey areas indicate 

partition boundaries 

The SLP-Management Container should contain 

the Directory Agent (DA) and global SLP Scope 

Objects. This partition should be replicated to all 

DA Servers. This should not represent a 

problem provided that these scopes are 

relatively small, or adequate WAN resoursces 

exist to handle the replication traffic, and/or the 

"SLP SA Default Lifetime" is increased in order 

to reduce the frequency of updates to the SLP 

scope database. 

C-Region Hub 


C-Region Scope 

Figure D32. NDS Architecture to support a Regional SLP Design 

As you review this diagram please take note of the following: 

SLP-Management containers 

at the WAN hubs and Major 

sites are only used if a 

scoped configuration is used. 

If an unscoped or global 

configuration is used then 

these SLP-Management 

containers would not exist. 

Note that DAs are still listed 

at the global SLP- 

Management level. This is 

done because the latest 

versions of SLP will allow 

NDS based SLP Directory 

Agent discovery. 

• The SLP-Management container at the root of the tree is intended to be partitioned. The 

SLP-Management containers at the three hub sites are intended to be partitioned also. 

• The Global SLP-Management partition, which contains all of the DA objects, is 

replicated to all of the DAs as is the global scope partition. 

• The regional SLP-Management partitions with their regional scopes are replicated only 

between servers at the regional hub site. 

This approach limits NDS synchronization and SLP registration traffic that crosses the WAN 

backbone to only those services that are placed in the global scope. This allows services to remain 

local or regional except for the “essential” services that it is determined should be globally 

available. Services are published globally by redirecting service types to the global scope, or 

placing static entries for essential services in the global scope. 

Directory Agent (DA) Placement and Configuration 

The logical choice in placing the DAs was one of two approaches: 



• Place the DAs on the existing NDS replica servers in the customer environment. 

• Add an additional replica server to each hub site to support NDS, SLP and CMD/MA. 

Because the current replica servers are the NWIP DSS servers and these servers will be connecting 

the three separate CMD environments at the customer site, the customer chose to provide new 

servers to host NDS, SLP and CMD/MA services. The addition of these replica servers allowed 

the customer to further reduce NDS replication across the WAN links by allowing the elimination 

of fault tolerant replicas that were at other WAN hub sites. 

For fault tolerance, the customer does intend to deploy a backup set of DAs once the NetWare 5.1 

migration is complete. 

The SLP Region ‘A’ DA configuration 

First we will cover the SLP set parameters that are set on the region ‘A’ DA. As you will see many 

of these parameters are identical across all DAs which will ease the complexity of modifying and 

distributing these set commands as well as the configuration files. 

The set parameters may be set through the monitor utility, set at the command prompt, or set with 

an NCF file. It is also possible to distribute these settings or NCF files with the On-Site Admin Pro 

utility available on the Novell Support web site at http://support.novell.com. 

The set parameters are as follows: 

• “Set SLP Scope List = A1-Region” This is necessary to tell the DA to register all of its 

own services with one of the ‘A’ Region scopes. 

• “Set SLP SA Default Lifetime = 65535” This setting (in seconds) pushes the TTL 

renewal time for SLP services that the DAs SA registers to slightly more than 18 hours, 

thus reducing SLP overhead traffic. 

• “Set SLP Discovery Option = 6” This setting tells the DA to turn off multicast discovery 

and discover other DAs via the static configuration in its SLP.CFG file. It also allows the 

server to use DHCP to discover DAs if and when the customer decides to use DHCP. 

Also remember that in NW5SP3 and later the SLP modules have supported DA discovery 

via NDS, which is why we placed all of the DA objects in the same context. 

Next we will look at the A-Region SLP.CFG file. An example follows: 



; 


;the DA is out of multicast range (or multicast is not supported) and DHCP is 

;not being used to configure the DA. 





; 


;DA IPV4, 130.1.1.1 

; 








; 


; 

REGISTER TYPE “mgw.novell” to SCOPE “global,a1-region” 



REGISTER TYPE “ndap.novell” to SCOPE “global,a1-region” 

; 



; 

DA IPV4, a-region-da.state.us 

DA IPV4, b-region-da.state.us 

DA IPV4, c-region-da.state.us 

The first thing you will note is that the “ndap.novell” and “mgw.novell” services this servers SA 

registers are being redirected to both its regional scope and the global scope. These services were 

redirected to the ‘Global’ scope because it was determined that “ndap.novell” and ‘mgw.novell’ 

services should be globally available to increase the performance of locating migration agent 

servers and to facilitate NDS tree walking. Note that this is not a necessity it can however boost 

performance. The scopes are defined as a comma delimited list. The regional scope is in the list 

because once a service type is redirected it will no longer register with the scope(s) in its scope list 

unless it is specifically sent there. 

Next you will see that the DA has all of the DAs in its static list, including itself, as the first server 

in its list of DAs its SA will attempt to talk to. 

Finally, The DA object for the ‘A’ region DA is configured to serve the scopes: 

• A1-Region 

• A2-Region 

• Global 

You will note that A-Region is the only one with two regional scopes. This is due to the use of 

CMD in the environment, and the concentration of CMD servers in this particular hub site. 

The SLP Region ‘B’ DA configuration 

First we will cover the SLP set parameters that are set on the region ‘B’ DA. 


• “Set SLP Scope List = B-Region” This is necessary to tell the DA to register all of its 

own services with the ‘B’ Region scope. 









Next we will look at the B-Region SLP.CFG file. An example follows: 



; 










; 


;DA IPV4, 130.1.1.1 

; 








; 


; 

REGISTER TYPE “mgw.novell” to SCOPE “global,b-region” 

REGISTER TYPE “ndap.novell” to SCOPE “global,b-region” 

; 



; 














Finally, The DA object for the ‘B’ region DA is configured to serve the scopes: 

• B-Region 

• Global 

The SLP Region ‘C’ DA configuration 

First we will cover the SLP set parameters that are set on the region ‘C’ DA. 

The Set Parameters are as follows: 

• “Set SLP Scope List = C-Region” This is necessary to tell the DA to register all of its 

own services with the ‘C’ Region scope. 











Next we will look at the C-Region SLP.CFG file. An example follows: 



; 








; 


;DA IPV4, 130.1.1.1 

; 








; 


; 

REGISTER TYPE “mgw.novell” to SCOPE “global,c-region” 

REGISTER TYPE “ndap.novell” to SCOPE “global,c-region” 

; 



; 














Finally, The DA object for the ‘C’ region DA is configured to serve the scopes: 

• C-Region 

• Global 



NetWare 5.1 Server Agent (SA) Configuration 

First we will cover the SLP set parameters that are set on all non-DA NetWare 5.1 servers. Note 

that X-Region denotes the region the server resides in. Also note that the servers in A-Region are 

split between the two A-Region scopes. 


• “Set SLP Scope List = X-Region” This is necessary to tell the servers SA to register all of 

its services with the ‘X’ Region scope. 


renewal time for SLP services that the SA registers to slightly more than 18 hours, thus 

reducing SLP overhead traffic. 

• “Set SLP Discovery Option = 6” This setting tells the SA to turn off multicast discovery 

and discover DAs via the static configuration in its SLP.CFG file. It also allows the 


Next we will look at the non-DA SLP.CFG file. An example follows: 



; 








; 


;DA IPV4, 130.1.1.1 

; 








; 


; 

REGISTER TYPE “mgw.novell” to SCOPE “global,X-region” 

REGISTER TYPE “ndap.novell” to SCOPE “global,X-region” 

; 



; 

DA IPV4, X-region-da.state.us 









ecause once a service type is redirected it will no longer register with the scope(s) in its scope list 


Next you will see that the server has only one DA in its static list of servers its SA will attempt to 

talk to. Note that in a fault tolerant configuration there would be two DAs serving this scope. 

Phase II—Client Configuration 

The most difficult piece of setting up the SLP infrastructure really occurs in phase one. Once all of 

the SLP services on the network have been registered with the directory agents, the client 

workstations can query the directory agents and retrieve lists of available SLP services in their 

region of the network. The few clients who need to see services from other regions simply add 

those regions to their scope lists, and the DAs that serves them to their DA list. The only thing that 

is really required for the client workstations to make use of the SLP infrastructure is the 

installation of the latest version of the NetWare client. 

Configuring the Client Workstation 

As was explained in the section “Service Location Protocol,” there are a number of ways a client 

workstation can resolve services on the network. Because this customer requires local short name 

resolution and browsing of network resources, client workstations are going to need to utilize the 

SLP infrastructure. The other methods of service resolution can still be used for global name 

resolution, but SLP should be the primary method of local service resolution on the network. 

After the latest NetWare client has been installed on the client workstation, it will attempt to use 

the SLP infrastructure by default. This can be verified in the property pages of the Novell client. 

To see these property pages, go into the Network applet on Windows 95/98/NT. Enter the property 

pages of the Novell client. Once there, select the Protocol Preferences tab. On that property page, 

the various methods of name resolution are displayed, as shown in Figure D33. 



Figure D33. The Novell client property pages on Windows NT. 

For the client to use the SLP infrastructure, the box to the left of SLP must be checked. It will also 

make the client more efficient if unused name resolution mechanisms are unchecked. For instance, 

if DNS is not going to be used as a method of name resolution for NetWare client services, the 

box to the left of DNS should be unchecked. This will not affect normal DNS name resolution for 

general IP-based applications, such as Netscape. 

There are some other parameters that need to be configured for the clients to be able to use the 

SLP infrastructure that was set up in phase one. Because the customer is not using multicast as a 

discovery mechanism for directory agents, the directory agent addresses must be statically 

configured at the client. With this, the SLP Scope List for the clients must also be modified. This 

is accomplished through the Service Location tab, which is shown in Figure D34. 

In the Service Location tab, there are places to specify the Scope List and the Directory Agent 

List. The Directory Agent List can hold either the IP addresses of the directory agents on the 

network, or it can hold the fully qualified DNS names of the directory agents. The Scope List 

specifies to which scopes the client workstation belongs. As can be seen in Figure D34, the client 

workstation belongs to both the SLP_SCOPE1_US and SLP_SCOPE2_US scopes. The reason for 

this will be explained. The check in the Static box means the client is statically configured. 



Figure D34. The Service Location property page of the Windows NT Novell client. 

As was shown in the previous section, the servers available on the network have been split 

between four separate scopes. Since most of the clients belong to a single scope, they will only be 

able to see those servers that also belonged to that scope. This does not violate this customer’s 

functional requirements of the SLP infrastructure; however, making the client a member of more 

than one scope will allow the client to see all of the servers on the network that are in those 

scopes. 

The one drawback to this phase of the rollout is that the client workstations need to be manually 

configured because this customer cannot make use of DHCP or ZENworks to automate the rollout 

of the SLP information. However, if a tool is available that will allow the network administrators 

to make Windows registry modifications remotely, these modifications can be automated. Novell 

strongly urges the automation of as much of this configuration as possible within a given 

computing environment. 

Modeling Client Service Resolution Traffic 

While it is straightforward to configure the client workstations to use the SLP infrastructure, it is 

important to understand how the clients are actually using the infrastructure for service resolution. 

In the event there are performance problems, this insight will aid in the problem resolution. 

When a client first boots up, it will attempt to find its preferred tree or preferred server. To do this, 

it will issue an SLP service request looking for a list of services available on the network. Before 

actually sending out the SLP queries, the workstation will have determined its primary directory 



agents on the network. A primary directory agent will be specified for each of the workstation’s 

SLP scopes. 

In the case of the customer’s SLP infrastructure, the client workstation will look to its static list of 

available directory agents. It will attempt to activate each one of those directory agents 

simultaneously. The first directory agent to respond will be considered the “primary” directory 

agent. Subsequent replies will cause the workstation to mark the directory agent as “active”, but it 

will not submit queries to those directory agents unless the primary directory agent is unavailable 

or the query is to a scope that can only be serviced by another directory agent. 

This process is repeated for each of the workstation’s SLP scopes. Thus, each client workstation 

will have two primary directory agents. One primary directory agent will be designated for 

GLOBAL, and one primary directory agent will be designated for X-REGION. The primary 

directory agents for each scope may be the same or it may be different once fault tolerant DAs are 

setup. It all depends upon the network latency and quickness of response on the part of the 

directory agents on the network. 

When a query for SLP services is requested, such as the one to resolve the preferred tree or 

preferred server, the workstation will send a query to each of its primary directory agents. Thus, 

for each service resolution, the SLP user agent on the workstation really makes two separate 

queries to each scope, collates the results, and passes the information back to the requesting 

application (Figure D35). 

One important fact to glean from Figure D35 is that all SLP service requests must cross at least 

one WAN link to get to a directory agent. In the event the WAN link is not available, there will 

not be any global service resolution from SLP. As will be explained in the next section, clients 

will still be able to access local NetWare services that are reachable via multicast. But network 

browsing will not be available until the WAN link connection is restored. 

Main DA 

Primary DA 

GLOBAL 

Frame Relay 

Hub site Regional office 

(Regional) 

Fault Tolerance DA 

Primary DA 

X-REGION 





Desktop System 

Figure D35. Sample SLP service resolution process for the SLP infrastructure. 



In the event the primary directory agent is not available, the client will wait for a response based 

upon the Wait Before Giving Up On DA timer. By default, this value is five seconds. Once the 

client deems the DA unreachable, the client will attempt to contact the next active DA for that 

scope in its list. 

The client workstation will cache information it receives about services through SLP. The Cache 

SLP Replies timer on the workstation determines the amount of time this information is kept. By 

default, this value is one minute. The default values for these settings should be acceptable for the 

customer’s SLP infrastructure. 

WAN Link Failures and Client Fault Tolerance 

By looking at Figure D35, it is clear to see the SLP infrastructure is dependent upon the WAN 

links at this customer. The T-1 backbone connecting the hub sites is not redundant, and the WAN 

links connecting the regional offices back to the hub sites are not either. Additionally, the clients 

are dependent upon SLP to find their preferred server or preferred tree. How then will the clients 

be able to connect to their local file server in the event of a WAN link failure? 

There are two states that need to be addressed to completely answer this question, but the baseline 

is that the clients and local servers will fall back to the default method of SLP communication. 

They will begin to use multicast to find the services that are local to them. This means that 

multicast must be enabled on a per regional office basis. No multicast needs to cross the WAN 

links when they are active, but all machines need to participate in a local multicast infrastructure 

in the event the SLP infrastructure is unavailable due to a WAN link failure. This works for this 

customer because the vast majority of the satellite offices are single segment networks, and the 

hub sites host the DAs. 

How the client workstation will respond to this WAN link failure is dependent upon the state of 

the client. There are two scenarios, and they are listed below: 

• The client workstation is booted after the WAN link failure. 

• The client workstation was using the SLP infrastructure before the WAN link failure. 

In the event the client workstation is booted after the WAN link failure, the machine will come up 

as normal. It will attempt to activate the directory agents listed in its statically configured list; 

however, they will not be activated because the WAN link is down. After the activation process 

fails, the client workstation will use the normal multicast method of SLP communication, as 

described in the section “Default SLP Communications,” to find any services that are local to it. 

This is the final fail-over mechanism for SLP. 

In the event the client workstation was using the SLP infrastructure before the WAN link failure, 

the machine may not experience any difficulties unless the user attempts to access a network 

resource not on the local LAN. Only if an SLP query is sent from the client to the directory agents 

after the WAN link failure will there be a delay in services. The client workstation will attempt to 

contact its primary DA for each scope and fail after five seconds. If fault tolerant DAs have been 

set up, it will then attempt to contact the next active DA in the list, which will also fail after five 

seconds. After that, it will use the normal multicast method of SLP communication to find any 

services that are local to it. Because each client workstation has two configured directory agents in 

a fault tolerant configuration, the time out period should be ten seconds before reverting to 

multicast. 

Once the WAN link connectivity has been restored, the client workstations should eventually 

reactivate their directory agents. However, to quickly facilitate this reactivation, reboot the 

workstations. 



When to Use a Regional Approach to SLP 

This section discusses the circumstances when a regional approach to SLP infrastructure design 

might be appropriate. 

Scalability 

The regional approach to SLP provides the greatest level of scalability of any type of SLP design. 

Environmental Needs 

Every customer environment is unique and must be assessed individually. There are certain 

environmental factors in a customer’s network that would tend to lead you toward a regional SLP 

design approach. 

Large Enterprise Networks 

This is appropriate for very large networks where SAP filtering is in common use today and 

services are not generally globally available. 

Need to Minimize NDS Synchronization Across WANs 

WAN link constraints may require you to avoid replication of non-essential services globally. 

Need to Reduce the Size of Partitions and Replica Rings 

Large environments may have many DAs. A global approach to design may result in an inordinate 

number of objects per partition or replicas per partition and as a result a large amount of NDS 

synchronization traffic. In these instances a regional approach to SLP design would be in order. 



Appendix E—Double-Byte Compatibility 

Issues 

Asian Double-Byte Compatibility—Basic Issues 

Numerous sources describe the Asian double-byte compatibility issues. The following sections list 

a few very basic compatibility issues and what to watch for. 

Background 

Most Indo-European writing system characters can be rendered on computer systems using singlebyte 

code pages. Asian writing systems, however, contain many thousands of characters and need 

double-byte code pages to have enough combinations to render the characters. 

Problem Areas 

Monocasing or Uppercasing 

While English single-byte characters can generally be monocased (upper/lower cased) without 

causing problems, Asian double-byte characters must not be monocased or the rendered characters 

will change. 

Wildcard and Path Delimiter Characters 

Because some Asian double-byte characters use code points that are wildcard characters (“*” star, 

“.” dot, “?” question mark) and the path delimiter character (“\” back slash), NetWare must 

temporarily change these characters to different values to avoid confusing them with wildcard 

characters. Consequently these characters (2Ah, 2Eh, 3Fh, 5Ch) are “OR’ed” with 80h to produce 

augmented characters AAh, AEh, BFh, and 5Ch respectively. When these characters are stored in 

the Asian NetWare 3.x bindery, they are mapped down to 10h, 11h, 12h, and 13h and saved. The 

NetWare operating system knows to map up these characters when handing them to other 

programs. 

How augmented characters are handled and stored on the file system is different, depending upon 

the NetWare operating system version. For NetWare 3.1 these characters are stored mapped down 

in the file system; whereas, in NetWare 3.11+ these characters are stored mapped up. It is usually 

the responsibility of the NetWare client software to map up characters before handing them off for 

processing or display. 

When NetWare 4 was modified for Asia, the BINDCONV.EXE utility was created to map up 

special bindery characters in a 3.x server bindery before implementing a NETSYNC connection 

between a NetWare 4 server and the NetWare 3.x server. No utility exists, however, to correctly 

map up Asian file system characters. 

Caveats 

Programs that deal with double-byte characters must properly handle mapped down and 

augmented characters. Most NetWare product utilities have been developed to properly handle 

these characters, but not all third-party programs have. Test to ensure that programs properly 

handle, transfer, store, print, and correctly display double-byte characters. 



Special augmented characters are stored in the file system differently in various NetWare 

products. Programs must be able to recognize this and intelligently convert the special characters 

before processing them. 

Conclusion 

NetWare needed to be adapted to avoid confusing and changing Asian double-byte characters. The 

NetWare server operating system and most NetWare product utilities correctly handle “mappeddown” 

or “augmented” characters. Third-party developed programs and utilities may or may not 

properly handle special double-byte characters, depending on whether or not they properly use 

Novell APIs. Applications that blindly monocase characters will certainly ruin or change original 

double-byte characters. Test to ensure that original double-byte character values are preserved. 



Appendix F—NDS HealthCheck “Lite” 

Note: We strongly encourage you to recommend to your customers to purchase a full HealthCheck 

from Novell.. 

We have included a basic HealthCheck “Lite” here to help you to ensure that NDS is stable before 

extending the schema for Netware 5.1 At some point, the NDS HealthCheck BSO will also 

contain the “Lite” version. 

Basic NDS HealthCheck (HealthCheck Lite) 

The following items are the steps to take when doing a quick assessment of an NDS tree’s health 

before extending the schema. Ensure that you are using the latest NLMs when performing these 

tasks. 

Back up the DSREPAIR Log 

Check the NDS Version 

Confirm that the latest version of the DS NetWare Loadable Module (NLM) is running on the 

network servers. Use NDSMGR or DSREPAIR to verify and/or update DS versions. If using 

DSREPAIR, be sure to run it from a server containing a [Root] replica, preferably the Master. 

Check NDS Time Synchronization 

These are the steps to properly check Time Synchronization: 

1. Load DSREPAIR.NLM at server console. 

Do this from the server that contains the Master of [Root]. 

2. From the Available Options menu, select the Time Synchronization option. 

3. Verify that YES is displayed in the TIME IS field in the SYNC column. 

This can also be accomplished using DSDIAG.NLM: 

1. From the Check NDS Versions report, press F8 for Display Options. 

2. Enable Additional Info. Timesync Check is an option available from the menu. 

Check Partition Continuity 

This option is available in DSREPAIR. At a minimum, you want to do this from the server 

holding the Master of [Root]. 

Check “Servers Known to this Database” 

This option is available in DSREPAIR. You want to ensure the servers are in an “Up” state. At a 

minimum, you want to do this from the server holding the Master of [Root]. 



Appendix G—NetWare 5.1 Rapid 

Deployment and Standardization 

Strategies 

Overview 

One of the primary ways to reduce time and costs for deploying NetWare 5.1 is to develop a 

custom installation solution for the customer. This allows you to tailor the install/upgrade process 

to the customer’s individual needs. It attempts to eliminate questions and decision-making 

requirements during the install/upgrade. This approach also minimizes training and skill 

requirements for the implementation teams. In addition the final product is consistent and 

reproducible. 

Available Options 

A range of options exists in development of a rapid deployment and standardization strategy. The 

level of customization should be based on the customer goals and requirements. The following list 

outlines the various options: 

• NetWare Accelerated Upgrade 

• NetWare 5.1 Installation with a Response File 

• Installations Scripts for NetWare 5.1 

• Custom CD image with patches and drivers integrated 

• RexxWare Migration Tool Kit 2.0+ 

• Custom NCF/Config file generation 

The above options are covered in detail in the sections below. 

NetWare Accelerated Upgrade 

You can run NetWare Accelerated Upgrade from a Windows client workstation, so that you don't 

need to be physically present at the server console. Although NetWare Accelerated Upgrade is 

quicker than the standard installation process, it does not install additional network products, 

licensing services, or license certificates. 

For more information: 

• http://www.novell.com/documentation/lg/nw51/docui/index.html#../othr_enu/data/ h9v4j5 

ki .html 

The utility itself is located at the root of the NetWare 5.1 Operating System CD (ACCUPG.EXE). 

NetWare 5.1 Installation with a Response File 

Installing the NetWare 5.1 operating system software can be easier and more flexible when you 

use a response file. When used with the graphical server installation, a response file lets you: 

• Set and display specific defaults 

• Bypass entire sections of the installation 

• Automate the entire server installation process 



A response file is a text file containing sections and keys (similar to a Windows .INI file). You can 

create a response file using any ASCII text editor. If you use a response file, the NetWare 5.1 

server installation reads the installation parameters directly from the response file, replacing the 

default installation values with response file values. 

This process (for NetWare 5) is documented in two AppNotes published in December of 1998 and 

February of 1999 (see the AppNotes listing at the beginning of this consultant guide). 


• http://www.novell.com/documentation/lg/nw51/docui/index.html#../othr_enu/data/ h9v4j5 

ki .html 

The following is a sample response file that can be used as a starting point for automating the 

installation process. The specific script elements can be understood from the two AppNotes 

mentioned above. The following script was written for NetWare 5 and may need to be slightly 

modified for NetWare 5.1: 

[NWI:Product Information] 

Major Version=NetWare 5 

Minor Version=00 

[NWI:Language] 

Server Language=4 

Prompt=FALSE 

[NOVELL:NOVELL_ROOT:1.0.0] 

OverwriteNewerVersion=Yes 

OverwriteOlderVersion=Yes 

ShowWelcomeScreen=No 

LogLevel=DEBUG_DETAIL 

[Selected Nodes] 

prompt=FALSE 

Novell:NetWare5:1.0.0=Novell:NetWare5OS:5.0.0,Novell:Products:1.0.0 

Novell:NetWare5OS:5.0.0=Novell:Disk 

Carver:1.0.0,Novell:Protocols:1.0.0,Novell:DS_Install:1.0.0,Novell:LicensePrompt:1 

.0.0,Novell:NW:1.0.0,Novell:NDPS Server Files:1.0.0 

Novell:NW:1.0.0=Novell:Startup:1.0.0,Novell:SYS:1.0.0,Novell:DriverFiles:1.0.0 

Novell:Startup:1.0.0=Novell:StartupDirectory:1.0.0 

Novell:SYS:1.0.0=Novell:SYSDirectory:1.0.0,Novell:ETCDirectory:1.0.0,Novell:PROFIN 

ST_NODE:1.0.0 

Novell:DriverFiles:1.0.0=Novell:LANFiles:1.0.0,Novell:SBDFiles:1.0.0 

Novell:NDPS Server Files:1.0.0=Novell:NDPS System:1.0.0,Novell:NDPS Public:1.0.0 

Novell:Products:1.0.0=Novell:NICIInstall:1.0.0 

Novell:NICIInstall:1.0.0=Novell:NICIModule:1.0.0 

[NWI:Install Options] 

Upgrade=FALSE 

Prompt=FALSE 

Startup Directory=C:\NWSERVER 

[NWI:Install Script] 

Close Script=sys:/system/postgui.ips 

[NWI:Locale] 



Uses Vgadisp=false 

Code Page=850 

Country Code=001 

Keyboard=United States 

Replace DOS Config Files=TRUE 

Prompt=FALSE 

[NWI:Mouse and Video] 

Mouse=PS/2 

Use Super Vga=FALSE 

Prompt=FALSE 

[NWI:Hardware] 

CD-ROM Driver=NetWare 

PSM Detection=TRUE 

Storage Detection=TRUE 

Network Detection=TRUE 

Prompt=FALSE 

[NWI:NW VOLUME] 

Prompt=FALSE 

SYS VOLUME SIZE=2000 

SYS PARTITION HOTFIX SIZE=4.0 

ALLOW VOLUME PROPERTIES=TRUE 

BLOCK SIZE=64 

COMPRESSION=TRUE 

SUBALLOCATION=TRUE 

DATA MIGRATION=FALSE 

GUI Prompt=FALSE 

[NWI:File Server] 

Prompt=false 

Servername=SRV01 

Server Id Number=OAOAC70A 

[NWI:PROTOCOLS] 

Prompt=false 

[NWI:TCPIP] 

Logical Name 1=NIC1_IP 

IP Address 1=10.10.199.10 

Subnet Mask 1=255.255.0.0 

Gateway 1=10.10.0.1 

[NWI:IPX] 

Logical Name 1=NIC1_IPX 

IPX Address 1=0AOA0000 

[NWI:Time Zone] 

Use Daylight Saving Time=true 

Time Zone=EST 

Prompt=false 

[NWI:NDS] 



Schema 

Extensions=sys:/system/schema/NLS.SCH,sys:/system/schema/AUDITING.SCH,sys:/system/ 

schema/NWADMIN.SCH,sys:/system/schema/NRD.SCH,sys:system/schema/SAS.SCH,sys:/syste 

m/schema/NDSPKI.SCH,sys:/system/schema/MASV.SCH,sys:/system/schema/SLP.SCH,sys:sys 

tem/schema/LDAP.SCH,sys:system/schema/LDAPUPDT.SCH,sys:system/schema/CATALOG.SCH,s 

ys:system/schema/WANMAN.SCH,sys:system/schema/SMS.SCH,sys:system/schema/NDPS100.SC 

H,sys:system/schema/NDPS200.SCH,sys:system/schema/SVC.SCH 

Schema Extensions Pre DS=sys:/system/schema/NDS500.SCH,sys:/system/schema/NLS.SCH 

Admin Language=4 

Tree Name=ACMETREE 

Server Context=SALES.ACME 

New Tree=FALSE 

Admin Login Name=ADMIN 

Admin Context=ACME 

Admin Password=ADMIN 

Display Summary=false 

Add Replica=FALSE 

Prompt=false 

[NWI:License] 

Display License Agreement=FALSE 

Prompt=FALSE 

License File=d:\nwinst\mla\mla.nlf 

[NWI:Time Synchronization] 

Default Time Server Type=Secondary 

[Initialization] 

SummaryPrompt=False 

[Novell:NOVELL_ROOT:1.0.0] 

closeScreen=SilentCloseScreen 

Reboot=True 

[NWI:Misc] 

Relogin Password=ADMIN 

Installations Scripts for NetWare 5.1 

NetWare Installation Scripts (formerly known as CDWare Script Installation) let you: 

• Alter or extend the NetWare 5.1 installation process. 

• Install additional products or services on a NetWare 5.1 server after the operating system 

has been installed. Third-party products can be installed from a custom CDWare script 

that is set to run post install using the Close Script parameter in the response file. This 

script can call the third-party install scripts, or can incorporate them into one master 

script. 


• 

http://www.novell.com/documentation/lg/nw51/docui/index.html#../othr_enu/data/h9v4j5 

ki.html 



Custom CD Image 

A custom CD image can be developed which integrates the latest support packs and patches as 

well as the latest drivers for the customer’s hardware. This image will speed up the install/upgrade 

process as well as ensure a standard file set across all servers. It is also recommended that the 

image include the customer’s license and NICI foundation key for distribution to all servers. 

RexxWare Migration Tool Kit 2.0+ 

Available at: http://www.simware.com/products . There is no charge to Novell customers for this 

product. 

REXXWARE offers tools for performing reliable, fast migration of bindery and data to 

NetWare 5.0. (check their web site for support with NetWare 5.1). A Java-based GUI allows the 

migration to be managed from a workstation, while the data and processing are completed on the 

server. 

As with the Novell upgrade processes, REXXWARE allows for in-place upgrade, across-the-wire 

upgrade, and across-the-wire manual upgrade. The benefit is that all of the processing is handled 

by the file server, which leverages the server processing power. There are also utilities to design 

and report update information prior to the upgrade. 

REXXWARE Upgrade 


Platform is server-based so file copies are more 

quickly performed. 

Servers/volumes can be individually mapped to 

appropriate NDS context. 

Allows for features such as undo last NDS update 

and checkpoint restart after equipment failure that 

ensure the migration will run with little risk. 

Selective migration allows extensive search masks 

on attributes to create subsets of objects before 

editing, moving, etc. 

Selective file migration allows selection of files 

(example: SYSTEM directory) not to be migrated. 

Objects can be edited singly or multiple search 

masks allow edits to be applied to entire subsets of 

object. 

User and system login scripts are migrated and 

reflect the new server and volume names. 

Passwords can be randomly generated for new 

NetWare 5.1 users or have no password but force 

the user to define one at initial logon. 

Data import is performed via batch mode import of 

new fields and attributes from external sources. 

NDS can be modeled off-line and “what if’ scenarios 

tested. 

You can do “trial run” on moving files with zerolength 

files to verify directory structure. 

You can generate customized or predefined reports 

on 3.x databases, including complete dumps of all 

objects, all fields, all attributes, etc. 

Will migrate passwords, but only if all of the file 

servers in the enterprise are up and running. Expect 

failure of the process and have a contingency plan. 



Uses the REXX scripting language. You have to have expertise in REXX. 

Custom NCF File Generation 

To encourage and enforce standards in NetWare 5.1 installations and upgrades, custom NCF and 

configuration files can be generated by utilities called in the post-install script. A variety of 

methods can be used and will be outlined in the scripting options section. Below is a sample Java 

class that will create a standard autoexec.ncf. 

// BuildAutoexec.java 

package com.novell.consulting.nwinst; 

import java.util.*; 

import java.io.*; 

import com.novell.application.install.ResponseFile; 

import com.novell.consulting.nwinst.AutoexecNcfFile; 

//---------------------------------------------------------------------------- 

//|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| 

//--------------------------------------------------------------------------class 

BuildAutoexec 

{ 

static private PrintWriter _autoexecFile; 

static private ResponseFile _responseFile; 

public static void main(String argv[]) 

{ 

if(argv.length < 2) 

{ 

System.out.println(““); 

System.out.println(“Error: incorrect argument count”); 


System.out.println(“Usage:”); 

System.out.println(“ java com.novell.consulting.nwinst.BuildAutoexec 

responsefile autoexecfile”); 


return; 

} 

//////////////////////////////////////////////////////////////////////// 

// Open the response file which is in ini format 

_responseFile = new ResponseFile(argv[0]); 

try 

{ 

_responseFile.initialize(false, false); 

} 

catch (IOException e) 

{ 

// FileNotFoundException 



System.out.println (“IOException: “ + e); 

return; 

} // catch 

catch(IllegalArgumentException e) 

{ 

System.out.println (“IllegalArgumentException: “ + e); 

return; 

} 

//////////////////////////////////////////////////////////////////////// 

// Open the output file 

try 

{ 

_autoexecFile = new PrintWriter (new FileOutputStream(argv[1])); 

} // try 

catch(IOException e) 

{ 

System.out.println (“BuildAutoexec IOException: “ + e); 

} // catch 

//////////////////////////////////////////////////////////////////////// 

// Build the Time Zone Section 

// Todo: 

// Need to figure out how to pull this from response file 

AutoexecNcfFile oldAutoexecNcfFile = new 

AutoexecNcfFile(“sys:\\system\\autoexec.pj”); 

String sTimeInfoString = oldAutoexecNcfFile.GetTimeHeader(); 

_autoexecFile.println (“;--------------------------”); 

_autoexecFile.println (“;- Set Server Time Zone -”); 


_autoexecFile.println (sTimeInfoString); 

//_autoexecFile.println (“SET Time Zone = EST5EDT”); 

//_autoexecFile.println (“SET Daylight Savings Time Offset = 1:00:00”); 

//_autoexecFile.println (“SET Start Of Daylight Savings Time = (APRIL SUNDAY 

FIRST 2:00:00 AM)”); 

//_autoexecFile.println (“SET End Of Daylight Savings Time = (OCTOBER SUNDAY 

LAST 2:00:00 AM)”); 

_autoexecFile.println (““); 

//////////////////////////////////////////////////////////////////////// 

// Build the Bindery Services Section 

String fileServerCx = _responseFile.getString(“NWI:NDS”, “Server Context”); 

_autoexecFile.println (“;----------------------”); 

_autoexecFile.println (“;- Bindery Services -”); 



_autoexecFile.println (“;----------------------”); 

_autoexecFile.println (“Set Bindery Context = “ + fileServerCx); 


//////////////////////////////////////////////////////////////////////// 

// Build the File Server Information Section 

String fileServerName = _responseFile.getString(“NWI:File Server”, 

“Servername”); 

String ServerID = _responseFile.getString(“NWI:File Server”, “Server Id 

Number”); 

”); 

”); 

”); 

_autoexecFile.println (“;-------------------------------------------------- 

_autoexecFile.println (“;- Name Server & Assign Internal Network Number - 

_autoexecFile.println (“;-------------------------------------------------- 

_autoexecFile.println (“FILE SERVER NAME “ + fileServerName); 

_autoexecFile.println (“SERVERID “ + ServerID); 


//////////////////////////////////////////////////////////////////////// 

// Build the Console Logging Section 

_autoexecFile.println (“;-------------------------------”); 

_autoexecFile.println (“;- Log Boot/AUTOEXEC Process -”); 


_autoexecFile.println (“LOAD CONLOG Entire=Yes”); 


_autoexecFile.println (“;----------------------------------”); 

_autoexecFile.println (“;- Tune Server (Set Parameters) -”); 

_autoexecFile.println (“;----------------------------------”); 

_autoexecFile.println (“Set NCP Protocol Preferences = TCP UDP IPX”); 

_autoexecFile.println (“Set Immediate Purge of Deleted Files = On”); 


_autoexecFile.println (“;-----------------------”); 

_autoexecFile.println (“;- Mount All Volumes -”); 

_autoexecFile.println (“;-----------------------”); 

_autoexecFile.println (“MOUNT ALL”); 


String ipxFrameType = _responseFile.getString(“NWInst:Custom”, 

“IPXFrameType”); 

String ipFrameType = _responseFile.getString(“NWInst:Custom”, 

“IPFrameType”); 

int ipFrameTypeLineNumber = 0; 

int ipxFrameTypeLineNumber = 0; 

int i = 1; 

String tempFrameType = ““; 



while(i < 5) 

{ 

tempFrameType = _responseFile.getString(“NWI:Network Adapter 1”, “Frame 

Type “ + Integer.toString(i) ); 

System.out.println(“Checking Frame type”); 

if(tempFrameType.equalsIgnoreCase(ipxFrameType)) 

{ 

ipxFrameTypeLineNumber = i; 

System.out.println(“Found IpxFrameType”); 

} 

if(tempFrameType.equalsIgnoreCase(ipFrameType)) 

{ 

ipFrameTypeLineNumber = i; 

System.out.println(“Found IpFrameType”); 

} 

i++; 

} 

//////////////////////////////////////////////////////////////////////// 

// Build the IP Protocol Section 

String ipLoadLineTemp = _responseFile.getString(“NWI:Network Adapter 1”, 

“Load Line “ + Integer.toString(ipFrameTypeLineNumber)); 

//String ipLoadLine = ipLoadLineTemp.substring(0, 

ipLoadLineTemp.lastIndexOf(“NAME=“)); 

//ipLoadLine += “NAME=NIC1_IP”; 

String ipLoadLine = ipLoadLineTemp; 

String ipBoardName = _responseFile.getString(“NWI:Network Adapter 1”, 

“Logical Name “ + Integer.toString(ipFrameTypeLineNumber)); 

String ipAddress = _responseFile.getString(“NWI:TCPIP”, “IP Address 1”); 

String ipMask = _responseFile.getString(“NWI:TCPIP”, “Subnet Mask 1”); 

String ipGate = _responseFile.getString(“NWI:TCPIP”, “Gateway 1”); 

_autoexecFile.println (“;------------------------------------------------- 

”); 

_autoexecFile.println (“; IP Protocol Section”); 


”); 

_autoexecFile.println (“LOAD TCPIP”); 

_autoexecFile.println (ipLoadLine); 

_autoexecFile.println (“BIND IP “ + ipBoardName + “ addr=“ + ipAddress + “ 

mask=“ + ipMask + “ gate=“ + ipGate); 


//////////////////////////////////////////////////////////////////////// 

// Build the IPX Protocol Section 

String ipxLoadLineTemp = _responseFile.getString(“NWI:Network Adapter 1”, 

“Load Line “ + Integer.toString(ipxFrameTypeLineNumber)); 



String ipxLoadLine = ipxLoadLineTemp.substring(0, 

ipxLoadLineTemp.lastIndexOf(“NAME=“)); 

//ipxLoadLine += “NAME=NIC1_IPX”; 

String ipxLoadLine = ipxLoadLineTemp; 

String ipxBoardName = _responseFile.getString(“NWI:Network Adapter 1”, 

“Logical Name “ + Integer.toString(ipxFrameTypeLineNumber)); 

”); 

”); 

String ipxNet = _responseFile.getString(“NWI:IPX”, “IPX Address 1”); 


_autoexecFile.println (“; IPX Protocol Section”); 


_autoexecFile.println (“LOAD IPXRTR”); 

_autoexecFile.println (ipxLoadLine); 

_autoexecFile.println (“BIND IPX “ + ipxBoardName + “ NET=“ + ipxNet); 

_autoexecFile.println (“LOAD IPXRTRNM”); 


//////////////////////////////////////////////////////////////////////// 

// Build the Final Section 

_autoexecFile.println (“;---------------------------”); 

_autoexecFile.println (“;- Add Java To Search Path -”); 

_autoexecFile.println (“;---------------------------”); 

_autoexecFile.println (“SEARCH ADD SYS:\\JAVA\\BIN”); 

_autoexecFile.println (“SEARCH ADD SYS:\\JAVA\\NWGFX”); 


_autoexecFile.println (“;------------------”); 

_autoexecFile.println (“;- Launch The GUI -”); 

_autoexecFile.println (“;------------------”); 

_autoexecFile.println (“; STARTX.NCF”); 


_autoexecFile.println (“;---------------------------------”); 

_autoexecFile.println (“;- Load Remote Console Support -”); 

_autoexecFile.println (“;---------------------------------”); 

_autoexecFile.println (“LOAD SPXS”); 

String rconsolePass = _responseFile.getString(“NWI:NDS”, “Admin Password”); 

_autoexecFile.println (“LOAD RCONAG6 “+ rconsolePass + “ 2034 16800”); 


_autoexecFile.println (“;---------------------”); 

_autoexecFile.println (“;- Load ManageWise -”); 

_autoexecFile.println (“;---------------------”); 

_autoexecFile.println (“; sys:/system/nma/nma5.ncf”); 


_autoexecFile.println (“;-----------------”); 

_autoexecFile.println (“;- Load Backup -”); 

_autoexecFile.println (“;-----------------”); 





} 

_autoexecFile.println (“;- Load Console Monitor -”); 


_autoexecFile.println (“LOAD MONITOR”); 



_autoexecFile.println (“;- Stop Logging Boot Process -”); 


_autoexecFile.println (“UNLOAD CONLOG”); 

//_autoexecFile.flush(); 

_autoexecFile.close(); 

} 

Scripting Options 

As you can see from the above, a variety of mechanisms are available to customize and script 

additions to the install process. The following lists the more common options available in order of 

complexity: 

Mechanism Discussion 

NCF Files NCF files can be used to launch NLMs and ILS scripts. They can be 

used for basic customization. 

Installation Scripts (formerly 

known as CDWare Scripts) 

The installation scripting language is the language used by most all 

Novell server based installs. It is a powerful scripting language and is 

documented in a file which can be located on http://support.novell.com 

by searching the knowledgebase for the word CDWare. 

Java Classes Once the Java support files have been copied to the server Java 

applications can be used to automate many processes. An example 

was shown above in the section “Custom NCF File Generation.” 

Custom NLMs Custom NLMs can be developed that accomplish certain operations at 

the API level. This kind of development requires a compiler capable of 

compiling NLMs as well as the Novell SDK files which are freely 

available from http://developer.novell.com. 

Conclusion 

A variety of options are available for rapid, consistent and minimum effort NetWare 5.1 

installations and upgrades. The choices made should reflect the size and standardization 

requirements of the environment. 



Appendix H—SAP Types 

This table lists SAP types (in hex) with a description of what it is used for. This information came 

from 

http://support.novell.com : 

• TID 2945808 = SAPs 0001 - 043F 

• TID 2945810 = SAPs 0441 - FFFF 

Type Description 

0001 User Novell - Provo Corp HQ 

0002 User Group Novell – Provo Corp HQ 

0003 NetWare Print Queue or Print Group 

Novell - Provo Corp HQ 

0004 NetWare File Server (can be emulated by 

NT Server running FPNW or Win95 with 

File and Print Share for NW) Novell - Provo 

Corp HQ 

0005 Job Server Novell - Provo Corp HQ 

0006 Gateway Novell - Provo Corp HQ 

0007 Print Server or Silent Print Server Novell - 

Provo Corp HQ 

0008 Archive Queue Novell - Provo Corp HQ 

0009 Archive Server Novell - Provo Corp HQ 

000A Job Queue Novell - Provo Corp HQ 

000B Administration Novell - Provo Corp HQ 

0017 Diagnostics None 

0020 NetBios None 

0021 SNA Gateway National Advanced Systems 

0022 Sperry Corp Computer Systems 

0023 NACS Async Gateway KTA 

0024 Remote Bridge Server Novell - Provo Corp 

HQ 

0025 Data Language Corp 

0026 Bridge Server or Asynchronous Bridge 

Server Computer Logics 

0027 TCP/IP Gateway Santa Clara Systems 

0028 Point-point Eicon Technology 

0029 Multi-point X.25 Gateway Eicon 

Technology 

002A Chi Corp 

002B Compass Computing 

002C PC Chalkboard Intel - Hillsboro 

002D Time Synchronization VAP Novell - Provo 

Corp HQ 

002E Target Service Agent (ARCserve 

5.0/Palindrome Backup Directory 4.x) 


Novell Provo Corp HQ 

0044 0 Connection Station Service Type 

Corollary Inc 

0047 Advertising Print Server Novell - Provo 

Corp HQ 

0048 TCP/IP Gateway Micom – InterLAN 

0049 Business Records Corp 

004A NetBlazer Modems Paradata Computer 

Networks 

004B Btrieve Server - VAP 5.0 Pervasive 

Software Inc 

004C NetWare SQL VAP Pervasive Software Inc 

004D Xtree-Net Central Point Software 

004E ICL Gateway VAP Computer 

Communication Consult 

004F Database Server Emerald Bay 

0050 Btrieve VAP 4.11 Novell - Provo Corp HQ 

0051 LAN Services 

0052 QuickLink ICM 

0053 MAC Project Novell - Provo Corp HQ 

0054 Value Added File System Novell - Provo 

Corp HQ 

0055 Term Emulator Systems Analysis Inc 

0056 Stocknet Broker SAP Type Novell - Provo 

Corp HQ 

0057 Stocknet Exchanger SAP Type Novell - 

Provo Corp HQ 

0058 Multi-point X.25 Router Eicon Technology 

0059 LAN Services 

005A Business Records Corp 

005B Business Records Corp 

005C Business Records Corp 

005D Business Records Corp 

005E Business Records Corp 

005F Business Records Corp 

0060 Stocknet Broker - Static Novell - Provo 




Corp HQ 

0061 Stocknet Queue Type Novell - Provo Corp 

HQ 

0062 Stocknet Player Type Novell - Provo Corp 

HQ 

0063 Interactive Financial Solution 

0064 ARCserve Interactive Financial Solution 


0066 ARCserve 3.0 Interactive Financial 

Solution 




006A Interactive Financial Solution 

006B Interactive Financial Solution 

006C Interactive Financial Solution 

006D Stocknet Exchange - Static Novell - Provo 

Corp HQ 

006E NACS NetPro Inc 

006F Rabbit Software Corp 

0070 MIC SNA DFV Server Mikado 

0071 Tape Drive Server Digi-Data Corp 

0072 WANcopy Utility Novell - Provo Corp HQ 

0073 Novell - Provo Corp HQ 


0075 NetWare Btrieve Novell - Provo Corp HQ 

0076 NetWare SQL Novell - Provo Corp HQ 




007A TES - NetWare VMS Novell - Provo Corp 

HQ 

007B Mergent International 


007D Interactive Financial Solution 

007E Interactive Financial Solution 

007F Interactive Financial Solution 












008A Interactive Financial Solution 

008B Interactive Financial Solution 


008D Mail Server McGill University 

008E Rational Data Systems 

008F Queue Types Tate Associates Inc 

0090 TNET X.21 IDA Bridge British Telecom 

0091 TNET X.21 Bridge British Telecom 

0092 Tape Backup Server Emerald Systems 

Corp 

0093 Watcom 

0094 Sila Com Software Novell - Provo Corp HQ 

0095 VMS Router Control Interconnections 

0096 Micro DataBase Systems 

0097 Dart College Hill Systems 

0098 NetWare Access Server Novell - Provo 

Corp HQ 

0099 Network Courier Microsoft Workgroup 

Canada 

009A Named Pipes Server Novell - Provo Corp 

HQ 

009B Job Server DIS 

009C Raylynn Knight 

009D CQ3270 LAN CQ Computer 

Communications 

009E Unix - Portable Group/Portable NetWare 


009F Progress Database Progress Software 

Corp 

00A0 Gupta SQL Base Server Gupta 

Technologies 

00A1 Powerchute-VAP/NLM Server Power 

Supply American Power Conversion 

00A2 Auditor Package Blue Lance Network Info 

Sys 

00A3 Security Blue Lance Network Info Sys 

00A4 “Corel Driver Product under Novell 386 




Corel Systems Corp, Optical Div” 

00A5 Archive Server Gigatrend Inc 

00A6 Menu Program R&S Data Systems 

00A7 386 NLM Unisys - Camarillo 

00A8 LAN 1 Router Atlanta Technologies 

00A9 “Object Type Corel Systems Corp, Optical 

Div” 

00AA “Object Type Corel Systems Corp, Optical 

Div” 

00AC IDA Status Utility Compaq Computer Corp 

00AD LANport Virtual Extension of Ports 

Microtest Inc 

0100 Peer Logic 

0101 R21PX Crosstalk 

0102 Inventory Manager Intel - Hillsboro 

0103 SequelNet Oracle Corp 

0104 VAP Pillsbury Company 

0105 Gateway to Unisys Marshfield Clinic 

0106 Gateways to Unisys Marshfield Clinic 

0107 RSPX Server /386 NetWare Novell - Provo 

Corp HQ 

0108 NetWare for VM & MVS Phaser Systems 

Inc 

0109 NetWare for VM & MVS Phaser Systems 

Inc 

010A NetWare for VM & MVS Phaser Systems 

Inc 

010B NetWare for VM & MVS Phaser Systems 

Inc 

010C Net 3270 McGill University Computing CT 

010D Image Server File Net 

010E RTK Owl Micro Systems 

010F Novell SNA Gateway Novell - Provo Corp 

HQ 

0110 Artefact Network Support 

0111 Test Server Novell - Austin 

0112 Print Server Hewlett Packard - Boise 

0113 Communication Server Novell - Provo 

Corp HQ 

0114 CSA MUX /Communication Server Novell - 

Provo Corp HQ 

0115 CSA LCA /Communication Server Novell - 

Provo Corp HQ 

0116 CSA CM /Communication Server Novell - 

Provo Corp HQ 


0117 CSA SMA /Communication Server Novell - 

Provo Corp HQ 

0118 CSA DBA /Communication Server Novell - 

Provo Corp HQ 

0119 CSA NMA /Communication Server Novell - 

Provo Corp HQ 

011A CSA SSA /Communication Server Novell - 

Provo Corp HQ 

011B CSA Status /Communication Server Novell 

- Provo Corp HQ 

011C SAA Data Link Agent Novell - Provo Corp 

HQ 

011D Communication Server Novell - Provo 

Corp HQ 

011E CSA APPC /Communication Server Novell 


011F Communication Server Novell - Provo 

Corp HQ 


Corp HQ 


Corp HQ 


Corp HQ 


Corp HQ 


Corp HQ 


Corp HQ 

0126 SNA Test /Communication Server Novell - 

Provo Corp HQ 


Corp HQ 


Corp HQ 


Corp HQ 

012A CSA Trace /Communication Server Novell 


012B Super SNA Agent /NetWare for SAA 


012C Communication Server Novell - Provo 

Corp HQ 

012D Communications Server Novell - Provo 

Corp HQ 

012E Communications Server/IKARUS Virus 

Scan Utility Novell - Provo Corp HQ 

012F Communications Server Novell - Provo 

Corp HQ 




0130 Communications 

Executive/Communications Server Novell - 

Provo Corp HQ 

0131 Image Server Wang Laboratories Inc 

0132 BT X.25 British Telecom 

0133 NNS Domain /Elmer Project Novell - Provo 

Corp HQ 

0134 Elmer Project Novell - Provo Corp HQ 

0135 NNS Profile /Elmer Project Novell - Provo 

Corp HQ 


0137 NNS Queue /Elmer Project Novell - Provo 

Corp HQ 



013A Elmer Project Novell - Provo Corp HQ 

013B Elmer Project Novell - Provo Corp HQ 

013C Elmer Project Novell - Provo Corp HQ 

013D Securities Trading & Technology 

013E Securities Trading & Technology 

013F Network Designers Ltd 

0140 Network Management System Accunetics 

0141 Software GMBH Lufthansa Information 

Service 

0142 Aladdin Knowledge Systems 

0143 CDROM Online Computer Systems 

0144 NetWise Inc 

0145 Communication Processor Evergreen 

Systems 

0146 XDB Server Database XDB Systems Inc 

0147 Piggyback Login Net_inc Micro 

Enhancement Inc 

0148 Network Software Associates 

0149 Advertising Remote Server Artefact 

Network Support 

014A ID 5001 Weather Station Zenith Data 

Systems 

014B Novell - Provo Corp HQ 

014C Netframe NetWare 386 Net Frame 

Systems 

014D Netframe NetWare 386 Net Frame 

Systems 

014E Netframe NetWare 386 Net Frame 

Systems 


014F Netframe NetWare 386 Net Frame 

Systems 

0150 Maxiback - VAP Sysgen 

0151 DCS System Server Computer Concepts 

Corporation 

0152 DCA IPX Communication Product/ 

IRMALAN Gtwy DCA 

0153 DCA IPX Communication Product DCA 

0154 Forms Capability Rochester Telephone 

Corp 


Corp 


Corp 


Corp 


Corp 


Corp 

015A Forms Capability Rochester Telephone 

Corp 

015B Forms Capability Rochester Telephone 

Corp 

015C Network Computing Inc - NCI 

015D Network Computing Inc - NCI 

015E Network Computing Inc - NCI 

015F Network Computing Inc - NCI 

0160 Network Computing Inc - NCI 

0161 Advertising Remote Server Artefact 

Network Support 

0162 System 9 HBF Group 




0166 NW Management Novell - Provo Corp HQ 

0167 InstantCom Communications Server 

Instant Information 

0168 PickIt (Comm Server) Intel PCED - 

Hillsboro 

0169 Peer Logic 

016A Open Image for NetWare Wang 

Laboratories Inc 

016B Open Image for NetWare Wang 


016C Open Image for NetWare Wang 





016D Open Image for NetWare Wang 


016E Open Image for NetWare Wang 


016F Luminar Optical Server Corel Systems 

Corp 

0170 TXD Thomas Conrad Corp 

0171 LANFax Redirector Alcom Inc 

0172 File Share Compaq Computer Corp 


0174 Compaq SNMP Agent /File Share Compaq 

Computer Corp 



0177 LANWare Horizon Technology Inc 



017A LANWare Horizon Technology Inc 

017B LANWare Horizon Technology Inc 

017C LANWare Horizon Technology Inc 

017D LANWare Horizon Technology Inc 

017E LANWare Horizon Technology Inc 

017F LANWare Horizon Technology Inc 

0180 NMI LAN Services Horizon Technology Inc 

0188 SYSM/LAN2 H&W Computer Systems 

0189 Xtree Server Central Point Software 

018E PC Metro Crystal Point 

018F PC Metro Crystal Point 

0190 Service Point Interpoint Software 

0191 Service Point Interpoint Software 

0192 Netway 2000 Tri Data Systems 

0193 Netway SNA Tri Data Systems 

0194 Maxway 500 Tri Data Systems 

0195 TCP/IP Gateway Computer Vision 

Services 

0196 Integrated Technologies Inc 

0197 Share Master Storage Dimensions 

0198 Zenith Electronics Corp 

0199 Zenith Electronics Corp 

019A Zenith Electronics Corp 


019B APT Net Remote Automated Programming 

Tech 

019C APT Net Remote Automated Programming 

Tech 

019D APT Net Remote Automated Programming 

Tech 

019E APT Net Remote Automated Programming 

Tech 

019F Mailslots IBM - Franklin Lakes 

01A0 Terminal Gateway for Unisys Mainframe 

Upstanding Systems 

01A1 DB Server Lodgistix Inc 

01A2 Spare Lodgistix Inc 

01A3 “Gateway, Composite Page, & Etc Servers 

Teknos Systems” 













01AA “Gateway, Composite Page, & Etc Servers 


01AB “Gateway, Composite Page, & Etc Servers 


01AC “Gateway, Composite Page, & Etc Servers 


01AD Menu Program R&S Data Systems 

01AE Menu Program R&S Data Systems 

01B0 Object Type for GARP Server Net 

Research Pty Ltd 

01B1 “Licensing Restrictions/BindView LAN 

Support Group, Network Res” 

01B2 “Licensing Restrictions/Bindery Type LAN 

Support Group, Network Res” 

01B3 Media Touch Systems 

01B4 Network Management Product NCR - SE 

Columbia 


Columbia 


Columbia 





Columbia 


Columbia 

01B9 Bonsai Technologies 

01BA BizTech 

01BB Bonsai Technologies 

01BC Bonsai Technologies 

01BD Bonsai Technologies 

01BE Server Type KM Systems 

01BF “Server Type for Value Added Product/ 

LanDesk Mgr Connect Computer Co/ 

Intel” 

01C0 “Object Type Collegiale, City of (Ottawa)” 

01C1 Object Types J&L Information Systems 





01C6 Distributed Application Folio Corporation 

01C7 Bindery Type Microtest Inc 

01C8 Object Bindery Type Madge Networks Inc 

01C9 Object Types Funk Software 

01CA Object Types Funk Software 

01CB NetModem/E Shiva Corp 

01CC LanRover/E Shiva Corp 

01CD LanRover/T Shiva Corp 

01CE Shiva Corp 

01CF E-mail Queue Object-type C&D Data 

Services 

01D0 E-mail Server Object-type C&D Data 

Services 

01D1 Lanlord Product Microcom Client Server 

Tech Gr 

01D2 Mark Hurst 

01D3 Mark Hurst 

01D5 Centers for Disease Control 

01D6 On-Queue Task Queue NetPlus Software 

Inc 

01D7 On-Queue Task Server NetPlus Software 

Inc 

01D8 FAXPress Server Castelle Inc 


01D9 Castelle Inc 

01DA LANPress Print Server Castelle Inc 

01DB Castelle Inc 

01DC FAX/Xerox 7033 Fax Server/Excel Lan Fax 

Castelle Inc 

01DD Castelle Inc 

01DE Castelle Inc 

01DF Castelle Inc 

01E0 Castelle Inc 

01E1 Castelle Inc 

01E2 Area Code & Exchange Look-Up Server 

Equinox Information Systems 

01E3 Sorting Server Equinox Information 

Systems 

01E4 Wall Data 

01E6 X25 Automated Bridge Monitor & Control 

Automated Interactions-Div Of 

01E7 Rational Data Systems 



01EA Rational Data Systems 

01EB Media Touch Systems 

01EC Powergrid Network Daemon Cognos Inc 

01ED Integralis Ltd 

01EE Integralis Ltd 

01EF Felsina Software 

01F0 Legato Systems 






01F6 Andersen Consulting - Chicago 

01F8 Sytron Corp 

01F9 “For Unibase Bv, Based in Holland 

Integralis Ld” 

01FB Northeast Broadcast Consultant 

01FC Extended Systems 

01FD IBM - Endicott 

0200 NP/SQL Server Novell - Provo Corp HQ 

0201 The Make Server Novell - Provo Corp HQ 




0202 Generic Job Server Novell - Provo Corp 

HQ 

0203 RMF2 Utility Novell - Provo Corp HQ 







020A Novell - Provo Corp HQ 

020B Novell - Provo Corp HQ 

020C Novell - Provo Corp HQ 

020D Novell - Provo Corp HQ 

020E Novell - Provo Corp HQ 

020F Novell - Provo Corp HQ 







021A OT_Messaging_Server Novell - San Jose 

021D MPR - NetWare Mobile IPX Home Router 

Novell - Fortune 

021E NetWare Lontalk Gateway Novell 

0233 NW Management - Management Agent 1.x 


0234 Network Management Info Server Novell - 

Provo Corp HQ 

0235 Bindery Type - TIRPC Service Novell - 

Provo Corp HQ 

0236 Novell - Salt Lake City 

0237 NMS IPX Discover or LANtern Read/Write 

Channel Novell - San Jose 

0238 NMS IP Discovery or LANtern Trap/Alarm 

Channel Novell - San Jose 

0239 NW Management - HMI Hub Management 

Novell - San Jose 

023A NW Management - Lanalyzer Agent Novell 

- San Jose 

023B Bindery Type for Broadcast Novell - Provo 

Corp HQ 

023C DOS Target Service Agent Novell - Provo 


Corp HQ 

023D SMS Workstation Name Object Novell - 

Provo Corp HQ 

023E SMS Testing & Development Novell - 

Provo Corp HQ 

023F SMS Testing & Development Novell - 

Provo Corp HQ 

0240 Novell - San Jose 



0243 Novell MHS DS Gateway for OCE Novell - 

Walnut Creek 

0244 NDS Gateway for OCE Novell - Walnut 

Creek 

0245 Superlab File Distribution Server Novell - 

Provo Corp HQ 

0246 Version Control Queue Novell - Provo 

Corp HQ 

0247 NVT Remote Login over SPX Novell - Salt 

Lake City 

0248 Queue Server for IBM PSF/2 Novell - 

Provo Corp HQ 

0249 Lantern RMON Novell - San Jose 

024A LAT Transport Service Provider Novell - 

Sunnyvale Western Reg 

024B LAT Session Manager Novell - Sunnyvale 

Western Reg 

024C LAT Network from NetWare Novell - 


024D Address Server Novell - Provo Corp HQ 

024F Appletalk Remote Access Service Novell - 


025E Xapia Interface for NW 3.11 Novell - Indisy 

Canada Inc 

025F X.400 Protocol Access Module Novell - 

Indisy Canada Inc 

0260 SNADS Protocol Access Module Novell - 

Indisy Canada Inc 

0261 Superlab Network Switch Server Novell - 

Provo Corp HQ 

0262 Hub Services Novell - Sunnyvale - 

Western Reg 

0263 NetWare Management Agent Novell - 

Sunnyvale - Western Reg 

0264 Global MHS Novell - Sunnyvale - Western 

Reg 

0265 SNMP Novell - Sunnyvale - Western Reg 

0266 Version Control Server Novell - Provo Corp 




HQ 

0267 Application Rights Program Novell - Provo 

Corp HQ 

0268 HP JetDirect Novell - San Jose 

0269 Superlab Automation Server Novell - Provo 

Corp HQ 

026A NW Management - NMS Console Novell - 

San Jose 

026B NW Time Synchronization Novell - Provo 

Corp HQ 

026D Advertising Job Server Novell - Provo Corp 

HQ 

0272 Datalink Switching (DLSW) Novell - San 

Jose 

0273 Nest Device Novell - Provo Corp HQ 

0274 GroupWise Message Multiple Servers 

Novell - Orem 

0275 Sample Code from Dev. Support Novell - 

Provo Corp HQ 

0277 SAP Server Type Novell - San Jose 

0278 Directory Server/ NDS Replica /Tree 


0281 Domain Application Services Novell - 


0282 NDPS Service Registry Service Novell - 

Provo Corp HQ 













028A MPR - IPX Address Mapping Gateway 

Novell - San Jose 

028B ManageWise Novell - San Jose 

028D Salutation Manager Novell - Orem 

028E Novell Administrator for Win NT/Tabasco 


0292 NetWare Client Libraries Novell - Provo 

Corp HQ 

02FF Novell - Provo Corp HQ 

0300 VAP - Advertising Services Firefox 


Communications Ltd 







0304 VAP - Advertising Services/ SAA Gateway 

Firefox Comm Ltd/Novell 



0306 NPS (NetWare Print Services) 

InterConnections Inc 

0307 NPS Spool Client InterConnections Inc 

0308 HP NS Util Hewlett Packard - Boise 

0309 Document Management Package Soft 

Solutions 

030A Worldgroup BBS Server Galacticomm Inc 

030B Lucid Systems Pty LTD 

030C HP JetDirect/ Quick Silver Hewlett Packard 

- Boise 

030D Broadcast Operation Sup Utah Scientific 

030E Fault Tolerant Control Utah Scientific 

030F CD ROM Server Trantor System Ltd 

0310 CD ROM Server Trantor System Ltd 





0315 CD ROM Serve Trantor System Ltd 


0317 Batch Processor Computer Aided 

Business Sol 

0320 Gateway Attachmate Corporation 

0321 Chicago Research & Trading 

0322 Frye Computer Systems 

0323 Wang Laboratories 

0324 Wang Laboratories 

0325 X.500 DSA Server AAC Associates 

0326 Novell Remote ISDN Router LANWorks 

0327 BootWare/Microsoft Diagnostics (MSD) 

LANWorks 

0328 SQL Server Watcom 




0329 Aetna Life & Casualty 

032A Aetna Life & Casualty 

032B Fax Server Digital Visions Corp 

032C Voice Server Digital Visions Corp 

032D Interprocess Exchange Server Digital 

Visions Corp 

032E Application Server Nationsbank Mortgage 

Corp 

0330 SAS Share Server SAS Institute 

0331 SAS Connect SAS Institute 

0332 Archetype 

0333 Archetype 

0334 Aetna Life & Casualty 

0335 Multisynch Communications Server 

Multitech 

0336 Communications Server Multitech 

0337 Magee Enterprises Inc 



033A Magee Enterprises Inc 

033B Magee Enterprises Inc 

033C Magee Enterprises Inc 

033D Magee Enterprises Inc 

033E Magee Enterprises Inc 

033F Magee Enterprises Inc 


0341 Data Service to Workstation/School Admin 

Chancery Software 

0342 Bindery Type Microtest Inc 








034A Public Preferred Systems Inc. 

034B Preferred Systems Inc. 

034C Preferred Systems Inc. 

034D Preferred Systems Inc. 


034E Preferred Systems Inc. 

034F Preferred Systems Inc. 

0350 Preferred Systems Inc. 

0351 Preferred Systems Inc. 

0352 Bindery Type Fujitsu Ltd 



0355 Backup Exec Arcada Software 

0356 LANovation 

0357 LANovation 

0358 Bindery Object Type CBIS Inc 

035A MBAC 

035B Right-Hand-Man E-mail/scheduling Pkg 

LAN Aces Inc 

035C Fax Server Transfax Corporation 

035D Fax Print Server Transfax Corporation 

035E Fax Merge Server Transfax Corporation 

035F Network Management Server Transfax 

Corporation 

0360 Object Type Funk Software 

0362 “Object-type, Pseudo Peer-to-peer US 

Army Corps of Engineers” 

0363 Print Server - Laser Jet Extended Systems 

0364 Server-type for LAN Times Japan Softbank 

Corp 

0365 Queue-type for LAN Times Japan Softbank 

Corp 

0366 MGATE - Communication Gateway/LANs 

+ Vax Coefficient Systems Corp 

0367 Excalibur Technologies Corp 



036A Excalibur Technologies Corp 

036B Bindery Type Aetna Life & Casualty 

036C IPX Layer Peer-to-peer Communications 

Sewell Development 

036D Micro Integration 

036E NLM Server Praxis 

036F Bindery Type Avail Systems Corp 

0372 Digital Equipment - Merrimack 

0373 NLM Advertising for UPS Info Brainstorm 

Engineering 




0374 Shareware Communications Server Cherry 

Tree Software 

0375 Enterprise ECS Intel Corp - Hillsboro 

0376 Enterprise Initialization Mode Intel Corp - 

Hillsboro 

0377 Comm Svr - Net Bios IPX US Robotics 

Software 

0378 NLM Advertising for UPS Info Brainstorm 

Engineering 

0379 Fax Server Extended Systems 

037A Fax Server Extended Systems 

037B Fax Server Extended Systems 

037C Fax Server Extended Systems 

037D Gateway Management Wall Data 

037E Powerchute Alert - UPS Monitoring 

American Power Conversion 

037F ViruSafe Notify Central Point Software 

0380 Fax Server Optus Information Systems 

0381 “TNS Transport Network Substrate, Vers 2 

Oracle” 

0382 ID for Lasermaster Printer Products Laser 

Master Corp 

0383 PowerChute Administrative American 

Power Conversion 

0384 Sequel Link Client-server Middleware 

Techgnosis Inc 

0385 Mail Systems Synectic Systems Ltd 

0386 Hewlett Packard Bridges Hewlett Packard - 

Roseville 

0387 Hewlett Packard Hubs Hewlett Packard - 

Roseville 

0388 Workstation Peer-to-peer Communications 

IBM - Research Triangle Park 

0389 Datanex Corporation 

0394 NetWare Connect NCS (Mac) Server 

Novell 

039A HP Open Mail & Portable NetWare Hewlett 

Packard - Berkshire 

039B Lotus Notes Iris Associates 

039C Communications Server Bindery Dator 3 

SPOL SRO 

039D Communications Server SAP Dator 3 

SPOL SRO 

039E Fax Server Ferrari Electronic GMBH 

039F Computer Vision Services 

03A0 Bindery Type for CD Server Jostens 


Learning Corp 

03A1 Neumeier & Walch Systemtechnik 

03A2 Hyprotech Ltd 

03A3 “Kyocera Corp, Yohaga Office” 




03A7 Object Type for a Group Stadt Pforzheim 

03A8 Object Type for a Queue Stadt Pforzheim 

03A9 Object Type for a Server Stadt Pforzheim 

03AA Universal Data Systems - Motorola 

03AB Universal Data Systems - Motorola 

03AC Universal Data Systems - Motorola 

03AD Universal Data Systems - Motorola 

03AE Raima Corp 

03AF Copy Protection Server Pace Software 

Systems Inc 

03B0 TNA Communication with 2 NLM's 

Palindrome 

03B1 Ethernet LAN Controller for NetWare Bus 

Tech 

03B2 Server ID for NLM Network Designers LTD 

03B3 File Management Services Systems Axis 

PLC 

03B4 Queue Management Services Systems 

Axis PLC 

03B5 Object Type IWI - Integrated Workstation 

Inc 

03B6 LANtech Services 

03B8 Modem Protocall - Sharing Serial Ports 

LANsource Technologies 

03B9 Global Info Application Exec Environment 

Funk Software 

03BA Magix Database Server Advanced 

Software Technologies 

03BB Performance Monitor Computer 

Communications Co/ Ameridata 

03BC NetPort Advertising Intel PCED 

03BD Wan Connection Server IDE Corporation 

03BE WICAT Jostens Learning Corp 

03BF WICAT Server Jostens Learning Corp 

03C0 Embedded in OEM Plotter Product 

CalComp 





CalComp 


CalComp 


CalComp 

03C7 LAN Spool 3.5 Intel - Hillsboro 

03C8 Network Management Madge Networks 

Ltd 

03C9 Diatek 

03CA Point-of-sale Server Optical Mark Systems 

Ltd 

03CB Software Access Control Server U of 

Plymouth 

03CC Axnetwar - Envelope/label Print Server 

Thuridion Software Engineering 

03CF Database Engine Blue Lance Network Info 

Sys 

03D0 Report Engine Blue Lance Network Info 

Sys 

03D1 Job Server Blue Lance Network Info Sys 

03D2 Object Type Blue Lance Network Info Sys 

03D3 Object Type Blue Lance Network Info Sys 

03D4 Visinet NLM ID# Technology Dynamics Inc 

03D5 Print Servers Lexmark International 

03D6 Print Servers Lexmark International 

03D7 Print Servers (type 4033-011) Lexmark 

International 

03D8 XLE Print Servers (type 4033-301) 

Lexmark International 

03D9 Server Monitoring Program Trellis 

03DA Multiple Services & Applications Think 

Systems Corp 

03DB Multiple Services & Applications Think 

Systems Corp 

03DC Multiple Services & Applications Think 

Systems Corp 

03DD Developing Server Performance Analyzer 

Banyan Systems Inc 

03DE Gupta Sequel Base Server / NW SQL 

Gupta Technologies 

03DF Remote Database Services Interactive 

Data Corp HQ 

03E0 Object Store Server Object Design 

03E1 Univel Server Type (Unixware) Univel 

03E2 Univel Server Type Univel 



03E4 Univel Server Type (Unixware) Univel 






03EA Univel Server Type Univel 

03EB Univel Server Type Univel 

03EC Univel Server Type Univel 

03ED Univel Server Type Univel 

03EE Univel Server Type Univel 

03EF Univel Server Type Univel 

03F0 Univel Server Type Univel 

03F1 First Call Thomson Financial 

03F2 Access Rights Server QM Consulting 

03F3 Vital Signs/LAN Server Blue Line Software 

Inc 

03F4 LAA Server Bindery Saber Software 

03F5 Microsoft SQL Server IPX/SPX Support 

Microsoft 

03F6 Asynchronous Serial Communications 

Black Creek Integrated Systems 







03FA Watson - Communications Server Prodigy 

Services 

03FB Netport Advertising Intel PCED - Hillsboro 

03FC Netport Advertising Intel PCED - Hillsboro 

03FD Netport Advertising Intel PCED - Hillsboro 

03FE Netport Advertising Intel PCED - Hillsboro 

03FF Modular Software Corporation 

0400 Bindery Object Types Artefact Network 

Support 


Support 


Support 


Support 





Support 


Support 


Support 


Support 


Support 


Support 

040A Image Application Laser Data 

040B Image Application Laser Data 

040C Image Application Laser Data 

040D Image Application Laser Data 

040E Image Application Laser Data 

040F Image Application Laser Data 

0410 Image Application Laser Data 




0414 Netsprint Digital Products Inc 

0415 Remote Database Services - Bindery 

Interactive Data Corp Corp HQ 

0416 Dealing Room Servers Teknos Systems 

Ltd 


Ltd 


Ltd 


Ltd 

041A Dealing Room Servers Teknos Systems 

Ltd 

041B Dealing Room Servers Teknos Systems 

Ltd 

041C Dealing Room Servers Teknos Systems 

Ltd 

041D Dealing Room Servers Teknos Systems 

Ltd 

041E Dealing Room Servers Teknos Systems 

Ltd 

041F Dealing Room Servers Teknos Systems 

Ltd 


Ltd 



Ltd 


Ltd 


Ltd 


Ltd 


Ltd 


Ltd 


Ltd 


Ltd 


Ltd 

042A Full Text Retrieval Client/server DB Eng 

Impact Italiana SRL 

042B Gateway Software Datev HA 

Systemtechnik 

042C Gateway Software Datev HA 

Systemtechnik 

042D Client-server Driver for IPX/SPX Reference 

Point Software 

042E Intrak Inc 

042F Loader Bindery Type Casper Systems Inc 

0430 Finder Bindery Type Casper Systems Inc 

0432 Filemaker Pro Claris Corp 

0433 Networking Hub (281x Advanced SNMP 

Agent) Synoptics 

0434 Network Terminal Emulator IDE 

Corporation 

0435 Administration Server McGill University 

0436 Network Dynamic Data Exchange Net 

Logic 

0437 Asynchronous Communications Server US 

Robotics Inc 

0438 Back up Product Corel Systems Corp 

0439 Back up Product Corel Systems Corp 

043A Miscellaneous Software Communications 

Tentera Computer Services 

043B Enterprise in Maintenance Mode Intel 

PCED - Hillsboro 

043C Connection Station Service Type Corollary 

Inc 




043D Connection Station Service Type Corollary 

Inc 

043E Connection Station Service Type Corollary 

Inc 

043F Connection Station Service Type Corollary 

Inc 

0441 Connection Station Service Type Corollary 

Inc 


Inc 


Inc 

0444 SNA Gateway / Microsoft SNA Server 

Microsoft 

0445 Workstation Terminal AccessHSD 

Hardware Software Dev 

0446 DE International Ltd 

0447 Distributive Cache Product Raima Corp 

044D IBM Host Gateway Idea Courier 

044E Project ID Urban Science Applications 

044F Common Communication Interface 

Computer Associates 

0450 Communications Server SDD Synthesizer 

Scandinavian Airlines 

0451 Tape Back-up for NLM Applications 

Mountain Network Solutions Inc 











0457 Canon Peripheral Server (GP55) Canon 

Information Systems 

0458 NetWare Server Product Intel - Phoenix 

0459 Object Oriented Database System Ontos 

Inc 

045A QMS Printer - Remote Configuration QMS 

045B Client Server Monitoring Util (SCSI Array 

Monitor) Dell Computer Corp 

045C Bindery Type - Application Definition 

LANovation 

045D Fax Server Ferrari Electronic GMBH 


045E Fax Server Ferrari Electronic GMBH 

045F Fax Server Ferrari Electronic GMBH 

0460 Fax Server Ferrari Electronic GMBH 

0461 Communications Gateway - OSI Eicon 

Technology 

0462 Communications Gateway - SNA Eicon 

Technology 

0464 Batchfiler Application Jovandi International 

Inc 

0465 NLM on File Server Jovandi International 

Inc 

0466 Time Synchronization Server Jovandi 

International Inc 

0468 Telephone Answering System A & M 

Communications 

046A Fax Server Extended Systems 

046B Cadence Time Service Polygon Inc 

046C Poly-portal for NetWare/Ethernet Gateway 

Polygon Inc 

046D Poly-link PC to Vax Networking Utilities 

Polygon Inc 

046E LAT ServicePolygon Inc 

046F Automatic Tracking System Automated 

Interations 

0470 Measureservers and Measureclients 

Advantech Benelux BV 

0471 Disk Monitor Storage Dimensions 

0472 Enterprise Network Services Banyan 

Systems Inc 

0474 Sybase SQL Server Sybase 

0475 Sybase SQL Server Console Sybase 

0476 Sybase SQL Server Monitor Sybase 

0477 Sybase SQL Server Back-up Sybase 

0478 Sybase Open Server Sybase 

0479 Sybase Open Server Console Sybase 

047C Remote Printer Console Peerless 

047D Auto-on/off Control NLM Mitsubishi Denki 

Computer 

047E Ascom Fax Server Ascom 

Telecommunications Ltd 

047F Ascom Advertising Fax Server Ascom 


0480 Ascom Fax Queue Ascom 


0481 Job Server High Aspect Development 




0482 Job Queue High Aspect Development 

0483 Finance Think Systems Corp 

0484 Forcasting Think Systems Corp 

0485 Schema Think Systems Corp 

0486 Fail Safe Analysis Think Systems Corp 

0487 Think Systems Corp 

0488 Communication Between Client and Server 

CDC Federal Credit 

0489 Store Name of Special File on Fileserver 

Delta Information Systems 

048A Main NLM Server for Calendar Manager 

Russell Information Sciences 

048B Array Monitor Server Core International 

048C Document Processing Server NLM Boss 

Logic Inc 

048D Document Processing Server NLM Boss 

Logic Inc 

048E Document Processing Server NLM Boss 

Logic Inc 

048F Document Processing Server NLM Boss 

Logic Inc 

0490 Power Product for File Server Brainstorm 

Engineering 

0491 NetBlazer Communication Server Telebit 

Corp 

0492 RTS Terminal Emulation Data Research & 

Applications 

0493 RSCF Client-Server API Data Research & 

Applications 

0494 CD Networker Bindery Type Lotus 

Development 

0495 Remote Back-Up Device Astora Software 

Inc 

0496 SQL Server IPX/SPX Hidden Server 

Microsoft 

0497 Database Lock Server High Aspect 

Development 

0498 Meter Server Polymeter Response Ltd 

0499 Lancorp EOMS Lancorp Pty Ltd 

049A Bull HN SDMLancorp Pty Ltd 

049B Network Management Agent Eicon 

Technology 

049C ICOT SNA Gateway ICOT 

049D Software NLM Interconnections 

049E Internet Gateway Metascybe Systems Ltd 

049F Email & Calendaring Communication 


Server Attachmate Canada 

04A1 Automation Information Router Kurt 

Manufacturing 

04A2 Xbase Record Engine Extended Systems 

04A3 Remote Procedure Call System Fortunet 

Inc 

04A4 Delivery of Valuable Info W/usage 

Tracking Wave Systems Corporation 

04A5 Remote Access Server Traveling 

Software Inc 

04A6 Bindery for Program Metering Database 

Pilot Systems 

04A7 Lt Auditor 4.00 Plus Blue Lance Network 

Info Sys 

04A8 Bindery Service Fujitsu 

04A9 Bindery Service Fujitsu 

04AA SAP Service Fujitsu 

04AB SAP Service Fujitsu 

04AC Calendar Server Campbell Services Inc 

04AE LED Server Inova Corporation 

04B0 CDnet Server Meridian Data Corp 

04B1 Policy Engine Emerald Systems 






04B7 LAN Assist plus Remote Control Microtest 



04BA LAN Assist plus Remote Control Microtest 

04BB Map Assist Peer-to-peer Microtest 

04BC Map Assist Peer-to-peer Microtest 

04BD Map Assist Peer-to-peer Microtest 

04BE Map Assist Peer-to-peer Microtest 

04BF Jetnet Driver for Novell IPX Protocols 

Jetstream Technology Ltd 

04C0 Database Server Running as NLM 

Lodestar Data Systems Inc 

04C1 Asynchronous Communications Servers 

US Robotics Inc 

04C2 Database Server Faircom 

04C3 Taurus Database Server DCI 




04C4 Taurus Serial Server DCI 

04C5 Casper Queue Casper Queue 

04C6 Casper Ghost Casper Systems Inc 

04C7 Conferencing Service 

04C8 Mail System Queue Service Mitsubishi 

Electric 

04C9 Video Server Novell - Multimedia 

04CA Message Express Product Horizon 

Strategies Inc 

04CB CD ROM Server CBIS Inc 

04CC Cost Recovery Server Vincent Larsen 

04CD PC-based SNA Gateway Ungermann 

Bass 

04CF User Restrictions Val Laboratory Co Ltd 

04D0 User Restrictions Val Laboratory Co Ltd 

04D1 SAP Advertising on Print Server Nissin 

Electric Co Ltd 

04D2 OT Ellipse Server Bachman Information 

Systems 

04D3 Asynchronous Access Server Skyline 

Technology 

04D4 Enterprise Description Object 

Ingenieurburo Spatzier 

04D5 Print Server Foresyte Technologies 

04D7 Cubix QL Server Cubix Corp 

04D8 Cubix QL Client Cubix Corp 

04D9 Job Server Storage Dimensions 

04DA Communication Server Firefox 


04DB Communication Server Firefox 


04DC Communication Server Firefox 


04DD Communication Server Firefox 


04DE Communication Server Firefox 


04DF Communication Server Firefox 


04E0 Communication Server Firefox 





















04EA Communication Server Firefox 


04EB Communication Server Firefox 


04EC Communication Server Firefox 


04ED Communication Server Firefox 


04EE Remote Access Server ICC 

04EF Statistic Management MultiTech 

04F0 Statistic Management MultiTech 

04F1 Remote Control Software MultiTech 

04F2 Remote Control Software MultiTech 

04F3 MultiTech 

04F4 NetLynx Communication Server Andrew 

Corporation 

04F5 NetLynx Communication Server Andrew 

Corporation 

04F6 Netlynx Communication Server Andrew 

Corporation 


Corporation 


Corporation 


Corporation 

04FA Netlynx Communication Server Andrew 

Corporation 

04FB Netlynx Communication Server Andrew 

Corporation 

04FC Netlynx Communication Server Andrew 

Corporation 

04FD Netlynx Communication Server Andrew 

Corporation 

04FE Netlynx Communication Server Andrew 




Corporation 

04FF Netlynx Communication Server Andrew 

Corporation 

0500 Netlynx Communication Server Andrew 

Corporation 


Corporation 


Corporation 


Corporation 

0504 Deskview X Bindery Type Quarterdeck 

Office Systems 

0505 Print Server Add-on Intel - Hillsboro 

0506 Index Sequential Access NLM Infopoint 

Systems 

0507 Associative Index Server Infopoint 

Systems 

0508 Netscribe Server Meridian Data Corp 

0509 Print Server for Remote Workstations 

Fuji Xerox Co Ltd 

050A Netmagic Bindery IdNet Magic Systems 

Inc 

050B Financial Market Information Server AT 

Financial 

050C Network Modem Anagram 

050D Network Modem Anagram 

050E Document Management Service Imagery 

Software Inc 

050F Image Management Service Imagery 

Software Inc 

0510 Mass Storage Service Imagery Software 

Inc 

0511 Database Server Tobit Hard & Software 

GMBH 

0512 Teli-Link Voice Server Computer & 

Communications Co 

0513 Print Server Emulex Corporation 

0514 1012 Hub Agent Asante Technologies 






051A 1012 Hub Agent Asante Technologies 

051B 1012 Hub Agent Asante Technologies 


051C 1012 Hub Agent Asante Technologies 

051D 1012 Hub Agent Asante Technologies 

051E Advertising Network Modems LANsource 

Technologies 

051F Application Programs U of Plymouth 

0520 Bloomberg Audio Server Bloomberg LP 

0521 Bloomberg Process Server Bloomberg LP 

0522 Net Modem Server Practical Peripherals 

Inc 

0525 Agent for Hub Management Idea Courier 

0526 Named Pipe Communications Service 

Symantec Group 

0527 Print Server/Remote Printer Pacific Data 

Products 

0528 Print Server Seiko Epson Corp 

0529 InterServer File Copying Bankers Trust 

Co 

052A Fax & Voice Server DCA 

052B Angora Enterprise Gateway Rabbit 

Software Corp 

052C LANtronix / Remote Login Terminal 

Gordian 

052D Application Server Citrix Systems 

052E OT_Bloomberg Media Touch Systems 

052F Microcom Remote Access Server 

Microcom Inc 

0530 Remark Voice Server Simpact Associates 

Inc 

0531 IPX Communication Server Symantec 

Group 

0532 Access Server for Modem Sharing Bay 

Technical Associates Inc 

0533 Gateway Between Network & Visa Pos- 

Port Hemko Systems 

0534 Device Location via Remote Config Tool 

Milan Technology Corp 











053A Device Location via Remote Config Tool 





053B Device Location via Remote Config Tool 


053C Device Location via Remote Config Tool 


053D Device Location via Remote Config Tool 


053E Remoted SMS Server New Era Systems 

Services Ltd 

053F Listener/NetWare Sterling Tefen Lab 

0540 Listener/DOS Sterling Tefen Lab 

0541 Listener/Windows Sterling Tefen Lab 

0542 Listener/OS2 Sterling Tefen Lab 

0543 Listener/MAC Sterling Tefen Lab 

0544 Listener/Unix Sterling Tefen Lab 

0545 Techra Client/Server RDBMS Kvatro As 

0546 DOCRA Client/Server Doc Mgmt System 

Kvatro As 

0547 Voice/fax Responding Machine System 

Sophia 

0548 I4/LS Naming Service Gradient 

Technologies 

0549 TNSI Network Utilities Toadally Network 

Systems Inc 

054A RM3 Configuration Cayman Systems Inc 

054B SNMP Configuration Cayman Systems Inc 

054D Imagesolve_ofs Imagesolve International 

054E District Communication Gateway 

Chancery Software Ltd 

054F District Link Chancery Software Ltd 

0550 EDM Client/PC Computer Vision 

0552 Security Object Bank of New Zealand 

0555 “Printers, Plotters & Routers Seiko 

Instruments Inc” 

0556 Fax Services OAZ Communications Inc 

0557 Fax Services OAZ 

0558 Fax Services OAZ 

0559 AT&T Joint Venture Telephony Server 


055A AT&T Joint Venture Telephony Server 


055B AT&T Joint Venture Telephony Server 


055C AT&T Joint Venture Telephony Server 



055D Hostview Utility Attachmate Corp 

055E Print Server Lexmark International Inc 

055F Print Server Lexmark International Inc 

0560 Print Server Lexmark International Inc 

0561 Print Server Lexmark International Inc 

0562 Statistics Gathering Agent Netcraft 

Software Development 

0563 ERL Database Server Silver Platter 

Information Ltd 

0564 ERL Directory Server Silver Platter 

Information Ltd 

0565 Newswire Notification Generation 

Technologies Corp 

0566 Ziff Proprietary Services Ziff Information 

Services 

0567 Time Server NLM Meinberg Funkuhren 

0568 X-Base Database Server Extended 

Systems 

0569 Advertising Media-DB Server Ravi 

Technologies Inc 

056A OEM Remote Access for Ethernet Shiva 

Corp 

056B OEM Remote Access for Tokenring Shiva 

Corp 

056C Integrated Remote Access for Ethernet 

(LanRover/E Plus) Shiva Corp 

056D Integrated Remote Access for Tokenring 

(LanRover/T Plus) Shiva Corp 

056F Med Station Server Pyxis Corporation 

0570 Telnet IPX Router Teletrol Systems Inc 

0571 NLM Server SR Associates/Cybermedia 

0572 Advertising NetModem Server Practical 

Peripherals Inc 

0573 Satellite Connections ULF Zimmermann 

0574 LAN/CD Server Logicraft 

0576 Peer Communications Tool Intelec 

Systems Corporation 

0577 Communication Server Norman Data 

Defense Systems 

0578 Modem Sharing Software SEG 

0579 Hops Database Server Hops 

International 

057A Datafile Access Handler LMS 

057B Novus Gateway Product Firefox 


057C LGS Interconections 




057D LGS-PFT Interconections 

057E LGS-PPS Interconections 

057F TN 3270 Gateway Bus Tech Inc 

0580 McAfee Virus Pattern Server (NetShield) 

McAfee Associates 

0581 Optical Server Optisys 

0582 Proride X.500 LDAP Support Control Data 

Systems 

0583 Net Trax Alarm Monitor Net X Corp 

0584 Net Trax File Server Agent Net X Corp 

0585 Net Trax Workstation Agent Net X Corp 

0586 Net Trax Bridge Agent Net X Corp 

0587 Team Office Product ICL Personal 

Systems OY 

0589 Hyperdesk Distribute Object Mgmt System 

Hyperdesk 

058A Hyperdesk Database Type Hyperdesk 

058B TCP/SuperLAT Host Print SAP Meridian 

Technology Corp 

058C OCS SafeServer Omnitech Corporate 

Solutions 

058D Jukebox User Group Todd Enterprises Inc 

058E Full Screen Login Confirm 

058F Meeting Space Server World Benders 

Inc 

0590 LAN Product Server BMC Software Inc 

0591 CBT Server First Class Systems 

0592 Net Tune Service Hawknet Inc 

0593 Print Server Ricoh Company Ltd 

0594 Remote Printer Ricoh Company Ltd 

0595 Slathp Status NLM Meridian Technology 

Corp 

0597 IPX Named Pipes Communication Service 

Symantec Group 

0598 Appmeter for Suites Funk Software 

059C ServerLog Diamond Software Inc 

05A0 Service Location Protocol Eicon 

Technology 

05A1 NMS Icons Networth Inc 










05AA NMS Icons Networth Inc 

05AB NMS Icons Networth Inc 

05AC NMS Icons Networth Inc 

05AD NMS Icons Networth Inc 

05AE NMS Icons Networth Inc 

05AF NMS Icons Networth Inc 

05B0 NMS Icons Networth Inc 



05B3 Multi-System Manager - Netview Interface 

IBM - Research Triangle Park 

05B4 Online Transaction Transportation System 

ABG Technology/United Card Svc 

05B6 Datastar NLM Apertus Technologies 

05B7 DS_LCC - Logical Link Controller Apertus 

Technologies 

05B8 Database Management Services 

Revelation Technologies 

05B9 Distribution Services Discovery IBM - 

Rome 

05BA Managing Hardware Routers Compatible 

Systems Corp 

05C0 Calendar Server Campbell Services Inc 

05C1 Network Management Application Xircom 






05D9 Ethernet-Managed Stackable Hub IBM - 

Research Triangle Park 

05E4 FileNet Network Clearinghouse File Net 

05E5 HPCS Data-Based Products Tobit Hard & 

Software GMBH 

05E6 AST SNMP Instrumented Server AST 

Research Inc 

05EB Office Extend Server Fransen King 

05EC Windows NT Named Pipe Server Optus 

Information Systems 




05ED Gateway Server Fujitsu Ltd 

05EE Bindery File Fujitsu Ltd 

05EF Fax Workstation Object Sofnet Inc 

05F2 Router Administration Server Livingston 

Enterprises 

05F3 Client Server Array Monitor Program 

Allodyne Inc 

05F4 Evergreen Management Agent Goodall 

Software Engineering 

05F5 Windows Bulletin Board System Pacer 

Software 

05F8 UPS SNMP Monitor NLM Computer Site 


05FA Goodall Virtual Protocol Adaptor Goodall 

Software Engineering 

0603 Time Card Server Advanced 

Management Solutions 

0606 Image Server Address Look-up 

Watermark Software 

0607 Arts RLogind Server Reuters/ American 

Real Time 

0608 Arts Generic Server Reuters/ American 

Real Time 

0609 Arts RUUPD - Are You up Daemon 

Reuters/ American Real Time 

060A Money Center Data Server Knight Ridder 

Financial Inc 

060C Axis Printer Server Axis Communications 

AB 

060D Unix Mail Server Felpausch 

0610 SCSI Management Adaptec Inc 

0611 Stealth Event Capture Engine 

Intelligence Quotient Intl Ltd 

0613 Universal Data Transporter Conseil 

Formation et Developpe 

0614 Communication Software (NLM) NEC - 

Nippon Electric Company 

0615 Communication Software (NLM) NEC - 

Nippon Electric Company 

0616 Fax Gateway Server Russell Consulting 

061C Print Server Emulex Corporation 

061D Print Server Emulex Corporation 

061E Print Server Emulex Corporation 

061F Print Server Emulex Corporation 

0620 Print Server Emulex Corporation 

0625 Setup Manager Access Control 

Maximized Software 


062F Metering Program Secure Design 

0636 Comet Terminal Server Goodall Software 

Engineering 

0637 Comet File Server Goodall Software 

Engineering 

0640 Windows NT Server-RPC Services 

Gateway Services for NW 

Win 95-User Level Security Microsoft 

064E NT Server-Internet Information Server 

Microsoft 

073D Connect:Direct NLM Server Sterling 

Software 

073E Connect:Direct NLM Server Sterling 

Software 

073F Connect:Direct NLM Server Sterling 

Software 

0740 Connect:Direct NLM Server Sterling 

Software 


Software 


Software 

0743 Maxserv 3270 Maxserv 

0744 Maxserv Price Maxserv 

0745 Maxserv Mail Maxserv 

0746 Maxserv Macs Maxserv 

0747 Maxserv Reserved Maxserv 

0748 Maxserv Reserved Maxserv 

0749 Tasking IPX/LWSI Gateway Tasking 

Software BV 

074D NLM Applications KNX Ltd 

074E NLM Applications KNX Ltd 

074F NLM Applications KNX Ltd 

0750 NLM Application KNX Ltd 

0753 STP Protocol Service Agent (CSA_FTP) 

Digital Technologies 

0754 IndF$file File Transfer Agt (CSA_indfile) 

Digital Technologies 

0755 All Kalpana Switches Kalpana 

0756 Chat Server Microsoft 

0757 Titanium Database Engine Micro 

Database Systems Inc 

0758 TCS Communication Server Micro 

Tempus Inc 

0759 PC Communication Partner SAP Fujitsu 




Ltd 

075A PC Communication Partner SAP Fujitsu 

Ltd 

075B PC Communication Partner Bindery 

Fujitsu Ltd 

075C DPC Server SAP Fujitsu Ltd 

075D DPC Server Bindery Fujitsu Ltd 

075E CAM Host TMD Consulting 

075F Server Monitoring Application Softwork 

GMBH 

076A Alarm Manager NLM Arcada/ Conner 

Peripherals 

076B Event Manager NLM Arcada/ Conner 

Peripherals 

076D Desktop Management NLM Advanced 

Modular Solutions Inc 

0770 Real-Time Integration Services Industrial 

Peer-to-Peer 

0771 LANDeep Server Monitor Deerfield 

Computer Solutions 

0773 Hitecsoft Api Manager Hitecsoft Corp 

0774 Hitecsoft Public Library Hitecsoft Corp 

0775 Hitecsoft Phone Server Hitecsoft Corp 

077B Advantage X-Base Server Extended 

Systems 

077F Security Auditor Secure Design 

0780 “U of Wisconsin Utilities U of Wisconsin - 

Madison, CAE” 







078B A Non-Name-Pipe Server Team 

Development Corp 

0798 NetHopper Router Rockwell Network 

Systems 

0799 NetHopper Client Router Rockwell 

Network Systems 

079A NetHopper Client Rockwell Network 

Systems 

079F Timbuktu Address Resolutions Farallon 

Computing 

07A0 Remote Access Server Meridian 

Technology Corp 

07A7 Backup Exec Job Queue Arcada 

Software 


07A8 Backup Exec Job Manager Arcada 

Software 

07A9 Backup Exec Job Service Arcada Software 

07AA Serverbench Server PC Weeks Labs 

07AB Serverbench Controller PC Weeks Labs 

07AC Service NW_Connect_PW_Server 

Flagstar 

07AF Site Meter Server Brightwork 

Development 

07B0 Proxy Agent Site Meter Brightwork 

Development 

07B3 Disc Disaster Recovery Software 

Scheduler Columbia Data Products 

07B4 Cubix Comm Server Cubix 

07B8 Identify Server Vendor for NMS Siemens- 

Nixdorf Information Sys 

07BA File Transfer Between LAN/Mainframe 

Proginet Corp 

07BF Database Server Comp Soft PLC 

07C0 Application Advertisement Comp Soft PLC 

07C1 Internet Apps on NW PCs Mango Systems 

Inc 

07CE Computer Supported Telephony Apps 

Global Communications 

07D1 Asynchronous Communication LAN 

Access Corp 

07D2 RM Auditor-Monitoring NW Usage 

Research Machines 

07D3 Generic NW Management Product 3Com 

Corp 

07D4 SCSI Mgmt Adaptec Inc 

07D9 Distribution Job Server Emotion Inc 

07DA Distribution Queue Emotion Inc 

07DB Distribution Feedback Job Server 

Emotion Inc 

07DC Voice Processing Server International 

Voice Exchange 

07DD Telephony Server Monitor International 

Voice Exchange 

07E0 Print Server Creative Controllers Inc 

07E1 “Box Router Supporting IP, IPX & 

Appletalk Furukawa Electric Co Ltd” 

07E2 TEL Serve Fujitsu NS Center 

07E3 Telemarketing Library Fujitsu NS Center 

07E4 Multi-Server Metering Brightwork 

Development 




07E6 Stress Magic Installation Utility Handler 

Net Magic Systems Inc 

07EC Financial Data Server Telemet America 

07ED ISDN Software Sharing of ISDN Boards in 

Network High Soft Tech Ingenieurburo 

07EE Comgate-Comm Gateway for IBM 

AS/400Comware International 

07F0 Zip Code Server Third Planet Software 

07F2 Norton Anti-virus Client Server Comm 

Symantec 

07F8 Software Entertainment Origin System Inc 

07F9 Remote Management of Remote Access 

Server Meridian Technology Corp 

07FC FTmanager - Controls NetWare Server 

Mitsubisi Denki Computer 

07FD SAP for Audittrack version 2.0 EG 

Software 

07FF Soft-tub Agent Proxy for Tri-com Adaptor 

3Com 

0801 SAP for Onguard EG Software 

080D IFONYFLOW for NetWare Fujitsu Social 

Science Lab 

080E Print Server for NW 3.x Ishigaki Computer 

System Corp 

0810 ELAN License Server Demo ELAN 

Computer Group 

0811 ELAN License Server ELAN Computer 

Group 

0813 “BVNCS Enterprise WAN LAN Support 

Group, Network Res” 

0814 Evergreen Windcap Management Agent 

Goodall Software Engineering 

0816 Policy Engine Emerald Systems 



0819 Policy Engine NCSU 

081A Policy Engine NCSU 

081B Policy Engine NCSU 

081C Policy Engine NCSU 

081D Off Line Copying On Technologies 

0827 Palindrome Service Broker Palindrome 

0829 LAN LENS Server Digital Equipment Corp 

082A LAN LENS Probe Digital Equipment Corp 

082B Job Queue Arcada Software 

082F DB Server 3.x Simultan AG 


0830 Pin64 Asahi Electronics Co Ltd 

0832 Appmeter 2-Licensing Product Funk 

Software 

0833 Communication Server Digital Products 

Inc 

0834 FTanalyzer Mitsubishi Electronic Corp 

0835 Instant Internet Performance Technology 

0836 High Speed Communication Server C 

Spec Corp 

0837 Atlanta/3 Print Server Kelly Computer 

Systems 

083D Application Server for NT Citrix Systems 

083E Custom Authentication/Load Balancing 

Univ of Pittsburgh 

0840 IP to IPX Gateway InterNet Junction 

0841 RDB/7000 Fujitsu Ltd LAN Technical Ctr 

084C ROUTE ONE and Related 2 Software 

Bug Inc 

084D 98 Server Manager NEC Corp 

0850 APLinkterm Mikasa System Engineering 

0853 APLinkgate Mikasa System Engineering 

0854 Automation Protocol Server Arcada 

Software 

0855 Tape ID Server Arcada Software 

0858 NetWare to Internet Gateway On 

Technology 

085A RDB/7000 Server for NetWare Fujitsu 

Limited 

085C DB-Express Fujitsu Kobe Engineering 

Limited 

085F Agent Router Proxy Arcada Software 

0860 Catalog Server Arcada Software 

0861 Inetix Gateway Micro Computer Systems 

0868 SoundByte Server Envision Telephony 

Inc 

0869 Peer-to-Peer File Redirection Alex Lloyd 

086F Vision 20 Multi-Functional Product Ricoh 

Corp 

0870 DPS-SV PFU Limited 

0876 “Audit Server LAN Support Group, 

Network Res” 

0877 “Alert Server LAN Support Group, 


0878 “NetSqueeze LAN Support Group, Network 

Res” 




0879 “EWAM LAN Support Group, Network 

Res” 

087A “Binding Server LAN Support Group, 


087B “Authentication Server LAN Support 

Group, Network Res” 

087D Modem Pool Server Attachmate 

087E Flora Manager for NetWare Hitachi Ltd 

Software Devt Ctr 

0886 Multi-user DOS Gold Concurrent Controls 

Inc 

088B SPX Telenet Agent Telebit 

0892 “UPS Control Software (UPSCON) 

Koubunsha, Ltd.” 

0897 Shared LAN Cache Measurement 

Techniques 

089A Clear it Dell Computer Corp 

089D Fax Server - Perfect Fit Newtech 

Systems 

089F Net Tune Pro License Hawknet Inc 

08A0 Net Tune Pro Alert Service Hawknet Inc 

08A1 “PowerVisor, PowerMonitor S Alfatech Inc” 

08A4 Inetix Gateway Admin Service Micro 

Computer Systems 

08A8 Rapport 112Shiva Corp 

08AA CPA Corp Print Accounting Blue Lance 

Network Info Sys 

08AC GroupEase for Windows Neighborhood 

Watch Ethosoft 

08AD CS-Care Network Management System 

Compu-Shack Prague 

08AE Firecall Team Development Corp 

08B0 NetWare Enhanced Integration for AS400 

IBM 

08B2 Overdrive Stampede Technologies Inc 

08B3 IIR AnswerSoft Inc 

08B4 Wanderlink Dialout Funk Software 

08B6 F-PROT Professional for NetWare 

Command Software Systems 

08B7 Web Management Coffee Computing 

08B8 CNA Distributed Traffic Monitor Chevin 

Software Engineering Ltd 

08B9 DS Gate Datastream International 

08BA VTD/X Gateway Micro-Matic Research 

08BB Salient Corp Salient Technologies Inc 


08BC IP Access American Internet Corporation 

08BE “Electronic Arts Games Electronic Arts, 

Inc” 

08BF IPX/IP Gateway Ukiah Software Solutions 

08C0 Norton Enterprise Framework (NEF) 

Symantec Corporation 

08C1 Xyratex VirtualSCSI NLM Xyratex 

08C2 8235 DIALs Switch for Token Ring IBM 

08C3 Stampede Overdrive Stampede 


08C4 Intergate Netsphere Communications 

Corp 

08C6 Piccolo Cornerstone Software 

08C8 ServerTrak Intrak Inc 

08C9 CDserve M4com Limited 

08CC Powerburst/Integrated Shiva Corp 

08CD SurfCONTROLJSB Computer Systems Ltd 

08CE “Trend Trak Intrak, Inc” 

08CF SurfCONTROLJSB Computer Systems Ltd 

08D0 Internet LANbridge Virtual Motion Inc 

08D1 Hyperdrive Paperwise 

08D2 Golf Scoring System Information & Display 

08D3 SurfCONTROLJSB Computer Systems Ltd 







08DA SurfCONTROLJSB Computer Systems Ltd 

08DB SurfCONTROLJSB Computer Systems Ltd 

08DC SurfCONTROLJSB Computer Systems Ltd 

08DD SurfCONTROLJSB Computer Systems Ltd 

08DE SurfCONTROLJSB Computer Systems Ltd 

08DF SurfCONTROLJSB Computer Systems 

Ltd` 

08E0 “HTTP-WebMail, ExpressIt!_2000 Infinite 

Technologies” 

08E1 “SMTP-WebMail, Infinite InterChange, 

ExpressIt!_2000 Infinite Technologies” 

08E2 “POP3-Infinite InterChange, 





08E3 “IMAP4-Infinite InterChange, 

ExpressIt!_2000Infinite Technologies” 

08E4 “NNTP-Infinite InterChange, 


08E5 MPR for ISDN AVM GMBH 

08E7 Procomm Remote Control Quarterdeck 

Corp 

08E8 fiNDS Netoria 

08E9 MyNet CKS Software Ltd 

08F1 Axis StorPoint Axis Communications 

08F4 Keylabs Automation Server Keylabs 

08F5 “LiftOff NewMoon Software, Inc” 

08F9 TSI Name Services Traveling Software 

Incorporated 

08FA ITA Agent Axent Technologies 

08FC CD FORCE Procom Technology 

08FD CallWare TAPIserve CallWare 

Technologies 

08FE Yoda Extended Systems Inc 

08FF Communications Servers for Windows NT 

IBM of Research Triangle 

0909 Dash Network Phone System Dash Inc. 

090A AutoXfer Platinum Technology 

090C Network Scan Server Axis Communication 

090D CD-Vision Ornetix 


090F Omniguard/ESM Manager Axent 

Technologies 

0910 Omniguard/ESM Agent Axent 

Technologies 

0915 Server Transfer System (STS) Prophet 

Systems Inc 

0916 KeyServer Sassafras Software Inc 

0918 Client/Server Database UMB Drecker 

GMBH 

091A SNA Gateway Product (GAP Protocol) 

Attachmate Corporation 

091B “Control, Configure, Administer TCP and 

SNA nets IBM Corporation of Raleigh” 

0C29 License Profile Integrity Software 

0C2A Virus File List Integrity Software 

0C2C Global License SAP Integrity Software 

0C31 License Report Definition / PlotterCalcomp 

238C Meeting Maker XP On Technology 

238D NLMOn Technology 

238E NLMOn Technology 

8202 NDPS Broker Agent Novell - Provo Corp 

HQ 

9620 License Profile Administrator Integrity SW 

FFFF All Types Novell - Provo Corp HQ 



Appendix I—Steps for Transitioning to 

Pure IP 

Note: In the following descriptions, pure IP means no IPX anywhere on the network and, 

therefore, no capability for running IPX-dependent applications, printing, services, and so forth. 

The assumption is that pure IP is the ultimate goal, in which case you should complete all steps in 

this task. When referring to other Novell documentation, keep in mind that not all Novell 

documentation defines pure IP this way. 

Dual Stacks 

Follow these steps to complete the transition to IP using the dual stacks option: 

1. Using the customer’s LAN/WAN diagrams, including locations of servers, clients, and 

routers, identify all network segments and the NetWare servers and clients on the segments. 

2. Using the customer’ LAN/WAN diagrams, design an SLP infrastructure (see Appendix D, 

SLP Design, for more information). 

3. Complete the upgrading/installing of your servers and clients using the IP and IPX option. 

• When using the dual stack option, it does not matter if you upgrade servers 

or clients first, nor do the clients and servers need to be upgraded at the 

same time. 

When all servers and clients have been upgraded to NetWare 5.1 using dual stacks, client to 

server communication is still available through either IP or IPX. Steps 4-7 start preparing 

you to get to pure IP and can be done simultaneously with step 3. Some aspects of these 

steps can be addressed in advance of step 3. 

4. Identify all IPX-based applications (refer to server applications and NLMs listed previously 

in Appendix A, IPX-Dependent Applications Worksheet.) Until you “turn off” IPX (step 8), 

your IPX-dependent applications will continue to run without problem. 

5. Upgrade, reconfigure, and eliminate identified IPX-dependent applications to use TCP/IP 

until all IPX-dependent applications have been removed. At the very least, consolidate local 

IPX dependencies as much as possible. 

6. Identify and then replace all IPX-dependent devices. Until you turn off IPX (step 8), your 

IPX-dependent devices will continue to function. Common examples of such devices are 

printers, CD-ROM towers, and fax servers. Printing will likely be the most pervasive of 

these. Remove this IPX dependency by migrating to an IP printing environment using NDPS 

or another IP printing solution, such as LPR. See the NDPS section in this Consultant Guide 

for more information. 

7. Eliminate SAP/RIP on the wire by modifying the configuration of the NetWare 5.1 servers 

to be IP-only (no CMD) by unbinding IPX from the LAN drivers. 

Hint: If an unknown IPX dependency is discovered at this point, re-bind IPX until the IPX 

dependency can be eliminated. 



8. Turn off IPX at the routers only after the following conditions have been met: 

• All NetWare servers have been upgraded/installed to NetWare 5.1 with 

both IP and IPX (step 3). 

• All NetWare clients have been upgraded/installed with both IP and IPX 

(step 3). 

• All IPX applications have been upgraded/replaced with IP versions (step 

5). 

• All printing has been migrated to IP (step 6). 

Note: IPX can be removed from the network when a segment has been deemed “IPX 

independent” instead of waiting for all IPX dependencies to be removed. 

9. Modify the configuration of the NetWare clients to be IP-only (no CMD) using ZENworks, 

ACU, or some other automated method to propagate the configuration changes. 

When you have completed these steps, you are at pure IP according to the definition given above. 



Using IP/CMD 

There are two options for performing the transition: 

• Pure IP via the MA-to-MA Protocol of CMD 

• Full CMD Implementation (using IP/CMD “islands” and the MA-to-MA Protocol) 

Pure IP Via the MA-to-MA Protocol of CMD 

Ethernet Segment 

IP/IPX Backbone 

Router Router 

IP only via the MA to MA Protocol IP only via the MA to MA Protocol 

IP and IPX 

NetWare Server with 

SCMD /bs /net=FFFFFFFC 


SCMD /bs /net=FFFFFFFC 


SCMD /bs /net=FFFFFFFD 


SCMD /bs /net=FFFFFFFD 

Dual Stack Clients 

PC PC PC PC 

Dual Stack Servers 

IP and IPX 


Dallas Sydney 

This diagram shows the connection of discontinuous IPX network segments 

using the MA to MA Protocol feature of CMD. 

Figure J1. MA-to-MA Protocol feature of CMD 

Migrating the backbone first is commonly referred to as “providing IP backbone support.” 

Essentially this means connecting two or more noncontiguous IPX network segments across an IP 

network backbone, as shown in the figure above. This method primarily uses the SCMD.nlm MAto-MA 

protocol, or “Backbone support” feature. 




routers, identify the backbone and the NetWare servers in the backbone. Also, identify all 

network segments (non-backbone) and the NetWare servers and clients in them. 

2. Determine and implement the SLP design. (See Appendix D, SLP Design.) 

3. Determine MA-to-MA Protocol Infrastructure design (see Appendix B, CMD Essentials). 

4. Prepare backbone for MA-to-MA protocol. 

a. Choose an appropriate NetWare 5.1 server on the backbone for an MA (ideally 

two will be used to provide fault tolerance). 

b. Load dual stack on the chosen server. 

c. Configure NLSP routing environment. 

d. Configure any necessary IPX filtering. 

e. Load SCMD with the appropriate CMD network number and configure any 

related parameters deemed necessary in the design. 

5. Enable MA-to-MA protocol between the hub sites and remote WAN link sites. 

a. Choose an appropriate NetWare 5.1 server on the backbone for an MA (ideally 

two will be used to provide fault tolerance). 

b. Load dual stack on the chosen server. 

c. Configure NLSP routing environment. 

d. Configure any necessary IPX filtering. 

e. Load SCMD with the appropriate CMD network number and configure any 


f. Remove the IPX routing function from the router’s WAN interface to the hub 

site so that the MA to MA link is the only IPX path to the corporate network. 

The resulting infrastructure removes native IPX traffic off of the WAN links and limits IPX traffic 

to the LAN where it is usually not a problem. 

Once the MA-to-MA infrastructure is in place, a dual stack approach is easily implemented at each 

of the sites now connected by the MA-to-MA protocol. 

Once all the IPX dependencies have been eliminated, the resulting infrastructure provides a 

complete pure IP solution as previously defined above. 



Full CMD Implementation Method (using IP/CMD “islands” and the MA-to-MA Protocol) 


IP/IPX Backbone 

Router Router 

IP and IPX IP and IPX 

IP and IPX 


SCMD /bs /net=ABF02A14 


SCMD /bs /net=ABF02A15 

IP/CMD Clients 

PC PC PC PC 

NetWare Servers with 

SCMD /net=ABF02A14 

NetWare Clients with 

CMD /net=ABF02A14 

IP/CMD Servers 

IP and IPX 


Dallas Sydney 

This diagram shows the CMD "island" concept. 

NetWare Clients with 

CMD /net=ABF02A15 

NetWare Servers with 

SCMD /net=ABF02A15 

Figure J2. Full CMD Implementation Method 


routers, identify the backbone and the NetWare servers in the backbone. Also, identify all 

network segments (non-backbone) and the NetWare servers and clients in them. 

2. Determine the SLP design. (See Appendix D, SLP Design.) 

3. Determine MA-to-MA protocol design for the backbone. (See Appendix B, CMD 

Essentials.) 

4. Determine CMD/MA “island” infrastructure design. (See Appendix B, CMD Essentials.) 

5. Determine implementation order, backbone first or CMD “island” at each WAN link site. If 

the backbone is first, follow the backbone migration strategy previously discussed. If the 

backbone is to be migrated after the CMD “islands,” a similar backbone migration strategy 

can be used. 



6. All users must have a dual stack NetWare 5.1 supported client before upgrading any server 

to NetWare 5.1 at the site. 

7. Create CMD “islands” on the network. For each planned island: 

a. Choose an appropriate NetWare 5.1 server at the site for an MA (ideally two 

will be used to provide fault tolerance). 

1. Load dual stack on the chosen server. 

2. Load SCMD with the unique CMD network number and configure any 


b. Upgrade remaining servers to NetWare 5.1 dual stack. 

c. Convert all clients from dual stack to CMD in the appropriate CMD network. 

d. Convert all non-MA servers from dual stack to CMD in the appropriate CMD 

network. 

8. Minimize IPX dependencies (applications and devices) identified in Appendix A through 

consolidation and eventual elimination. The most pervasive IPX dependency will likely be 

printing. Either NDPS or an LPR-based solution will suffice. (See the NDPS section in this 

Consultant Guide.) 

9. Remove CMD from all servers and clients as quickly as possible. This can be done as IPX 

dependencies are eliminated. 

10. Remove the IPX bindings from all MA servers as quickly as possible. This can be done as 

IPX dependencies are eliminated. 

Once all the IPX dependencies have been eliminated, the resulting infrastructure provides a 

complete pure IP solution as previously defined above. 



Appendix J—Lab Requirements for 

NetWare 5.1 Upgrade Testing 

Try to set up the lab to emulate the production environment as much as possible; this should make 

the pilot and implementation phases more successful. 

NDS Design 

Set up the tree the way it is or will be in the production environment, including the appropriate 

DS.NLM version. This does not have to include the production environment’s 

partitioning/replication scheme unless you have a way to simulate WAN links in the lab. 

Workstations 

Make sure you have the following: 

• Same hardware configuration as in the production environment 

• Same Novell client software as production workstations (especially if an ACU will be 

tested in the lab) 

• Same patch levels on the desktop operating system as production workstations 

Network and Server 

You should have a lab server running the same NetWare version(s) and patch levels as the servers 

that will be upgraded in the production environment. This server should be installed in a separate 

NDS tree, but the lab network should be physically connected to the production network to allow 

access to the production network, the Internet, etc. 

Office 2000 Integration (WebDAV) with NetWare 5.1 

Make sure you have the following: 

• NetWare 5.1 installed on the appropriate server(s) in the lab 

• Same Internet browser software as is used in production on the appropriate workstation(s) 

in the lab 

• Office 2000 installed on the appropriate workstation(s) in the lab 

In addition, if you are currently running the Netscape Web Server on a NetWare server that will be 

upgraded to NetWare 5.1 and support Office 2000 Integration, set this configuration up in the lab. 

Novell Distributed Print Services (NDPS) 

Emulate the printing environment that is in production so the transition to NDPS can be 

documented and tested. Be sure to include Novell’s print server solution (PSERVER.NLM) and 

any hardware print servers. 





Appendix K—What’s New (Included) in 

NetWare 5.1 

• NDS eDirectory (Enterprise Directory Services) = NDS 8 

• Support Pack 4 is automatically installed 

• Novell Distributed Print Services (NDPS) = superset of earlier, stand-alone NDPS 

product plus it includes IP printing (IPP) and LPR 

• Lightweight Directory Access Protocol (LDAP) version 3 = LDAP services for NDS 

eDirectory 

• Novell Internet Access Server (NIAS) 

• Storage Management Services (SMS) 

• Catalog Services 

• WAN Traffic Manager 

• Public Key Infrastructure Services (PKIS) 

• Cryptographic Infrastructure (NICI), version 1.3.1; NICIU0 (U.S. / Canada 128-bit), 

version 1.3.1 

• Security Authentication Services (SAS), which provides SSL support 

• Domain Name System (DNS) 

• Domain Host Control Protocol (DHCP) 

• NetWare Enterprise Web Server, version 3.5.1, which when installed includes: 

• Novell Directory Services Web Management 

• Novell SQL Connector 

• Virtual Directory Support 

• Servlet Gateway 2.0 

• NSP, NDODB (support for ASP, ADO programs) 

• Cluster Management (ability to manage groups of NetWare 5.1 servers running Web, 

News, Virtual and Multiple Web Server instances) 

• WebMon (Web Server Monitoring Utility) = NetWare Web Manager 

• WebDAV NSAPI Extension (for working with Microsoft Office 2000) 

• ~HomeDir Support (for working with Microsoft Office 2000) 

• Novell Script (for working with Microsoft Office 2000) 

• NetWare FTP Server 

• NetWare News Server 

• Novell Script (support for VBScript on the server) 

• NetWare Management Portal = web-based management of NetWare 5.1 

• NetWare Web Search Server 

• NetWare MultiMedia Server 

• Novell JVM 

• Client Software 

Third-party products include the following: 

• Nombas JavaScript (support for JavaScript on the server) 



• Halcyon InstantASP 

• IBM WebSphere Application Server– can be plugged into NetWare Enterprise Web 

Server 

• WebSphere NSAPI Plug-in– can be plugged into NetWare Enterprise Web Server 

• WebSphere Studio Standard Edition– can be plugged into NetWare Enterprise Web 

Server 

• Oracle 8i 

• WebDB (Oracle web extensions) 



Appendix L—Time Sync 

Table 1: What’s New in NetWare 5.1 

The design basics of laying out a time synchronization configuration are covered in the NDS 

Design BSO. However, two new features have been added in TIMESYNC.NLM 5.14 (which 

ships with Support Pack 4 in NetWare 5.1 and can be downloaded for use with NetWare 5.0): 

• Auto Disocvery over IP 

TIMESYNC.NLM 5.14 can now auto-discover time sources using SLP. The autodiscovery 

in IP works the same way as auto-discovery in IPX (which uses SAP). The 

two SET parameters which enables this feature are: 

• TIMESYNC SERVICE ADVERTISING=ON 

This paramemter enables TIMESYNC.NLM to advertise the “timesync.novell” 

service in SLP. This would also enable advertising over SAP if the server has the 

IPX stack enabled. 

• DIRECTORY TREE MODE=ON. 

This parameter confines auto-discovery to servers in the same NDS tree. 

• DNS Name Recognition 

TIMESYNC.NLM 5.14 now allows you to enter the DNS name of the NetWare server to 

contact for time instead of entering the IP address. The complete DNS name has to be 

entered including the domain name, e.g.: 

TIMESYNC TIME SOURCES = MYSERVER.PROVO.NOVELL.COM; 

If time is being taken from an NTP server, the DNS name needs to be followed by the 

port no 123, e.g.: 

TIMESYNC TIME SOURCES = NTPSERVER.PROVO.NOVELL.COM:123; 

Timesync internally resolves the name by doing a DNS lookup using the WinSock API’s 

exported by the WinSock NLMs. 



Table 2: Updated Time Sync FAQ for NetWare 5.1 

Frequently Asked Questions 

Novell's Recommendations on Time Synchronization 

Why is time synchronization necessary? 

Time synchronization ensures that all servers in a enterprise network report the same time. Such 

synchronization is important because applications and services such as Novell Directory Services (NDS) 

require time stamps to establish the order of events and record real-world time values. 

What is Novell's recommended approach to achieve time synchronization amongst NetWare servers? 

Novell recommends the use of TIMESYNC NLM to achieve time synchronization amongst NetWare 

servers. 

TIMESYNC NLM version 5.08 onwards has the capability to talk to other NTP sources and exchange time 

information with them. This allows a NetWare server running TIMESYNC NLM version 5.08 and above to 

synchronize time with an external time server (public NTP source) as well as allowing an NTP client to 

obtain time from a NetWare server. 

I need to synchronize my NetWare servers with an NTP time source. What is Novell's 

recommendation on this? 

TIMESYNC NLM has been enhanced to work with NTP time sources. This version of TIMESYNC NLM 

(ver 5.08 or later) is available on http://support.novell.com and will also be available on future support 

packs of NetWare 5. 

Please check http://www.support.novell.com for the latest downloadable TIMESYNC NLM. 

The latest downloadable version (as of 16 May 1999) is 5.09 from NW5SP2.EXE. 

What is the role of NTP NLM in time synchronization? 

Novell is committed to making Internet standards available on its platform. To achieve this, Novell has 

provided the NTP.NLM on NetWare 5 -- a service which implements the Network Time Protocol (NTP) 

definition described in RFC1305. In addition, Novell has enhanced its time synchronization service, 

TIMESYNC NLM, to inter-operate directly with NTP based time sources. 

TIMESYNC NLM has features such as: a comprehensive collection of set parameters, easy setup, auto 

discovery over IPX, interoperability with IPX and IP, and interoperability with NetWare 4.x and NetWare 

5. This makes the TIMESYNC NLM easy to use and manage. NTP.NLM met some specific customer needs 

when it was introduced, but is much less robust. 

Of the two implementations for synchronizing time in a NetWare environment, Novell recommends using 

TIMESYNC NLM. Wherever standard NTP interoperability is needed (to either serve time or take time from 

NTP time sources), TIMESYNC NLM's new features can be used. In effect, the NTP interoperability 

enhancement to TIMESYNC NLM eliminates the need to use NTP.NLM. 



Since NTP.NLM was introduced for the first time on NetWare 5 whereas TIMESYNC NLM has been in the 

field since NetWare 4.x and is now capable of providing NTP functionality on NetWare, it is best to use 

TIMESYNC NLM for all purposes of time synchronization. 

How is the working of TIMESYNC NLM different in NetWare 5 compared to NetWare 4.11? 

TIMESYNC NLM on NetWare 4.x only used IPX as its communication protocol. This also implies that it 

used SAP (Service Advertising Protocol) to advertise itself. This protocol relies on periodic network 

broadcasts to advertise services. 

TIMESYNC NLM in NetWare 5 has been enhanced to work over IP. It still retains its ability to work over 

IPX. This implies that if you have a network comprising both pure IP and pure IPX servers, time can flow 

from IPX to IP, and vice- versa, as long as there is at least one server that has both IP and IPX to provide 

translation between the two sides. You do not need the Migration Gateway solution for this purpose. 

SLP (Service Location Protocol) is used to advertise and locate services in an IP network. This is much less 

bandwidth intensive than SAP, but requires more administration. TIMESYNC NLM has not yet been 

enhanced to perform auto discovery of time servers over IP. This feature is expected to be available in 

Support Pack 3. 

Apart from these differences in protocols, the working of TIMESYNC NLM in NetWare 4.x and NetWare 5 

remains identical. There is no difference in the packet format, time synchronization algorithms, or for that 

matter, in anything. 

With NetWare 5 Support Pack 2, TIMESYNC NLM has the capability to serve as an NTP client as well as 

an NTP server as described in an answer to an earlier question. 

How do I achieve time synchronization in a mixed environment comprising platforms such as 

NetWare, Unix, Windows NT and mainframes? 

The only way to achieve time synchronization in a mixed environment is by using an open, standard 

protocol for time synchronization such as NTP. 

Unix boxes often have NTP built into the base OS. NTP implementations are also available for MS 

Windows NT and Apple Macintosh computers. Once you have identified an NTP implementation for your 

platform, and have deployed it on your platform, you are ready to talk to other NTP sources such as 

NetWare, Unix boxes, Internet time sources etc. 

How do I build fault tolerance into the time synchronization at my enterprise? 

Fault tolerance is achieved by configuring Timesync NLM with multiple time sources. This can be done by 

setting the "timesync time source" set parameter. Therefore, if one server cannot be contacted for any 

reason, the time can be got from other servers in the time source network. 

Multiple time sources can be entered by separating the two time sources with a semicolon. For example : 

SET TIMESYNC TIME SOURCES=1.2.3.4; 5.6.7.8; 

The semicolon (;) is used as a separator between two sources. 

TIMESYNC NLM and NTP 

What are the similarities and differences between TIMESYNC NLM and NTP? 

TIMESYNC NLM is a Novell proprietary time synchronization service available on NetWare. NTP is an 

Internet protocol specification (Internet RFC 1305), that needs to be implemented by vendors on platforms. 

NTP implementations are available on NetWare, NT, Mac, Unix, etc. 

TIMESYNC.NLM now provides Novell timesync protocol, NTP client and NTP server capability. 



NTP believes in the absolute concept of time i.e. the number of seconds elapsed since 1 January, 1900 

referred to as UTC (Universal Coordinated Time). All clocks need to synchronize with UTC time. 

However, TIMESYNC NLM has no such absolute concept of time. As long as all the computers in an 

intranet serve the same time, they are considered to be synchronized. The NetWare server may show a time 

different from the actual time of the day and still claim to be synchronized to the network provided all other 

NetWare servers are showing the same time. NTP has been designed for the Internet, whereas TIMESYNC 

NLM has been designed keeping an intranet in mind. 

TIMESYNC NLM is actually an adaptation of NTP. TIMESYNC NLM uses the same algorithms as NTP to 

account for network delay when obtaining time from a time source. However, NTP as a protocol is quite a 

heavyweight. When adapting TIMESYNC NLM, some features have been omitted to make it simple and 

practical. Some of the features in NTP that are not present in TIMESYNC NLM, are : 

• Leap second insertion: At regular intervals, clocks need to be compensated by inserting a leap 

second to the clock time. 

• Drift compensation: NTP keeps track of the pattern of changes to the clock, and over a period of 

time it computes a drift compensation factor that is applied to the clock. 

• Clock filtering and clock selection algorithms: NTP uses fairly complex algorithms to assess the 

reliability of each of the time sources in its list of time sources, and selects only those that are 

considered to be reliable. 

• Authentication: NTP can use authentication to ensure the integrity of the time source. TIMESYNC 

NLM, which has been designed for the intranet, trusts all time sources. 

• NTP is quite strict while considering a time source as a contender for obtaining time. If a time 

source is more than 1000 seconds (about 17 minutes) away from the local clock, NTP rejects the 

time source. The time source is labeled an "insane" time source. 

NTP never corrects time directly. The time polled is given as a feedback to the clock, so that the clock 

corrects its time. This is in contrast to TIMESYNC NLM, where the difference in time is gradually applied 

to the local clock. Typically, TIMESYNC NLM tries to correct time within one polling interval (the default 

value is 10 minutes). As a consequence of this approach, TIMESYNC NLM is able to synchronize time in a 

network much faster. NTP takes much longer to make this happen. 

The other differences between TIMESYNC NLM and NTP have to do with manageability and ease of setup. 

TIMESYNC NLM has several set parameters that enables administrators to control the working of 

TIMESYNC NLM to a great extent. In NTP, the only things that can be configured are the time servers. 

Almost nothing else is configurable. TIMESYNC NLM has features such as auto discovery over IPX, and 

uses multiple naming schemes ( SAP names , dotted NDS names and IP addresses can be entered into the 

time sources list) to identify time sources. These features make TIMESYNC NLM easier to setup and 

manage. 

TIMESYNC NLM over IP 

Does TIMESYNC NLM work over IP? 

Yes, TIMESYNC NLM in NetWare 5 works over IP. IP addresses can be specified in the time sources set 

parameter. For example : 

SET TIMESYNC TIME SOURCES=1.2.3.4; 

Does TIMESYNC NLM require CMD (Compatibility Mode Driver) to work over IP? 



TIMESYNC NLM in NetWare 5 works natively over IP. In other words, TIMESYNC NLM itself handles all 

IP related communication, and hence does not need CMD to work over IP. 

Why are questions such as: "Does TIMESYNC NLM work over IP?" still asked? 

Users and administrators are familiar and comfortable with the TIMESYNC NLM of NetWare 4.x. 

TIMESYNC NLM over 4.x used SAP for auto discovery; the first server in a tree was set to TIMESYNC 

NLM type SINGLE reference, and subsequent servers were set to SECONDARY by the installation 

process. The Secondary servers discovered the Single reference server using SAP. 

Because TIMESYNC NLM in NetWare 5 does not feature auto discovery over IP, each Secondary server 

needs to be explicitly configured to take time from the Single server. If this is not done, the Secondary 

server will report that it is out of sync, and hence gives the impression that "TIMESYNC NLM does not 

work over IP". 

Auto-discovery over IP will be available by NetWare 5 Support Pack 3 and will us the SLP (Service 

Location Protocol) over IP instead of SAP in IPX for auto-discovering time servers on the network. 

When will CMD be required? 

If a pure IP network needs to obtain time from a pure IPX server by giving a server name in the time 

sources set parameter, CMD is required to resolve the IPX address. 

Setting up TIMESYNC NLM over IP 

I am setting up a network of NetWare 5 servers. How do I set up time synchronization? 

Refer to the TIMESYNC NLM documentation to decide whether to use a Single - Secondary model, or a 

Reference - Primary - Secondary model. Single - Secondary models are good for small networks (30 

servers or less). Reference - Primary - Secondary models are suitable for larger networks, and for networks 

that span geographical separate regions. 

Each TIMESYNC NLM server, that needs to get time from another server, needs to be explicitly configured. 

For example, if server B needs to take time from Server A, server B needs to be set up as follows: 

From the console prompt, type: 

Set timesync configured sources = on 

Set timesync time sources = ; 

Run monitor NLM. Select the option Server Parameters -> Time. The parameter "Timesync configured 

sources" should be on. The IP address of Server A should be entered in the "Timesync time sources" field. 

Ensure that only dotted decimal IP addressed are entered. TIMESYNC NLM cannot understand DNS names. 

TIMESYNC NLM will be enhanced to understand DNS names in one of the support packs subsequent to 

Support Pack 3. 

Over IPX, I did not need to set up configured sources. Why do I have to do it now? 

Over IPX, TIMESYNC NLM could automatically discover other TIMESYNC NLM sources using SAP. 

TIMESYNC NLM over IP as yet does not have this capability. This functionality will be shipped in Support 

Pack 3 of NetWare 5. 

Can I use a server name in the configured sources? 

In an IP only setup, IP addresses are preferred. This will de done away with the ability to recognise DNS 

names in a future release of TIMESYNC NLM. 



Using TIMESYNC NLM with NTP time sources 

Can TIMESYNC NLM work with NTP time sources? 

Yes. TIMESYNC NLM, ver 5.08 or later, can work with NTP. This implies that TIMESYNC NLM can take 

time from an NTP time source, and can serve time to NTP clients. 

How do you setup a TIMESYNC NLM server to obtain time from an NTP time source? 

The configuration is similar to obtaining time from a normal TIMESYNC NLM time source. Set the value 

of the "Configured Source" set parameter to "on". Specify the IP address of the NTP time source in the 

"Time sources". However, an NTP time source needs to be differentiated from a TIMESYNC NLM time 

source by suffixing ":123" to the IP address. 123 has been chosen as it is the standard port for NTP. 

For example : 

SET TIMESYNC CONFIGURED SOURCES=ON 

SET TIMESYNC TIME SOURCES= 1.2.3.4:123; 

Where 1.2.3.4 is an NTP source. 

Can Timesync Reference and Timesync Single servers take time from an NTP time source? 

In a pure timesync scenario, Single and Reference servers read time from their local hardware clocks and 

serve it to time clients. They do not change their time. In other words, even if you have entered timesync 

time sources in Single or Reference server, they will not be used to change the time on the Single or 

Reference server. 

However, the NTP feature now enables Single and Reference servers to obtain time from NTP time 

sources. This means that the Single or Reference server, if setup with NTP sources in its time sources set 

parameter, would poll the NTP time source periodically, and adjust its local clock to synchronize with the 

NTP time source. 

Can Timesync Secondary and Timesync Primary servers take time from an NTP time source? 

Yes. All types of timesync servers can obtain time from an NTP time source. 

I have an existing network of NetWare servers. I want this network to take time from an NTP time 

source. How do I configure the network? 

Identify the "root" time servers in the network. If you have used a Single - Secondary model, the Single 

server is the root. If you have used the Reference - Primary - Secondary model, the Reference server and 

Primary servers together act as the root for serving time to the rest of the network. 

Update the root server(s) to get time from the NTP time source. The steps required to do this are explained 

above. 

As the entire network looks to the root time sources for time, we are ensuring that the entire network takes 

time from the NTP time source. 

How does TIMESYNC NLM provide time to an NTP client? 

TIMESYNC NLM, ver 5.08 or later, has the capability to provide time to an NTP client. This service is 

provided through UDP port 123. 

If you want your Unix machines to take time from a NetWare server, set up NTP on your Unix machines 

with the IP address of the NetWare server. This is done by entering the following statement in the NTP 

configuration file (usually /etc/ntp.conf) for the Unix system : 



Server 

Can TIMESYNC NLM obtain time from an Internet Time source? 

Internet time sources are typically public domain NTP time sources that are at Stratum 1 or 2. This being 

the case, setting up TIMESYNC NLM to obtain time from an Internet source is no different from setting it 

up to obtain time from an NTP time source within the intranet. The configuration steps to achieve this are 

identical. 

NTP uses the nomenclature of “stratum” to indicate the accuracy of a time source. The stratum ranges from 

1 to 16. 1 stands for source which is most accurate where as 16 stands for one which is “out of sync”. A 

NTP server at stratum “n+1” is one which accepts time from a NTP server at stratum “n”. Thus a server at a 

lower stratum indicates a server which is more accurate than one at a higher stratum. 

What are the limitations of this NTP enhancement to TIMESYNC NLM? 

This enhancement enables TIMESYNC NLM to understand NTP wire format. However, the NTP Protocol 

specification, contained in RFC 1305, mandates several features such as: leap second insertion and clock 

drift correction, that were considered heavy weight, and have, therefore, not been included in this 

enhancement. Thus, TIMESYNC NLM provides the NTP client and NTP server functionality while at the 

same time continues to be lightweight. 

Traffic generated by TIMESYNC NLM 

What are the different ways in which a TIMESYNC NLM server generates traffic? 

A TIMESYNC NLM server can generate the following kinds of traffic: advertisement traffic, discovery 

traffic, time request traffic and time response traffic. 

Advertisement traffic is generated when TIMESYNC NLM announces its service in the network. Over IPX, 

this is achieved through SAP. Over IP, TIMESYNC NLM does not advertise its service. Service 

Advertisement using SLP is expected in future releases . SAP traffic is typically generated once every 

minute. SLP advertisement is performed only when TIMESYNC NLM starts up, or when TIMESYNC NLM 

has to re-register when the SLP Service or the SLP Directory Agent goes down. Advertisement traffic over 

IP (when this feature is available in future releases) is expected to be significantly less than the SAP based 

advertisement traffic in IPX. 

Discovery traffic is generated when TIMESYNC NLM tries to discover the presence of other TIMESYNC 

NLM servers in the network. In IPX, this actually does not cause any traffic at all, as all NetWare servers 

contain a SAP cache, which can be queried to perform discovery. Over IP, SLP is used for discovery and 

hence, discovery implies that a call needs to be made to an SLP service agent. 

Time request traffic is generated when a server needs to take time from another server. This is periodic in 

nature, and in the steady state, its frequency is controlled by the "timesync polling interval" set parameter. 

The default value of this polling interval is 10 minutes. However, the frequency of polling is higher when a 

NetWare server starts up, or loses time synchronization for any reason. This implies that TIMESYNC NLM 

will generate much more traffic during server startup. 

Time response traffic is generated when a server receives a request for time from another server. In 

TIMESYNC NLM, time is provided only when it is requested by another server. In other words, a "pull" 

model is used to distribute time, and time is not "pushed" to other servers. Therefore, under normal 

circumstances time response traffic is equal to time request traffic, and hence follows the same periodicity. 

How do you control the traffic generated by TIMESYNC NLM? 

Set parameters of TIMESYNC NLM can be used to modify the traffic generated by TIMESYNC NLM to suit 

your requirements. The following table indicates the set parameters to be used to modify TIMESYNC NLM 

traffic: 



Timesync 

Traffic Type 

Advertisemen 

t 

Traffic 

Discovery 

Traffic 

Time request 

traffic 

Time 

response 

traffic 

Set Parameter to be 

used 

Timesync service 

advertising 

No set parameter 

can control this 

traffic. 

Timesync polling 

interval 

Timesync 

synchronization 

radius 

Time polling count 

Depends entirely on 

request traffic. All 

the set parameters 

that impact request 

traffic also impact 

response traffic. 

Notes of the use of the set 

parameter 

Set timesync service advertising = 

off eliminates all advertisement 

traffic. 

Increase in polling interval may 

reduce traffic. 

Increase in synchronization radius 

may reduce traffic. 

Timesync polls 3 times (the default 

value of this parameter). A reduced 

value will obviously reduce traffic. 

TIMESYNC NLM, Transport Protocols, and Firewalls 

Recommendations 

What transport protocols does TIMESYNC NLM use? What are the port numbers used? 

TIMESYNC NLM uses datagrams over IPX and IP. 

This server cannot be discovered using 

auto discovery; explicit configuration is 

needed to take time from this server. 

Recommended for IPX and not for IP. 

This traffic is quite minimal anyway. 

Polling interval may be increased up to 

60 minutes. Increasing the interval 

beyond 60 is not recommended. 

Synchronization radius depends on the 

kinds of applications that run on 

networks. Some may need more precise 

time than others. 

Polling count may be reduced to 2 in a 

LAN where the chance of packet loss is 

quite a loss. It is not prudent to reduce 

this value if timesync is operating 

across a WAN. 

In an IP environment, TIMESYNC NLM uses UDP on port 524. The request packet is dispatched from 524, 

but the response is received on a dynamic port. 

When communicating with an NTP time source, TIMESYNC NLM uses UDP port 123, which is the popular 

port for NTP. The request packet is dispatched from 123, and the response is also received at 123. 

Can TIMESYNC NLM work across a firewall? 

TIMESYNC NLM can work across a firewall only if the firewall permits incoming UDP traffic. 

If TIMESYNC NLM has to communicate with a TIMESYNC NLM source across the firewall, all incoming 

UDP traffic must be permitted. This is because the incoming TIMESYNC NLM packet is destined to be an 

dynamic port. 

If TIMESYNC NLM has to communicate with an NTP source across the firewall, incoming UDP traffic for 

UDP port 123 must be permitted. 

On the working of TIMESYNC NLM 

How do servers establish time synchronization in the first place? 



When a server starts up, TIMESYNC NLM on Secondary and Primary servers obtains time from Single / 

Reference servers as appropriate and sets the RTC (Real Time Clock) of the computer. The original time of 

the RTC is totally disregarded by this operation. Once the RTC of the Secondary / Primary server has been 

set, time synchronization should be established. 

For a Single or Reference server that does not point to a NTP time source, TIMESYNC NLM copies time 

from RTC into its buffer, and declares that time is synchronized. By definition, Single or Reference (that do 

not point to NTP time sources) will always be synchronized. 

If a Single or Reference server points to an NTP time source, its behavior is identical to that of Secondary 

or Primary servers. 

How and why can servers fall out of time synchronization? 

Assuming that servers have been synchronized for some time, exceptional conditions may cause them to 

fall out of time synchronization. Some of the conditions can be: 

• A clogged network 

• A faulty router 

• An NLM that hogs CPU cycles and prevents the software clock from being updated 

• An NLM that sets off clock interrupts so that the software clock does not get updated 

What are the differences between a Primary and Secondary server when obtaining time from 

multiple sources? 

A Secondary server may be setup to have multiple time sources. However, it will contact only one time 

source. It will attempt to contact the next time source only if it fails to obtain a response from the first time 

source. After obtaining time from the time source, a Secondary server will adjust its clock to approach the 

time obtained. However, in this process, the Secondary server does not give any importance to its own 

clock. For example, if a Secondary server has the time 10:03, and the time obtained from the Single server 

is 10:04, the difference of 60 seconds is made up by accelerating the clock gradually over a polling interval. 

If the polling interval is 600 seconds, an adjustment of 60 / 600 or 1 second for every 10 seconds elapsed is 

made. 

This gradual adjustment of time is very important. Sudden changes of time can throw many distributed 

applications out of gear. 

A Primary server contacts all its time sources, and not just one of them (as the Secondary server does). This 

is done during every polling interval. The Primary server then calculates the average of all the values. Time 

from Reference servers is given more importance than the time obtained from Primary Servers. This is 

done by assigning a weight of 16 to the time from the Reference server and a weight of 1 to that obtained 

from other Primary servers. The difference in time is gradually applied to the RTC of the server. 

Should the Single or Reference server be a NetWare 4.11 or a NetWare 5 server? 

As mentioned before, apart from protocol differences, there are no fundamental differences between the 

working of TIMESYNC NLM between NetWare 4.11 and NetWare 5. At a fundamental level, it does not 

matter whether the Single server is on a NetWare 4.11 or a NetWare 5 server. Actually, a TIMESYNC NLM 

server has no way of making out if the time is from a NetWare 4.11 or from NetWare 5 (the packet formats 

are identical). 

However, other considerations may favor one or the other alternative. If you need to set up the Single 

server to obtain time from an NTP time source, this is possible only in NetWare 5. 



DNS Name Recognition feature and AutoDiscovery over IP in 

Timesync.NLM 

DNS Name recognition feature has now been added to Timesync in ver 5.14 and will ship with NetWare 

Support Pack 4. So now a user can enter the DNS name of the NetWare server to contact for time instead of 

entering the IP address. The complete DNS name has to be entered including the domain name. 

e.g. Timesync Time sources= MYSERVER.PROVO.NOVELL.COM; 

If time is being taken from an NTP server, the DNS name need to be followed by the port no 123. 

e.g. Timesync Time Sources = NTPSERVER.PROVO.NOVELL.COM:123; 

Timesync internally resolves the name by doing a DNS lookup using the Winsock APIS exported by the 

winsock nlms. DNS feature works fine with NetWare 5 with Support Pack 3 installed on it. It may not work 

without SP3 as the winsock nlms had to be fixed for SP3. 

Timesync can also now auto discover time sources over IP. This is also a feature that is being rolled out 

with Timesync ver 5.14. Timesync uses SLP in IP for autodiscovery of time sources. The autodiscovery in 

IP works the same way as autodiscovery in IPX which uses SAP. The set parameter which would enable 

this feature is TIMESYNC SERVICE ADVERTISING and DIRECTORY TREE MODE. Both of these 

need to be set ON. 

TIMESYNC SERVICE ADVERTISNG set to ON enables Timesync to advertise the “timesync.novell” 

service in SLP. This would also enable advertiing over SAP if the server has the IPX stack enabled. The 

DIRECTORY TREE MODE set to ON confines autodiscovery to servers in the same NDS tree. 

TIMESYNC.NLM Debug Switches 

To open up the timesync debug screen , one needs to do “set timesync debug=7” at the server console. At 

present there is only one Timsync debug switch enabled. 

Timesync debug screen gives info like the time server type of thie server , which server was contacted for 

time and its time server type, at what time did the polling take place, what was the time offset discovered 

and if time is synchronized or not. This information is printed at each polling interval. 



Appendix M—NetWare/IP 

NetWare/IP Considerations for Protocol Migration 

Whenever NetWare/IP is being used, the migration mechanisms are somewhat different. As with 

any protocol migration, improper planning and implementation can lead to significant loss of 

service. Since NetWare/IP implementations can vary widely, this document will limit the scope to 

the simplest examples of NetWare/IP deployments. It should be noted that Novell does not 

support NetWare/IP on NetWare 5.1 at the time of this writing. If NetWare/IP becomes a 

NetWare 5.1 supported product, a future version of this methodology will incorporate this change. 

In the meantime, complex and/or cumbersome migration mechanisms may be required. Such a 

migration is made possible by the ability to run SCMD.NLM on a NetWare 4.11/4.2 server. 

Scenario 1: NetWare/IP on the WAN (IPX on the LAN) 

This NetWare/IP “backbone” deployment strategy is very common since it addresses the most 

significant consequences of IPX SAP/RIP for an enterprise. This case can also be the simplest to 

address. If the NetWare/IP infrastructure can be left in place and unchanged until all IPX 

dependencies are removed, the migration essentially becomes a dual stack approach. As noted 

throughout this document, a dual stack approach is always the preferred migration mechanism. If 

this is not possible, the NetWare/IP “backbone” will need to be replaced with a combination of a 

CMD “island” and MA to MA protocol solution. This approach is basically the CMD island 

approach previously discussed. 

Scenario 2: NetWare/IP on the WAN and the LAN (NetWare/IP clients and servers) 

Since NetWare/IP is not supported on NetWare 5.1 at this time, maintaining access to services 

between these two environments is more cumbersome since a dual stack approach is not possible. 

Instead, the use of CMD and therefore SLP is required. 

Scenario 3: Mixed NetWare/IP on WAN and LAN 

Essentially this type of environment will require a combination of mechanisms. 

The migration steps for these three scenarios are presented in the following Novell documents: 

• Migration Strategies for Upgrading IPX and NetWare/IP Networks to Pure IP, June 1999 

• NWIPCMD.HTM (included in the NW 4.11 Support Pack—IWSP6a.exe at the time of 

writing) 

• IP AND NetWare/IP (NWIP), TID 2944678 

In any of these cases, current problems due to an unhealthy NetWare/IP environment can easily be 

exacerbated by attempting to use pure IP to solve these problems. In all protocol migration 

projects, a very careful and methodical migration is recommended. An unhealthy NetWare/IP 

domain requires the utmost care and planning. The most prudent course of action would be to 

address the current NetWare/IP issues to attain a stable NetWare/IP domain before proceeding 

with a NetWare 5.1 protocol migration. 



Appendix N—NetWare Management 

Portal 

Prerequisites 

• NetWare 5.1+ 

• Browser requirements are Netscape 4.5+ or IE 5.0+. 

• TCP/IP port 8008 is used 

Setup 

• PORTAL.NLM is automatically loaded during NetWare 5.1 installation; no setup or 

configuration is required. 

• By default, Portal is installed with SSL enabled. SSL can be disabled for Portal by 

commenting out this section in the server’s AUTOEXEC.NCF: 

# 

### To prevent Portal from using SSL, comment out the following lines as shown: 

# Load httpstk.nlm/SSL /keyfile:”SSL Certificate IP” 

# 

Without SSL on your Portal server, information passed between the browser and the 

server is not secure. For this reason, you should probably not disable SSL on a 

production server. 

Overview of NetWare Management Portal 

Novell’s direction in network management is web-based, and the NetWare Management Portal is 

Novell’s first generation of web-based management tools. Wherever there is a web browser 

running on a client workstation, you can use Management Portal to manage NetWare servers. 

Management Portal supports traditional management services or features, which allow you to 

accomplish the following tasks: 

• Mounting and dismounting volumes 

• Accessing files on volumes and DOS partitions 

• Managing server connections 

• Configuring SET parameters 

• Monitoring system resources 

• Viewing server console screens 

• Downing, restarting, or resetting a server 

• Browsing the NDS tree and viewing partitions 

Management Portal provides some new tools. These tools address a server’s health and resources 

by doing the following tasks: 

• Checking the general server health status 

• Viewing the status of all loaded modules, including memory usages for each NLM 

• Viewing information about all hardware adapters, hardware resources and processor data 



• Monitoring the health of many server processes and resources. 

Using Portal 

Running Portal from your client browser is simple: 

• Open your web browser 

• In the address field enter the Portal server’s IP address, e.g.: http://137.65.123.11 

• Click Login (admin or admin-equivalence is required to access all of the features) 

• If you have NetWare Enterprise WebServer installed on your server, you will have to add 

the port number 8008 to the end of the IP address for your Portal server. So, using the 

example above, the new address field will look like this: http://137.65.123.11:8008 

Online help is provided and it is good. Detailed information in Help is provided for every section, 

feature and function. Also, you will see a question mark (?) icon. Clicking on that icon will give 

you component-specific help for each line item on the Server Health page. Nice feature. 

Portal Considerations 

• The reset button does a warm boot on the server, so if autoexec.bat does not include the 

command to load the server you will lose access to the server. The browser will show a 

traffic light that is dark when this happens. When you regain communication, the traffic 

light will display the server’s status. 

• Use the delete function with caution since the Admin user can delete any object including 

itself. 

• In Monitor, you can view connection information. Portal has the same information, 

however, .Portal’s Connection Information screen includes all information about 

Connection 0. Another difference between Portal and Monitor is that Portal does not use 

the asterisk character to mark connections that count against the server’s connection 

limit. 

• Server Up Time (days:hours:minutes:seconds) does not tick; the page must be reloaded. 

• Server Health Status is reported by the traffic light and is updated every five seconds, but 

the graphic will only refresh if the status has changed. 

• Multi-Server Health. Depending on how much memory is loaded on the client 

workstation and the Web browser you are using, if you view more than 40 servers 

simultaneously, you may experience unpredictable results, like shut down the browser. 

Brief Description of Portal’s Management Features 

• Server Information: This header section on the main page, contains Server’s name, 

NetWare version, version and date of SEVER.EXE, version and date of PORTAL.NLM 

and the Server’s total up time. 

• Server Health Status:Green means health is good, Yellow means something is suspect 

and Red means bad or trouble. 

• Login/Logout: If you are not logged in, click the login button. If you are logged in, on the 

front page, you will see a status saying that you are logged in. If you are logged out, you 

will get a “Greetings Username” just below the traffic light. Unless all your browser 

windows are closed, Portal session will remain open, and you do not have to log in again. 

• Main Page Configuration: This is where you adjust port numbers, start and stop HTTP 

log files, toggle settings for SET parameters and hidden console commands. Also, you 

can unload/reload PORTAL.NLM, setup IP filtering to control access to Portal. 



• Support Connection Link:There is a Novell logo, top right corner that if pressed, will take 

you to Support Connection Web page. You can download server patch kits or upgrades 

by using this feature. 

• Home Button: Every page has this and clicking this takes you to the Main page. 

• Customizing Main Page:It is possible to customize Portal’s home page. Create a file 

using text, graphics, custom links and save it as PRTLANNC.HTM and save it in the 

SYS:\LOGIN directory, this is the Portal server’s directory. Any information that is 

included in this file will appear on the bottom of the main page. 

• Volumes Management Tab: List of server’s volumes, access to DOS partitions, attributes 

and mount status of volumes, manage and view server’s file system. From this page, you 

also have access to the following: 

• NSS Volumes: Basic file access, but you cannot change the volume attributes. 

• File Access Rights: Via NDS login, you can copy files to and from any given directory, 

as well as access. With Admin rights, you have access to the DOS partition. If SHARE is 

not loaded in DOS, and you select the Shareable attribute on a DOS file, it will not work. 

SHARE has to be loaded. 

• Browsing the File System: View file system on DOS partitions, Volumes. Browse 

directories, files, view, change attributes of files, directories and volumes. To move 

down, click the volume, drive or whatever. To move up, click the double dots. 

• File/Directory Information: Click the Info icon for a file, directory will show creation 

date, rights, file space useage. You can delete, rename a directory or file. You can also 

create new subdirectories, but you can only do so on NetWare volumes. 

• Viewing Files: Browsers setup to look at extensions, Portal will allow you to click and 

view any file. 

• File Upload: Portal allows you to copy a file at a time (next release will allow for 

multiple selects) from any mapped drive to the directory that you are in. You have to 

have the Write right for this to occur. 

• Mount/Dismount: Admin rights given, you can dismount, mount volumes. You are asked 

to confirm your choice before it is actually dismounted. By dismounting SYS volume, 

icons in Portal (they reside in SYS:\LOGIN) will not display. Mount SYS and reload the 

page, icons reappear. 

• Connection Management: Here you can view current connections, clear specific 

connections, clear all not logged in, and broadcast to users. And for specific users, you 

can view the login time, connection number, network address, login status, files in use, 

etc. 

• Memory Management: View server memory in pie charts, statistics, also links to Swap 

file, Virtual Memory information, and Memory usage, NLM’s. 

• System Resources: Lists all resource tags in use at any given time. 

• System Statistics: Network Management information, Kernal information, Media 

Manager statistical information and LSL statistic information. 

• Screens: View all current console screens. You get simple command line input with 32 

characters supported. Load/Unload a module. 

• Down Server Options: Admin’s can down, restart, reset the server. You are asked to 

confirm your selection. 

• Module List: List of all NLM’s currently loaded in servers memory, you can sort , via the 

column heading, by: module name, memory usage, code/data size. Click the memory 

value, and you will be displayed information about that NLM. You can load an NLM 

from here as well. You will see it as an entry field. 

• Registry: Read only of NetWare Registry tree structure. 

• Winsock 2.0 Management: Detailed information about Winsock Sockets and 

Applications, API are shown here. 



• Tree Walker: View NDS tree, get information and details about individual objects. NDS 

Partition Page provides info about NDS partitions on the server. 

• Remote Access Tab: Access other servers that have Portal loaded on them. 

PORTAL.NLM has to be loaded on those servers. If you do an upgrade from NW 4 or 5 

to 5.1, PORTAL.NLM is automatically loaded. 

• Suppose you have “Non-Portal” servers in your tree, you can still get to them, by clicking 

NetWare Servers. That will load an additional module called NWRSA and then list other 

non-Portal servers reported by SLP in the current server’s tree. You can’t do any health 

monitoring or other admin stuff. When you see a question mark, next to the server, 

Portal is checking its availability. The question mark will change to a server icon if it is in 

the current tree. The question mark will be removed, if it is not found in the current tree. 

• A simple question to ask our customers: Do you want to use Portal as your Network 

Management Tool? If the answer is yes, then make sure tree merges are done first, so 

that you can take advantage of Portal excellent management tools. 

• Hardware Adapters: Storage and network adapters are listed here, you can get detailed 

views of information by clicking on the LAN adapters. 

• Processor Information: Status of processors available on the server. On multi processor 

boxes, you can start/stop the processor. You can not stop Processor 0, for obvious 

reasons. 

• Hardware Resources: Shared memory, slots, ports, DMA, interrupts are shown here. 

• PCI Device Information: Detail information on each PCI device listed by HIN (hardware 

instance number) and give links to additional details. 

• Server Health Page: This page allows you to view numerous options. Each of the items 

are listed below. 

• DS Thread usage 

• Work to do response time 

• Allocated server processes 

• Available server processes 

• Abend/debug information 

• CPU Utilization 

• Connection usage 

• Available Memory 

• Virtual Memory Performance 

• Cache Performance 

• DS Status-loaded or open 

• Packet receive buffers 

• Available ECB’s 

• LAN traffic 

• Available disk space 

• Available directory entries 

• Disk throughput 



Appendix O—Template Preliminary 

Report 

The preliminary meeting for the NetWare 5.1 Upgrade project was held on _________ . The purpose of this meeting was to kick off the project, set expectations, and gather the 

required information so that this project can stay within its timelines. 

In attendance at this meeting were: 

• ______ 

• ______ 

Team Members / Roles 

The following are the consulting team members and their roles in this project: 

• _______ 

• _______ 

The following are __________’s team members and their roles in this project: 

• _______ 

• _______ 

Project Goals 

The following are _________’s expectations: 

• Upgrade ___ Netware 3.x (be specific with versions) to NetWare 5.1 

• Upgrade ___ Netware 4.x (be specific with versions) to NetWare 5.1 

• Upgrade ___ Netware 5.0 servers to NetWare 5.1 

• Design and implement Novell Distributed Print Services (NDPS) 

• Office 2000 Integration (WebDAV) with NetWare 5.1 

• Upgrade ___ client workstations to the latest NetWare 5.1 client software 

To-Do: Include the appropriate portions from the Statement of Work and anything “new” 

uncovered from the preliminary meeting. In this section, you want to clearly state to the customer 

what work is expected and will be delivered. 

Information Still Needed 

You still requires the following documentation and information: 

• LAN/WAN Diagrams 

• TCP/IP Infrastructure Diagrams (DNS, DHCP) 

• NDS Design Documents 

To-Do: Document any missing documentation not collected during the preliminary meeting and 

who is responsible for obtaining this information. 



If not applicable, remove this section and you can change it to a section stating that the following 

information was collected and will be used to upgrade to NetWare 5.1. 

Lab Requirements 

The following are the necessary lab requirements to ensure a successful engagement. Failure to 

have an adequate lab can result in project delays or even project failures. 

To-Do: Include a completed (and updated for your specific project) Appendix J here. 

Critical Success Factors 

The following are ___________’s citical success factors for this engagement: 

To-Do: Include success factors here (from the problem analysis document and/or the preliminary 

meeting). 

Additional NetWare 5.1 Software 

The following software will be used on NetWare 5.1 servers: 

• _______ 

• _______ 

To-Do: From the preliminary meeting. 

eDirectory or other version of NDS 

________ will be implementing: 

• eDirectory (NDS 8) 

• Legacy NDS (NDS 7) 


Licensing Scheme 

________ is a customer for NetWare 5.1. 


Project Milestones / Timeframe 

The following are _________’s milestones for this project: 

To-Do: For example, Phase 1 = having xxx number of servers in the xxx office upgraded to 

NetWare 5.1 by . Phase 2 = having NDPS installed in the xxx office by . 

Next Steps 

Now that the preliminary meeting has been completed, the next steps in this project for are: 

• _______ 



• _______ 

To-Do: If you are following the consultant guide, you can state that the next step is to perform a 

technical assessment and impact study, the goal being to get the NetWare production environment 

to a baseline system before upgrading to NetWare 5.1. Also note that the completed PFC is 

needed and will be used for this step. 

Sign-Off 

Lead Consultant Signature: ___________________________ Date: ______________ 

Customer Signature: ______________________________________ Date: ______________ 



Appendix P—Template Technical 

Assessment and Impact Study Report 

Many customer projects have suffered limited success or even failure as a result of their not 

properly assessing the current environment prior to upgrading to NetWare 5.1. Problems can be 

minimized greatly by careful review of the current environment. To minimize this risk, we 

conducted a technical assessment of your current environment to determine if it is capable of 

supporting NetWare 5.1. 

The technical assessment compared your current NetWare environment with the NetWare 5.1 

minimum recommendations (or Novell Customer Services’ real-world recommendations) to 

identify deficiencies. 

The impact study here documents the impact of each deficiency found, as it pertains to 

implementing Netware 5.1. 

We strongly recommends that all of these deficiences be resolved before any production 

upgrade to NetWare 5.1. The solution design we develop for you will assume that your 

production environment is (or will be) at a baseline system. 

• Deficiencies found in the technical assessment were: 

• Solutions for resolving these deficiencies are: 

Note: You can state that further testing needs to be done in the lab. 

• Possible problems if these deficiencies are not resolved before the NetWare 5.1 upgrade 

include: 

Note: You can state that further testing needs to be done in the lab. 

• Persons responsible for resolving these deficiencies are: 

Sign-Off 

Lead Consultant Signature: _________________________________ Date: ______________ 

Customer Signature: ______________________________________ Date: ______________

NetWare 5.1 Upgrade Consulting Guide - ITwelzel.biz

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?