Netware 5.1 Upgrade

NOVELL PARTNER CONSULTING SERVICE OFFERINGS

NOVELL PARTNERNET CONFIDENTIAL CONSULTANT GUIDE NetWare 5.1 Upgrade

¨ 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

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:

• Preliminary Report • Technical Assessment / Impact Study Report • Design Report • Closing (Final) Report Terminology

• 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

Skill Set

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)

Page 4 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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:

• 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

Purpose

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.

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

Page 6 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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

Page 7 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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

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

Reference Material

Books • 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

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

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.

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:

SP1 SP3 SP4 SP5 P3 SP2 Initiate Perform a Develop Validate Implement Validated System Solution Engagement Technical Solution and Test and Test Design and Development Assessment and Design System Design Pilot Systems Deployment Plan Impact Study

(Project leader) Perform technical Develop and Instruct customer Prepare draft Conduct initial assessment and document detailed to assemble test deployment plan engagement meeting impact study solution designs environment with customer Identify pilot sites Develop technical Develop and Build prototype (Consultant) Prepare assessment and document test and preliminary report impact study report acceptance plans Develop system Test prototype implementation plans

(Consultant) Deliver Deliver Deliver designs and preliminary report technical assessment plans to customer Modify and retest Implement and test to customer and impact study prototype pilot systems report to customer

Document final Modify and retest system design pilot systems

Prepare and present Prepare and deliver revised designs and final design and validation results validation results

(Conditional) CBM prepares and negotiates WOA for pilot implementation

Figure 1. Solution Development

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.

NetWare 5.1 Upgrade—Solution Development

Subprocess 1—Start the Project

Key Inputs Key Outputs Personnel Personnel • Lead consultant (if one has been assigned) • Lead consultant • All consulting team members • Customer contacts • Your project manager (optional)

Outputs / Deliverables Resources / Tools • Preliminary report

Data / Reports Data / Reports • Preliminary report • Signed statement of work • Weekly status reports • Completed preflight checklist • Summary of problem analysis Customer Sign-Off • Summary of feasibility study • Project manager • Preliminary report • Fax Copy to project manager

Task Summary 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

Page 13 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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)

Page 14 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.

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

NetWare 5.1 Upgrade— Solution Development

Subprocess 2—Perform a Technical Assessment and Impact Study

Key Inputs Key Outputs Personnel Personnel • Lead consultant • Lead consultant • Consulting team members • Customer contacts/interfaces

Resources / Tools Outputs / Deliverables • Technical assessment and impact study report

Data / Reports Data / Reports • Signed statement of work • Weekly status reports • Problem analysis • Technical assessment and impact study report • Feasibility study • Preliminary report

Task Summary 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.

Page 16 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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

OS Minimum Version or Comments Patch Level

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 Recommend minimum of 16MB RAM. higher

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 Recommend minimum of 24MB RAM. higher

Windows 2000 Base product

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.

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 X Limited No support for Pure IP v2.71 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.

• 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 • Cannot work with pure IP. • Upgrade to latest client version. the latest level. • Cannot take full advantage of NDS (multi-tree, ZEN, NDPS, • Continue using same version etc.). (and sacrifice NDS and/or pure IP functionality). • May not be able to connect to server (if upgrading).

• Microsoft Client for NetWare • Bindery support only. • Upgrade to Novell Client Networks is being used. software. • Run NetWare 5.1 with Bindery Services for Microsoft client workstations.

• OS/2 workstations connected • OS/2 workstations will not • Maintain IPX on NetWare to NetWare servers. connect to pure IP servers that require OS/2 NetWare 5.1 servers. connectivity.

• UNIX (non-NFS) workstations • UNIX workstations will not • Maintain IPX on servers that connect to NetWare servers. connect to pure IP require UNIX connectivity. NetWare 5.1 servers. • Run NFS 5 on NetWare 5.1 servers, and NFS on UNIX workstations.

• Macintosh workstations and • Macintosh computers cannot • Obtain current client/file servers run AppleTalk and connect to the network system from Prosoft connect to NetWare servers. (NetWare 5.1 does not include (www.prosofteng.com). Mac client). • Leave AppleTalk clients • Macintosh computers cannot connected to current server see the NetWare volumes and version. (NetWare 5.1does not include Mac file system).

Activity 2b—Assess Client Internet Browsers

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

Page 20 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. Note: Internet Explorer 4.0 and Netscape’s browsers have limited functionality with the WebDAV protocol and they do not support Web Folders.

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 4.10+ 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 3.12+ with the latest support pack • NetWare 4.10+ with the latest support pack • 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.

Possible Issues Possible Results or Impacts Options

• Patches are not at most • No guaranteed stability. • Apply latest patches (this is current levels. recommended). • Cannot take advantage of certain functionality and • Do nothing (and sacrifice enhancements. functionality). • Inability to leverage technical support (problem resolution).

Step 2—Assess CLIB Patch Level 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.

Page 22 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Possible Issues Possible Results or Impacts Options

• The server does not meet • Cannot upgrade this particular • Upgrade the CPU to recommended CPU server to next OS version. recommended level. requirements. • Obtain a new server. • Consider consolidation of this server with other servers. • Leave the server at its current NetWare version.

Step 6—Assess Server Operating System RAM NetWare 5.1 requires a base minimum of 128MB, which includes RAM for the standard NetWare products.

Possible Issues Possible Results or Impacts Options

• Server does not have the • Server may not run • Purchase more RAM for minimum 128MB of RAM. NetWare 5.1. selected server (if capable). • Cannot upgrade this particular • Consider consolidation of this server due to RAM limitations. server with another one. • Get a new server. • Leave server at the current NetWare version.

Step 7—Assess Other RAM Requirements 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

Possible Issues Possible Results or Impacts Options

Page 23 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • Server does not meet RAM • Server may not run specific • Purchase more RAM for requirements for applications application. server. that will be running on it. • Move application to another server. • Get a new server. • Consider consolidation with another server that has enough RAM.

• Server is going to be a • May not complete NDS • Upgrade to at least 128 MB of dedicated DS replica server. synchronization within the RAM (recommended for a recommended 30-minute dedicated DS replica server. period.

Step 8—Assess CD-ROM The following CD-ROM requirements must be met:

• 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).

Possible Issues Possible Results or Impacts Options

• Server does not have a VGA • Cannot use GUI install. • Use another NetWare 5.1 monitor. installation method besides • Cannot use ConsoleOne. the GUI installation. • Do all NetWare management from a workstation. • Get 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.

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

Possible Issues Possible Results or Impacts Options

• Server does not have mouse • Cannot use GUI install • Free up the IRQ (reconfigure capability (IRQ or port efficiently. other device to another IRQ if available). availability). • Potential delay in upgrading this particular server to • Obtain a mouse for this server NetWare 5.1. (use a COM port or mouse port as applicable).

Step 11— NetWare 5 DOS Partition setup suggestions: 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

CONFIG.SYS AUTOEXEC.BAT TIMEOUT = 10 @echo off Echo = 1) NetWare Server prompt $p$g Echo = 2) Plain DOS goto %config% Echo = 3) DOS Workstation Client goto end Echo = 4) DOS Workstation CD Echo = Please select option 1, 2, 3, or :NWSERVER 4? CD\NWSERVER Switch NWSERVER, DOS, CLIENT, CD SERVER Exit Goto end

:NWSERVER :CLIENT set config=NWSERVER CD\NOVELL\CLIENT32 Files=30 STARTNET Buffers=30 Goto end Return :CD :DOS C:\DOS\MSCDEX /D:MSCD0001 /L:D Set config=DOS Files=30 :DOS Buffers=30 Return :END

: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

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.

Possible Issues Possible Results or Impacts Options

• LAN Driver is not capable of • Can’t upgrade to NetWare 5.1. • Upgrade LAN driver for NIC to appropriate ODI specification. ODI spec 3.30. • Could cause corrupted packets as other servers get • Replace network interface upgraded. card. • Project delays.

Step 2—Assess Server LAN Adapter (Address Setting) Network interface cards should not be set at memory address A000.

Possible Issues Possible Results or Impacts Options

• Server NIC address set to • This address will conflict with • Modify NIC settings. A000. NetWare 5.1’s graphical • Replace NIC. interface. • • Do not upgrade this server to Cannot upgrade this server to NetWare 5.1. NetWare 5.1.

Step 3—Assess Server LAN Adapter (Frame Types) All servers must be running the same frame format to communicate.

Possible Issues Possible Results or Impacts Options

• NIC is running 802.3 (potential • Cisco IOS version could cause • Standardize on 802.2. issue with older Cisco IOS NDS corruption. • Upgrade Cisco IOS. versions).

Step 4—Assess NetWare TCP/IP Stack An IP stack is needed in the following situations:

Possible Issues Possible Results or Impacts Options

• No IP stack. • Cannot use accelerated • Implement IP stack on upgrade. servers. • Cannot get to pure IP. • Do without IP.

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/

Possible Issues Possible Results or Impacts Options

• HAM and CDM drivers are not • Cannot upgrade to • Update controllers. available for the hard drive or NetWare 5.1. array controllers.

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

Possible Issues Possible Results or Impacts Options

• SYS volume does not have at • NDS relies on the SYS volume • Backup SYS and other least 750 MB of free space. for storage of the NDS volumes. Reallocate more database. Limited capacity will space to the SYS volume. restrict NDS. • 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 • File system is not performing • Backup volume, delete KB block size, and at enhanced level. volume, recreate volume, and suballocation is, or will be, restore volume. enabled. (A 64 KB block size • Do nothing. is not an issue if the volume will support NSS.) • Back up the volume and use Consulting Services RESIZE.NLM.

Step 3—Assess DOS Partition Size 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.

Possible Issues Possible Results or Impacts Options

• DOS partition has less than 35 • Unable to perform an in-place • Leverage Partition MB of free space. upgrade. Magic/Server Magic (TID 2926225). • Run out of space during in- place upgrade and cause • Get a new server (across-the- problems. wire upgrade). • Recovery of a failed in-place upgrade is very difficult.

Step 4—Assess Additional Name Space Modules 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)

Possible Issues Possible Results or Impacts Options

Page 31 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • No additional name space • Cannot use GroupWise • Load appropriate name space modules are loaded. WebAccess. modules. • Cannot use accelerated • Live without name space. upgrade. • No long filename support.

Step 5—Assess Unnecessary Name Space Modules 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.

Possible Issues Possible Results or Impacts Options

• Unnecessary name space • DET is larger than necessary. • Unload unnecessary name space modules and remove modules are loaded. • Slower volume mounts. name space with VREPAIR. • Increased RAM requirements. • Live with unnecessary name space.

Possible Issues Possible Results or Impacts Options

• SAP is being filtered. • NDS cannot synchronize. • Disable SAP filtering. • Time cannot synchronize. • Do not filter SAP types: • RCONSOLE cannot function. • 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.)

Page 34 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. Activity 9—Assess Non-NetWare Server Operating System Platforms • Might be an opportunity to sell the appropriate “NDS for xxx” product.

Analysis Possible Results or Impacts Options

• Third-party or other NLMs are • Server abends and/or other • Update to a certified version. not NetWare 5.1 certified. difficulties. • Find an alternate solution. • Server upgrade delays. • 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. Visit- http://developer.novell.com/prodcert/

Page 36 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

Possible Issues Possible Results or Impacts Options

• Slow/congested WAN links • Poor time sync • Enable compression • Poor NDS sync • Upgrade link speed • Won’t accept additional traffic • Design solutions around the links • Application/connection timeouts

• Inadequate resources on • Router failures • Add memory/resources to routers to handle SAP • RIP/SAP corruption existing hardware increases • Upgrade hardware/firmware

• Lack of reliability/fault • Service interruptions • Encourage fault tolerance tolerance • Limit service dependencies on WAN links • Provide fail-over mechanism for service dependencies

• Multicast is turned off on WAN • You must manually design an • Design SLP appropriately SLP infrastructure deployment • Turn on multicast on the WAN plan. (not recommended)

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

Possible Issues Possible Results or Impacts Options

• Misconfigured TCP/IP • Not all clients and servers will • Reconfigure TCP/IP infrastructure. For example, be able to successfully infrastructure. incorrect default gateways, communicate with other hosts. incorrect subnet masks, or duplicate addressing schemes. • Non-existent TCP/IP • No TCP/IP based networking • Propose NetWare 5.1 infrastructure. possible. installation using IPX only. • Discuss extension of scope of work with client to design TCP/IP infrastructure. Notify project manager. • Unreliable TCP/IP • Not all clients and servers will • Identify points of failure and infrastructure. be able to successfully recommend strategy to communicate with other hosts. address issues. • Lack of formal DNS • A global mechanism of name • Design around lack of formal infrastructure for name resolution for NetWare 5.1 DNS infrastructure. resolution. clients is not available, which • Propose formal DNS limits name resolution options. infrastructure for name • A TCP/IP-based deployment resolution. of NetWare 5.1 becomes more difficult and less fault tolerant. • Lack of formal DHCP • Inability to dynamically deliver • Propose formal DHCP infrastructure. client configuration options. infrastructure preferably using NetWare 5.1 DHCP. • Static configuration of TCP/IP environment. • Deficient formal DHCP • Inability to dynamically deliver • Determine if current DHCP infrastructure. client configuration options. 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. • TCP/IP routing protocols • Servers participating in the • Required static configuration incompatible with routing infrastructure will not of TCP/IP on NetWare 5.1 NetWare 5.1. send or receive routing servers. updates. • Insufficient IP addresses. • Cannot upgrade all • Create private addressing clients/servers to TCP/IP. scheme with NAT for Internet access. • Look at TCP/IP subnetting strategies. • Acquire more public addresses.

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 • Exacerbating the problem you • The NWIP environment must environment is unhealthy. are trying to solve. The be stabilized. –or- upgrade to NetWare 5.1 is • A migration strategy needs to often considered a be carefully planned one solution/remedy for the NWIP NWIP site at a time. environment. 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 • Encapsulated IPX on WAN • Use dual-stack approach with deployed. links. existing NWIP infrastructure. Follow dual-stack design • IPX on LAN wire. strategy. –or- • Replace NWIP infrastructure with Migration Agents in Backbone Support mode. Follow the IP/CMD migration strategy. • NWIP deployed to servers and • Encapsulated IPX on LAN and • Create coexistent CMD clients WAN. infrastructure and convert NWIP servers and clients to • No IPX on any wire CMD. Follow the IP/CMD migration strategy.

Step 1—Determine Print Server Capabilities Using the data from PFC table 16, see if the print servers work with IPX, IP, or NDS.

Possible Issues Possible Results or Impacts Options

• Print servers do not have an • This forces IPX to be used on • Design SLP appropriately for IP stack. the LAN. CMD support. • The implementation of pure IP • Implement dual stacks on (SLP design, use of dual NetWare servers associated stacks, etc.) will be affected. with the IPX print servers. • Upgrade print servers firmware or replace with newer technology. • Print servers do not work with • This forces NetWare 5.1 • If print servers support IP, use NDS. servers to do bindery LPR/LPD or IPP. emulation. • Maintain bindery emulation on appropriate NetWare 5.1 servers. This will require IPX and corresponding changes to SLP/pure IP design.

Step 2—Determine Action Plan 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 • IPX • IPX support should be a given, if the print server through bindery print queues is already being used in a NetWare 3.x or NetWare 4.x environment. • Adversely affects SLP/pure IP design. Legacy NetWare Printing • IPX • Adversely affects SLP/pure IP design. through NDS • NDS 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.

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

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

Possible Issues Possible Results or Impacts Options

• Certain SET parameters are • Could cause memory • Restore default settings. not at optimal setting. corruption. • Once the server has optimally • Could cause abends. tuned its own settings over a period of time, compare the • Performance is degraded. server’s dynamic settings to • NDS corruption occurs. the Novell recommended • File system corruption occurs. settings. • • Inconsistent time Thoroughly analyze each SET synchronization occurs. 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.

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.

Possible Issues Possible Results or Impacts Options

• A particular application is IPX • Cannot move to a pure IP • Upgrade the application to an dependent. environment. IP-based version. • Remove the application from the network. • Provide support for the application through SCMD (compatibility mode).

Step 1—Analyze Network SAP Information 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.

Page 45 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 IPX- dependent 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.

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

Activity 1—Project Manager Review

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.

NetWare 5.1 Upgrade—Solution Development

Subprocess 3—Develop Solution Design

Key Inputs Key Outputs Personnel Personnel • Lead consultant • Lead consultant • Consulting team members • Customer contacts/interfaces

Resources / Tools Outputs / Deliverables • Test and acceptance plan

Data / Reports Data / Reports • Signed statement of work • Weekly status reports • Summary of problem analysis • Design report • Summary of feasibility study • Completed preliminary report • Completed technical assessment and impact study • Conceptual solution design • Critical success factors

Task Summary 1. Prepare a solution design for the NetWare 5.1 upgrade. 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.

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

Start

Does NDS NDS Yes tree exist? HealthCheck

NDS design

NDS review/ re-design

NDS design report

Activity 1—NDS Design or Review

NDS structure:

NetWare 3.x to NetWare 5.1: NDS Design For detailed information, see the NDS Design Consulting guide (not included here, available on http://partnerweb.novell.com ).

Page 49 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Start

Latest client? Yes

Select client version

ZENworks? Yes

NAL? Yes

Manual update

Client design report

Activity 2—Update Novell Client Software

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 .

Start

Design SLP SLP design report Dual stack? No infrastructure

Yes

Design dual stack Dual stack design Design MA-MA MA-MA protocol implementation report protocol design report strategy infrastructure

IP on WAN, Yes limited IPX on LAN

Full CMD implementation CMD/MA island method; report Design CMD/MA island

Application Design plan for IPX to IP migrating existing migration IPX-dependent report applications to IP

Design plan for Device IPX to IP Design print migrating existing migration services using IPX-dependent report NDPS or other devices to IP

Design plan for Router IPX to IP migrating existing migration IPX-dependent report routers to IP

Activity 3—Analyze the Transition Path to IP

Page 53 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. Note: Before proceeding with this section, we strongly recommend that you read both Appendix D, SLP Design and Appendix B, CMD Essentials.

Deliverable:

The report should include:

• 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

Page 54 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. Not using CMD avoids the following issues: • You must continue to manage two protocols on the network until migration is • Planning and implementation of a CMD complete. environment. • Training time and costs associated with implementing a CMD environment • Possible increased server hardware requirement to support a CMD infrastructure • NDS and SLP considerations for CMD

• Servers and clients can be upgraded in a • The advantages of a single protocol are less controlled way without impacting the realized only as quickly as IPX enterprise. dependencies can be removed.

• Servers and workstations do not have to be • At least some IPX broadcast traffic will upgraded at the same time or in a specific continue to exist in the network until the order if a NetWare 5.1 supported client is migration is complete and IPX is unbound being used. from servers and routers.

• 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.

• 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:

Page 55 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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. See Appendix I for specific steps on implementing this strategy. The Pure IP via the MA to MA Protocol of CMD strategy has the following advantages and disadvantages:

Advantages Disadvantages

• Accommodates IPX dependencies without • IPX communication will still exist but will be the need for IPX traffic across WAN links. hidden by the MA to MA protocol. • Addresses the major consequences of IPX • Requires a comprehensive understanding of SAP/RIP more quickly than dual stacks – at the existing IPX environment. least on the WAN. • Provides more time to replace or eliminate • Depending on the environment, server IPX dependencies. hardware requirements may be significant. • This option addresses the administrative • High Design Complexity. Disperse network costs of maintaining IPX over the WAN at environments will require a very complex MA the start of the transition instead of the end. 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.

Page 56 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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. See Appendix I for specific steps on implementing this strategy. 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 • IPX communication will still exist but will be without the need for IPX traffic across WAN hidden by CMD and the MA to MA protocols. links. • May address the major consequences of • Requires a comprehensive understanding of IPX SAP/RIP more quickly than dual stack. the existing IPX environment. • May remove IPX protocol from the LAN most • Depending on the environment, server quickly. hardware requirements may be significant. • This option allows the network administrator • Higher Risk -- If implementation mistakes are to focus IPX traffic removal efforts on made they can result in network-wide specific sites/network LAN segments first. 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.

Page 57 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Deliverable:

The report should include:

• 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.

Page 59 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

Start

In-place upgrade First NetWare Yes of R/W replica of 5 server in tree? root server

Replace Upgrade (ATW) Yes hardware? Wizard

Start NetWare Yes In-place upgrade 3.x ?

Custom Accelerated large #s Yes upgrade standardization

In-place upgrade

Activity 5—Determine Upgrade Method to Use

The report should include:

• 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)

Advantages Disadvantages

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.

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)

Advantages Disadvantages

Advantage of this versus copying files with the No GUI-based utility; manual process. May not be Upgrade Wizard is speed (i.e., with the Upgrade appropriate for inexperienced installers. 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.

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.

Page 64 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. (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 /netware/sys/system/DSREPAIR.NLM Update

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.

Page 65 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

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

Activity 1—Project Manager Review

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.

NetWare 5.1 Upgrade—Solution Development

Subprocess 4—Test Solution Design in the Lab

Key Inputs Key Outputs Personnel Personnel • Lead consultant • Lead consultant • Consulting team members • Customer contacts/interfaces

Outputs / Deliverables Resources / Tools • Prototype system • Prototype system documentation Data / Reports • Recommended solution design Data / Reports • Impact study report • Weekly status reports • Preflight checklist information • Test and acceptance results report • Critical success factors

Task Summary 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.

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.

Page 70 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.

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).

Page 72 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 NetWare 5.1.

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.

Page 73 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 74 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 75 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 76 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 77 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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: • Where the server will be placed in the tree (tree name and context) • 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 assignments, and to compress the bindery files.

Page 78 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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. 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. 7. Print out the system login script (NET$LOG.DAT). This information is useful if you later need to update the container login script.

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.

Upgrade Wizard workstation

Netware 3 source server Netware 5 destination server

Figure 2. Isolate the NetWare 3.x Server

Update NLMs Make sure that the following NLM programs are updated to the latest versions on the NetWare 3.x server:

• A3112.NLM • SPXS.NLM • AFTER311.NLM • STREAMS.NLM • CLIB.NLM • TLI.NLM • MAC.NAM • TSA311.NLM • SMDR.NLM • TSA312.NLM

Page 79 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 80 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Figure 3. Sample Project Window

Create Subordinate Objects (conditional) 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

Page 81 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 82 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 83 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

Page 85 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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: • Where the server will be placed in the tree (tree name and context) • 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. 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. 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.

Page 86 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 7. Print out the system login script (NET$LOG.DAT). This information is useful if you later need to update the container login script.

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. 1. Run SYS:SYSTEM\BINDFIX to remove obsolete MAIL directories and trustee assignments, and to compress the bindery files. 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-to- server 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 like- named 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 in- place upgrade in order to use the accelerated upgrade utility; this is because the accelerated upgrade utility does not extend the schema.

Page 87 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 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.

Page 89 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 90 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 91 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 92 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 93 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 No. There are four directories you will newer version (4.10 to 4.11, for probably not copy from the SYS volume: example), should every file be SYSTEM, PUBLIC, LOGIN, and ETC. copied—including the system However, some of the configuration files in and public files? 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.

If the server is not upgraded to a Yes. By default, this type of migration newer version of NetWare, means that the two servers will be the same. should every file be copied?

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.

Page 94 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 95 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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).

Activity 1—Project Manager Review

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.

The pilot is performed on production workstations (a small subset).

NetWare 5.1 Upgrade—Solution Development

Subprocess 5—Perform the Pilot

Key Inputs Key Outputs Personnel Personnel • Lead consultant • Lead consultant • Consulting team members • Customer contacts Outputs / Deliverables • Identified pilot sites w/site surveys Resources / Tools • Pilot systems • Pilot results • Pilot system documentation • Test and acceptance documents of pilot systems Data / Reports • Debriefing • Suggested pilot sites with site surveys • Solution design Data / Reports • Modified system implementation plan • Modified test and acceptance plan • Weekly status reports • Closing report

Task Summary 1. Prepare a draft deployment plan and pilot test 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.

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

Activity 1—Project Manager Review

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).

NetWare 5.1 provides support for, and ships with, the following methods of network printing:

• 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.

Notes:

• 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.

Page 101 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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 The environment is IPX dependent. This during the upgrade process. prevents a pure IP environment and impacts the SLP design, because MAs must be used for connectivity.

Works for bindery-based programs and Each printer in the printing environment requires workstations. 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.

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. NDPS requires NetWare 5.1 servers to run Once the software is installed on the servers NDPS related NLMs to provide the printing and clients, the configuration within NDS is services. Loading these NLMs will increase centrally managed. resource utilization on a NetWare 5.1 server.

The NDPS server is less likely to have a The NDPS server becomes a point of failure in failure than the legacy print servers. the printing environment. In the event the NDPS server goes down, the printers associated with that server will not be available.

NDPS is a TCP/IP-based printing solution. It The workstations need relatively new clients (that will remove the IPX dependencies from the support NDS, IP, and NDPS). printing environment. Print driver distribution is automated through If the print server hardware does not natively NDPS. Each NDPS server has a database support NDPS, a NDPS gateway will need to be of print drivers that are distributed to the loaded and configured to enable non-NDPS workstations when print services are printers to work with NDPS. 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 An SLP infrastructure is required. environment. When using NDPS controlled access printers, print jobs can be monitored, paused, and deleted.

Page 103 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. NDPS controlled access printers require To print in a pure IP environment, external print only one NDS object per printer versus server hardware, such as JetDirect cards, must legacy printing; this reduces the number of support the TCP/IP protocol. NDS objects required in the NDS tree for printing.

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

Page 104 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 queue- based 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 NDPS- embedded 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).

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-NDPS- embedded 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

Deliverable:

• A report detailing how NDPS will be designed. You can expand and complete the following table and include as part of the report.

NDPS Brokers NDPS Managers NDPS Printer NDPS Gateways Comments Agents ENS RMS SRS CAP PAP

Page 106 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 107 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 Intended use was for “Mom and Pop” shops where control is wanted over who can print where everyone prints to all printers. The to what printers. [Public] object is given all rights to Public Access printers.

Controlled Access NDPS printers have Public Access printers are not NDS objects. corresponding NDS objects. You browse They are discovered via SAP or SLP. You can through the tree structure to find them. see a list of NDPS Public Access Printers within NWAdmn from “Tools, NDPS Public Access Printers.”

The driver can be set up to automatically The driver can be set up to automatically download to workstations by: download to workstation by one of two methods: • NDPS Remote Printer Manager Tab • NWAdmn32, Tools, NDPS Public Access on the Controlled Access printer Printers object. • NWPMW32.EXE The drivers will install and the printer icon The drivers will install and the printer icon will will appear in the printer folder. appear in the printer folder. Another tab shows who can “see” the If the driver is not set up to automatically Controlled Access printer: download you will have to manually install the If the driver is not set up to automatically printer driver with the NWPMW32 utility. You download, you can manually install the cannot use the Microsoft Printer Wizard because printer driver with Microsoft’s Printer Wizard a Public Access NDPS printer has no or the NWPM32 utility. 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 non- configured 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.

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.

175 Printers

Dedicated NDPS Server BROKER.NLM NDPSM.NLM HPGATE.NLM NDPS1

10 Printers 25 Printers NDPS Services NDPS Services BROKER.NLM BROKER.NLM Remote Main Ring Remote NDPSM.NLM Site #1 Site #2 NDPSM.NLM HPGATE.NLM HPGATE.NLM RMT1_FS1 RMT2_FS1

Task 2—NDPS Deployment

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.

Page 109 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 110 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 non- configured 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.

Page 111 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 112 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.

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:

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.

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 .

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.

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

Activity 1—Project Manager Review

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.

Page 119 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. Page 120 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 system1.

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

Page 121 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

Page 122 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 123 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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

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 users2.

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.

2 http://support.microsoft.com/support/kb/articles/Q195/8/51.ASP )

Page 124 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 Finish3.

Once Microsoft Office 2000 is installed access My Computer, there you will notice the Web Folders icon.

3 http://support.microsoft.com/support/kb/articles/Q195/8/51.ASP )

Page 125 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 126 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 127 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 129 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 .

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

Page 131 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

Page 132 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 133 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

Page 134 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 135 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • Common error messages for Web Folders are available at http://support.microsoft.com/support/kb/articles/Q195/8/51.ASP ) • 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.

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.

Activity 1—Project Manager Review

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.

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 Mission IP-Only Upgrade Available? IPX-Depende (server name) Critical? (no IP-only up

Y / N Y / N Date Plan to Upgrade Will Support Available to IP Version?

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/IP- based 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”

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.

Application

Libraries

Protocol NCP SAP Interface

CMD IPX SLP Redirect

CMD IP Redirect

Figure B1. Illustrating CMD redirections.

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.

Page 141 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 Call to NCP

NCP

I T P C X P I CMD 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.

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

Page 143 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

bindery.novell SA1 sapsrv.novell cmd.novell SA1 SA1 SA2 SA3 SA3 SA3

sapsrv.novell sapsrv.novell SA1 DA SA1 SA3 SA3

SLP SReq SLP SReq sapsrv.novell sapsrv.novell

SA1 w/ CMD SA2 no CMD SA3 w/ CMD Bindery Table Bindery Table Bindery Table SA1 SA2 SA1 SA3 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)

Page 145 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.

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 IP/CMD Server FS2

IPX IP/CMD RIP/SAP SAP Information Information from from SLP IPX Device Migration Agent Registered Services Broadcasts

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.

Delta bindery information sent from MA to CMD

TCP port 2302

session established Once per minute RIP/SAP broadcast IP/CMD

sapsrv.novellSLP SReq objects for Migration Agent

Bindery information from

CMD Network

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.

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.

Page 149 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

FS1? IPX Client IP/CMD Client Yes FS1 No FS1

FS1?

IPX IP/CMD

Migration Agent Directory Agent

IPX Server FS1 IP/CMD Server FS2

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.

Page 150 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.

RIP/SAP info from IPX Network 1 encapsulated IPX in IP (UDP 2645) IPX Network Network 1 2 Backbone Support Backbone Support Server Server RIP/SAP info from IPX Network 2 encapsulated in IP (UDP 2645)

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 NLSP broadcast HELLO NLSP Neighbors NLSP2 Up 13 packet from NLSP1 NLSP1 Up 60 NLSP3 Up 43 NLSP2 Up 13 NLSP4 Up 27 NLSP4 Up 27 NLSP1 NLSP3

NLSP Neighbors NLSP1 Up 60 NLSP2 Up 13 NLSP3 Up 43 NLSP4

Figure B9. The NLSP HELLO packet updates neighbor routing tables.

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.

Page 152 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 Encapsulated HELLO packet sent to MA2via UDP 2645 Encapsulated HELLO packet sent to MA3via 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.

NLSP Neighbors NLSP Neighbors NLSP2 Up 13 NLSP1 Up 60 NLSP3 Up 43 Encapsulated NLSP NLSP2 Up 13 NLSP4 Up 27 HELLO packet from NLSP4 Up 27 NLSP1 w/ SCMD NLSP1 NLSP3 w/ SCMD

Encapsulated NLSP NLSP Neighbors HELLO packet from NLSP1 Up 60 NLSP1 NLSP2 Up 13 NLSP3 Up 43 NLSP4 w/ SCMD

Figure B11. Updating NLSP tables across the virtual IPX network.

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.

Router

IPX IPX Network Network 1 2

MA to MA protocol exchanges RIP/SAP info

Backbone Support Backbone Support Server1 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:

Page 155 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.novell objects sapsrv from FS1 sapsrv from FS2 sapsrv from FS3 64KB of information ... sapsrv from FS162 sapsrv from FS163 sapsrv from FS1 sapsrv from FS2 sapsrv from FS3 ... sapsrv from FS162 sapsrv.novell object Directory Agent registered sapsrv.novell?

IP/CMD Network C00FFEE

IP/CDM Client IP/CMD Server FS163

Figure B13. The 64KB SLP limit will affect poorly designed CMD environments.

Page 156 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 IP/CMD RIP/SAP SAP Information Information from from SLP IPX Device Migration Agent Registered Services Broadcasts

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.

Router Router Migration Agent CMD net BADBEEF

IPX Server FS1

Figure B15. Poor placement of Migration Agents.

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.

Page 159 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 IP/CMD Segment Segment

Migration Agent

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.

Test Objective: 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

Page 160 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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%.

Test Objective: 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.

Test Objective: 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.

Page 161 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 Backbone Support

Migration Agent Backbone Support

...

MA w/ MA w/ MA w/ MA w/ MA w/ MA w/ BS BS BS BS BS 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

Page 162 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

Page 163 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 164 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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:

Page 165 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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 Migration Agent Migration Agent Backbone Support Backbone Support Router Router

Router Router Migration Agent Migration Agent Backbone Support Backbone Support

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 infrastructure.

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.

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.

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 NDS- based, 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

Novell Client for Windows NT

Novell Client for 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.

Page 168 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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:

• http://support.novell.com – minimum patch list • http://www.novell.com/download • http://support.novell.com/Ftp/Updates/nw/nwclients/Date0.html

Client to be Installed Version NCIMan Can Be Used Comments with ACU

Novell Client for Windows 9x

Novell Client for Windows NT/2000

Novell Client for DOS/Windows 3.x

Other

• 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.

• 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

Page 170 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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

Process:

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

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. • Place the UNATTEND.TXT file in a location on the network where users have Read and File Scan rights, e.g., SYS:PUBLIC\ACU. • 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” • Go to “Update Login Scripts”.

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.

• Use NAL and the NAL NT Service Process to distribute the client software.

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

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:

Available switches for SETUP.EXE include:

• /? Displays list of available switches • /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:

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:

Note: This login script does not contain commands for determining the DOS/Windows 3.x clients.

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

REM Check to see if a Novell Client is currently installed: IF "%OS" = "WIN98" THEN GOTO W98C32 END

W98C32: REM The following should be one line in your Login Script: @\\zensrvr\sys\public\client\win98\ibm_enu\SETUP.EXE /ACU /NCF /U:\\zensrvr\sys\public\client\win98\ibm_enu\UNATTEND.TXT EXIT

REM Check to see if a Microsoft Client is currently installed: IF = "C:\WINDOWS" OR = "C:\WIN98" THEN GOTO MSCLIENT98 END

MSCLIENT98: MAP Y:=ZENSRVR\SYS:PUBLIC\CLIENT\WIN98\IBM_ENU DRIVE Y REM The following should be one line in your Login Script: #SETUP.EXE /ACU /NCF /U:\\zensrvr\sys\public\client\win98\ibm_enu\UNATTEND.TXT EXIT

REM Check to see if a Novell Client is currently installed: IF "%OS" = "WIN95" THEN GOTO W95C32 END

W95C32: REM The following should be one line in your Login Script: @\\zensrvr\sys\public\client\win95\ibm_enu\SETUP.EXE /ACU /NCF /U:\\zensrvr\sys\public\client\win95\ibm_enu\UNATTEND.TXT EXIT

REM Check to see if a Microsoft Client is currently installed: IF = "C:\WINDOWS" OR = "C:\WIN95" THEN GOTO MSCLIENT95 END

MSCLIENT95: MAP Y:=ZENSRVR\SYS:PUBLIC\CLIENT\WIN95\IBM_ENU DRIVE Y REM The following should be one line in your Login Script: #SETUP.EXE /ACU /NCF /U:\\zensrvr\sys\public\client\win95\ibm_enu\UNATTEND.TXT 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

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.

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 IP- based 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.

Page 181 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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

Page 182 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. (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.

Page 183 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Multicast SLP packet User Agent addressed to 224.0.1.22 Service Agent requests services does not have service; no reply

Unicast SLP packet addressed to original host

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.

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.

Page 186 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 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.

Unicast SLP packet DA List addressed to original host DA1 DA2 DA3 Multicast SLP packet User or Service Agentaddressed to 224.0.1.35 DA2 Looks for Directory Directory Agent responds Agent

Unicast SLP packet addressed to original host

DA3 Directory Agent responds

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

Page 189 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

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

Page 192 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 193 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Directory Agent creates Service List entry for services SA1 registered SA2

Service registration using Service registration using DA1 unicast SLP packet unicast SLP packet

Unicast SLP request for Unicast SLP response list of services ACK ACK

DA List Services Learned DA List DA1 SA1 DA1 DA2 SA2

Service Agent 1 User Agent Service Agent 2

ACK

Service registration using unicast SLP packet

DA2 Directory Agent creates Service List entry for services SA1 registered

Figure D6. Summary of the service registration process.

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

Page 194 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

5. DA creates (modifies) object in local SLP cache

Services Learned SA1 DA2

4. DA sees sync event and reads NDS for new SLP service object info

3. NDS partition sync event is triggered 4. DA sees sync event DA receives service and reads NDS for new registration from a SLP service object info service agent 5. DA creates (modifies) 2. DA creates (modifies) object in local SLP cache SLP service object in NDS DA sends ACK to SA Services Learned DA1 DA3 SA1 1. DA creates (modifies) object in local SLP cache

Services Learned SA1

Figure D7. DA to DA synchronization.

Page 195 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 196 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 197 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Services Learned Services Learned SA1 Service Registration Service Request

Acknowledgement

Service Agent belonging DA1 servicing User Agent belonging to Scope 1 Scope 1 to Scope 2 and configured with address of DA1

Figure D10. Example of scoping.

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

Page 198 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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:

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.

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.

Page 200 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

Page 201 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. being 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

Page 202 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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

Page 204 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 3

Option 2 Option 4 "Hybrid" of 1-3

Option 1

Low Scaleability High Scaleability

Figure D12. Scalability vs. Ease of Implementing SLP.

Option 1 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

Page 205 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 UA

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:

No Multicast

SA SA SA UA UA SA SA SA UA UA

DA DA O=Novell O=Novell Unscoped scope Unscoped scope

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.

DAL-SLPDA --> DAL-SCOPE SEA-SLPDA --> SEA-SCOPE replica: replica:

Router

Toronto

TOR-SLPDA --> TOR-SCOPE replica:

Figure D15. Option 3: Implementing SLP in a large WAN environment.

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

Router Multicast

Multicast

SLPDA - DRegion,Global SLPDA - SRegion,Global DNS - dal.abc.com DNS - syd.abc.com syd-fs1 dal-fs1 syd-fs2 dal-fs2 Sydney Dallas

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.

Page 209 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

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.

Grey areas indicate [ROOT] (Sample_Tree) SLP-Management partition boundaries containers at the WAN hubs and Major sites are only used if a scoped The SLP-Management Container configuration is used. If an should contain the Directory Agent unscoped or global (DA) and unscoped or global SLP configuration is used then Scope Objects. This partition should these SLP-Management Org. Name SLP-Management be replicated to all DA Servers. This containers would not should not represent a problem exist. Note that DAs are provided that these scopes are still listed at the global relatively small, or adequate WAN SLP-Management level. resoursces exist to handle the This is done because the replication traffic, and/or the "SLP latest versions of SLP will SA Default Lifetime" is increased in allow NDS based SLP order to reduce the frequency of DA Objects Un-Scope or Directory Agent discovery. Global Scope Objectsupdates to the SLP scope database.

State/locality 1 State/locality 2 State/locality 3

WANSite Hub 1 1 WAN Hub 2 Site 3 Major Site 1 Major Site 2 WAN Hub 3

SLP-Management SLP-Management SLP-Management SLP-Management SLP-Management

Local Scope Local Scope Local Scope Local Scope Local Scope

Figure D11. General SLP/NDS design.

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.

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. • 5, the maximum number of CMD servers per scope is about 108. • 6, the maximum number of CMD servers per scope is about 90. • 7, the maximum number of CMD servers per scope is about 77. • 8, the maximum number of CMD servers per scope is about 67.

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.

Page 214 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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 FR to satelite satelite offices B-Region offices Hub

Atlanta Chicago Hub Hub

FR to FR to H-Region Frame Relay (FR) D-Region satelite satelite Hub DS-3 Hub offices Cloud offices

G-Region E-Region Hub Hub

FR to Los Angeles FR to satelite Hub satelite offices offices

FR to satelite offices

Figure D17. Hub sites are connected to one another through a Frame Relay cloud.

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.

Page 217 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.

Page 218 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 SReg Scope2 ndap.novell 1 ndap.novell 2 ndap.novell 5 FS1 FS2 ndap.novell 3 ndap.novell 6 Scope1 Scope2 ndap.novell 4 FS1 ndap.novell 1 ndap.novell 2 FS2 FS5 FS3 FS6 FS4

DA1 Services Scope1 Scope2

FS6 WAN FS3 Scope1 Scope2 ndap.novell 6 ndap.novell 3 SReg SReg

DA3 Services DA2 Services Scope1 Scope1 FS5 Scope2 Scope2 FS4 Scope1 Scope2 ndap.novell 5 ndap.novell 4

Figure D18. Sample SLP infrastructure.

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.

Page 219 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

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 D23. SLP Scope Units property page for the ATLA_NDS1_US_SLPDA NDS object.

Figure D25. SLP Scope Units property page for the CHIC_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

Page 225 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

Page 226 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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:

Page 227 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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

Page 228 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 229 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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

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.

Hub site

Frame Relay Frame Relay Hub site Regional office DS-3 (Regional)

Desktop System

Hub site

Service Request bindery.novell

Primary DA SLP_SCOPE2_US

Figure D30. 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 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:

Page 232 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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

Page 233 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 234 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 235 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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 56kbps- clock rate. The hub sites are connected via T-1 clocked, 256kbps CIR Frame circuits. None of the circuits are compressed.

NWIP NWIP NWIP DSS DSS DSS

no multicast

T-1 FR 256k CIR T-1 FR 256k CIR IP Only IP Only Hub Site Hub Site Hub Site Region B Region A Region C no multicast no multicast no multicast Mixed NWIP,IPX Mixed NWIP,IPX Mixed NWIP,IPX ~266 56k FR 28.8 CIR ~266 56k FR 28.8 CIR ~266 56k FR 28.8 CIR

~266 regional sites ~266 regional sites ~266 regional sites ~86 servers ~173 servers ~86 servers

Proposed CMD Region Proposed CMD Regions Proposed CMD Region

Figure D31. Customer WAN diagram with 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

Page 237 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 238 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Grey areas indicate [ROOT] (Sample_Tree) 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 Org. Name SLP-Management 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.

State/locality 1 DA Objects Global Scope SLP-Management containers Object 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 B-Region Hub A-Region Hub C-Region Hub containers would not exist. Note that DAs are still listed at the global SLP- Management level. This is done because the latest SLP-Management SLP-Management SLP-Management versions of SLP will allow NDS based SLP Directory Agent discovery. A1-Region A2-Region B-Region Scope Scope Scope C-Region Scope

Figure D32. NDS Architecture to support a Regional SLP Design

As you review this diagram please take note of the following:

• 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:

Page 240 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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: ;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” ; REGISTER TYPE “mgw.novell” to SCOPE “global,a1-region”

Page 241 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. REGISTER TYPE “ndap.novell” to SCOPE “global,a1-region” ; ;The last line in the file must contain a carriage return and line feed. A ;semicolon specifies a comment. ; 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.

The set parameters are as follows:

• “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. • “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 B-Region SLP.CFG file. An example follows: ;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.

Page 242 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. ; ;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” ; REGISTER TYPE “mgw.novell” to SCOPE “global,b-region” REGISTER TYPE “ndap.novell” to SCOPE “global,b-region” ; ;The last line in the file must contain a carriage return and line feed. A ;semicolon specifies a comment. ; DA IPV4, b-region-da.state.us DA IPV4, a-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 ‘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. • “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.

Page 243 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 C-Region SLP.CFG file. An example follows: ;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” ; REGISTER TYPE “mgw.novell” to SCOPE “global,c-region” REGISTER TYPE “ndap.novell” to SCOPE “global,c-region” ; ;The last line in the file must contain a carriage return and line feed. A ;semicolon specifies a comment. ; DA IPV4, c-region-da.state.us DA IPV4, b-region-da.state.us

DA IPV4, a-region-da.state.us

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 ‘C’ region DA is configured to serve the scopes:

• C-Region • Global

Page 244 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

The set parameters are as follows:

• “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. • “Set SLP SA Default Lifetime = 65535” This setting (in seconds) pushes the TTL 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 server to use DHCP to discover DAs if and when the customer decides to use DHCP.

Next we will look at the non-DA SLP.CFG file. An example follows: ;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” ; REGISTER TYPE “mgw.novell” to SCOPE “global,X-region” REGISTER TYPE “ndap.novell” to SCOPE “global,X-region” ; ;The last line in the file must contain a carriage return and line feed. A ;semicolon specifies a comment. ;

DA IPV4, X-region-da.state.us

Page 245 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 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.

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.

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.

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.

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.

Service Request bindery.novell

Main DA Primary DA GLOBAL

Frame Relay Hub site Regional office (Regional)

Desktop System

Service Request bindery.novell Fault Tolerance DA Primary DA X-REGION

Figure D35. Sample SLP service resolution process for the SLP infrastructure.

Page 249 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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?

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 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.

Page 250 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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 single- byte 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.

Page 252 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 “mapped- down” 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.

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].

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

Page 255 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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).

For more information:

• 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]

Page 256 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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]

Page 257 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

For more information:

• http://www.novell.com/documentation/lg/nw51/docui/index.html#../othr_enu/data/h9v4j5 ki.html

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

Advantages Disadvantages

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 Will migrate passwords, but only if all of the file NetWare 5.1 users or have no password but force servers in the enterprise are up and running. Expect the user to define one at initial logon. failure of the process and have a contingency plan.

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 zero- length 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.

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(““); System.out.println(“Usage:”); System.out.println(“ java com.novell.consulting.nwinst.BuildAutoexec responsefile autoexecfile”); System.out.println(““);

return; }

//////////////////////////////////////////////////////////////////////// // Open the response file which is in ini format

_responseFile = new ResponseFile(argv[0]);

try { _responseFile.initialize(false, false); } catch (IOException e) { // FileNotFoundException

Page 260 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 (“;------”);

_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 -”);

Page 261 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. _autoexecFile.println (“;------”); _autoexecFile.println (“Set Bindery Context = “ + fileServerCx); _autoexecFile.println (““);

//////////////////////////////////////////////////////////////////////// // 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); _autoexecFile.println (““);

//////////////////////////////////////////////////////////////////////// // Build the Console Logging Section

_autoexecFile.println (“;------”); _autoexecFile.println (“;- Log Boot/AUTOEXEC Process -”); _autoexecFile.println (“;------”); _autoexecFile.println (“LOAD CONLOG Entire=Yes”); _autoexecFile.println (““); _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 (“;------”); _autoexecFile.println (“;- Mount All Volumes -”); _autoexecFile.println (“;------”); _autoexecFile.println (“MOUNT ALL”); _autoexecFile.println (““);

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 = ““;

Page 262 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 (“;------”); _autoexecFile.println (“LOAD TCPIP”); _autoexecFile.println (ipLoadLine); _autoexecFile.println (“BIND IP “ + ipBoardName + “ addr=“ + ipAddress + “ mask=“ + ipMask + “ gate=“ + ipGate); _autoexecFile.println (““);

//////////////////////////////////////////////////////////////////////// // Build the IPX Protocol Section

String ipxLoadLineTemp = _responseFile.getString(“NWI:Network Adapter 1”, “Load Line “ + Integer.toString(ipxFrameTypeLineNumber));

Page 263 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. //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 (“;------”); _autoexecFile.println (“; IPX Protocol Section”); _autoexecFile.println (“;------”); _autoexecFile.println (“LOAD IPXRTR”); _autoexecFile.println (ipxLoadLine); _autoexecFile.println (“BIND IPX “ + ipxBoardName + “ NET=“ + ipxNet); _autoexecFile.println (“LOAD IPXRTRNM”); _autoexecFile.println (““);

//////////////////////////////////////////////////////////////////////// // 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 (“;------”); _autoexecFile.println (“;- Launch The GUI -”); _autoexecFile.println (“;------”); _autoexecFile.println (“; STARTX.NCF”); _autoexecFile.println (““); _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 (“;------”); _autoexecFile.println (“;- Load ManageWise -”); _autoexecFile.println (“;------”); _autoexecFile.println (“; sys:/system/nma/nma5.ncf”); _autoexecFile.println (““); _autoexecFile.println (“;------”); _autoexecFile.println (“;- Load Backup -”); _autoexecFile.println (“;------”); _autoexecFile.println (““); _autoexecFile.println (“;------”);

Page 264 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. _autoexecFile.println (“;- Load Console Monitor -”); _autoexecFile.println (“;------”); _autoexecFile.println (“LOAD MONITOR”); _autoexecFile.println (““); _autoexecFile.println (“;------”); _autoexecFile.println (“;- Stop Logging Boot Process -”); _autoexecFile.println (“;------”); _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 The installation scripting language is the language used by most all known as CDWare Scripts) 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.

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 Type Description Novell Provo Corp HQ 0001 User Novell - Provo Corp HQ

0002 User Group Novell – Provo Corp HQ 0044 0 Connection Station Service Type Corollary Inc 0003 NetWare Print Queue or Print Group Novell - Provo Corp HQ 0047 Advertising Print Server Novell - Provo Corp HQ 0004 NetWare File Server (can be emulated by NT Server running FPNW or Win95 with 0048 TCP/IP Gateway Micom – InterLAN File and Print Share for NW) Novell - Provo 0049 Business Records Corp Corp HQ 004A NetBlazer Modems Paradata Computer 0005 Job Server Novell - Provo Corp HQ Networks

0006 Gateway Novell - Provo Corp HQ 004B Btrieve Server - VAP 5.0 Pervasive 0007 Print Server or Silent Print Server Novell - Software Inc Provo Corp HQ 004C NetWare SQL VAP Pervasive Software Inc 0008 Archive Queue Novell - Provo Corp HQ 004D Xtree-Net Central Point Software

0009 Archive Server Novell - Provo Corp HQ 004E ICL Gateway VAP Computer 000A Job Queue Novell - Provo Corp HQ Communication Consult 000B Administration Novell - Provo Corp HQ 004F Database Server Emerald Bay 0017 Diagnostics None 0050 Btrieve VAP 4.11 Novell - Provo Corp HQ 0020 NetBios None 0051 LAN Services 0052 QuickLink ICM 0021 SNA Gateway National Advanced Systems 0022 Sperry Corp Computer Systems 0053 MAC Project Novell - Provo Corp HQ 0023 NACS Async Gateway KTA 0054 Value Added File System Novell - Provo Corp HQ 0024 Remote Bridge Server Novell - Provo Corp HQ 0055 Term Emulator Systems Analysis Inc 0025 Data Language Corp 0056 Stocknet Broker SAP Type Novell - Provo Corp HQ 0026 Bridge Server or Asynchronous Bridge Server Computer Logics 0057 Stocknet Exchanger SAP Type Novell - Provo Corp HQ 0027 TCP/IP Gateway Santa Clara Systems 0058 Multi-point X.25 Router Eicon Technology 0028 Point-point Eicon Technology 0059 LAN Services 0029 Multi-point X.25 Gateway Eicon Technology 005A Business Records Corp 002A Chi Corp 005B Business Records Corp 002B Compass Computing 005C Business Records Corp 002C PC Chalkboard Intel - Hillsboro 005D Business Records Corp 002D Time Synchronization VAP Novell - Provo 005E Business Records Corp Corp HQ 005F Business Records Corp 002E Target Service Agent (ARCserve 0060 Stocknet Broker - Static Novell - Provo 5.0/Palindrome Backup Directory 4.x)

Corp HQ 0084 Interactive Financial Solution

0061 Stocknet Queue Type Novell - Provo Corp 0085 Interactive Financial Solution HQ 0086 Interactive Financial Solution 0062 Stocknet Player Type Novell - Provo Corp HQ 0087 Interactive Financial Solution

0063 Interactive Financial Solution 0088 Interactive Financial Solution

0064 ARCserve Interactive Financial Solution 0089 Interactive Financial Solution

0065 Interactive Financial Solution 008A Interactive Financial Solution

0066 ARCserve 3.0 Interactive Financial 008B Interactive Financial Solution Solution 008C Interactive Financial Solution 0067 Interactive Financial Solution 008D Mail Server McGill University 0068 Interactive Financial Solution 008E Rational Data Systems 0069 Interactive Financial Solution 008F Queue Types Tate Associates Inc 006A Interactive Financial Solution 0090 TNET X.21 IDA Bridge British Telecom 006B Interactive Financial Solution 0091 TNET X.21 Bridge British Telecom 006C Interactive Financial Solution 0092 Tape Backup Server Emerald Systems 006D Stocknet Exchange - Static Novell - Provo Corp Corp HQ 0093 Watcom 006E NACS NetPro Inc 0094 Sila Com Software Novell - Provo Corp HQ 006F Rabbit Software Corp 0095 VMS Router Control Interconnections 0070 MIC SNA DFV Server Mikado 0096 Micro DataBase Systems 0071 Tape Drive Server Digi-Data Corp 0097 Dart College Hill Systems 0072 WANcopy Utility Novell - Provo Corp HQ 0098 NetWare Access Server Novell - Provo 0073 Novell - Provo Corp HQ Corp HQ 0074 Novell - Provo Corp HQ 0099 Network Courier Microsoft Workgroup Canada 0075 NetWare Btrieve Novell - Provo Corp HQ 009A Named Pipes Server Novell - Provo Corp 0076 NetWare SQL Novell - Provo Corp HQ HQ 0077 Novell - Provo Corp HQ 009B Job Server DIS 0078 Novell - Provo Corp HQ 009C Raylynn Knight 0079 Novell - Provo Corp HQ 009D CQ3270 LAN CQ Computer 007A TES - NetWare VMS Novell - Provo Corp Communications HQ 009E Unix - Portable Group/Portable NetWare 007B Mergent International Novell - Provo Corp HQ 007C Interactive Financial Solution 009F Progress Database Progress Software Corp 007D Interactive Financial Solution 00A0 Gupta SQL Base Server Gupta 007E Interactive Financial Solution Technologies 007F Interactive Financial Solution 00A1 Powerchute-VAP/NLM Server Power Supply American Power Conversion 0080 Interactive Financial Solution 00A2 Auditor Package Blue Lance Network Info 0081 Interactive Financial Solution Sys 0082 Interactive Financial Solution 00A3 Security Blue Lance Network Info Sys 0083 Interactive Financial Solution 00A4 “Corel Driver Product under Novell 386

Corel Systems Corp, Optical Div” 0117 CSA SMA /Communication Server Novell - 00A5 Archive Server Gigatrend Inc Provo Corp HQ 00A6 Menu Program R&S Data Systems 0118 CSA DBA /Communication Server Novell - Provo Corp HQ 00A7 386 NLM Unisys - Camarillo 0119 CSA NMA /Communication Server Novell - 00A8 LAN 1 Router Atlanta Technologies Provo Corp HQ

00A9 “Object Type Corel Systems Corp, Optical 011A CSA SSA /Communication Server Novell - Div” Provo Corp HQ

00AA “Object Type Corel Systems Corp, Optical 011B CSA Status /Communication Server Novell Div” - Provo Corp HQ

00AC IDA Status Utility Compaq Computer Corp 011C SAA Data Link Agent Novell - Provo Corp HQ 00AD LANport Virtual Extension of Ports Microtest Inc 011D Communication Server Novell - Provo Corp HQ 0100 Peer Logic 011E CSA APPC /Communication Server Novell 0101 R21PX Crosstalk - Provo Corp HQ

0102 Inventory Manager Intel - Hillsboro 011F Communication Server Novell - Provo Corp HQ 0103 SequelNet Oracle Corp 0120 Communication Server Novell - Provo 0104 VAP Pillsbury Company Corp HQ

0105 Gateway to Unisys Marshfield Clinic 0121 Communication Server Novell - Provo 0106 Gateways to Unisys Marshfield Clinic Corp HQ

0107 RSPX Server /386 NetWare Novell - Provo 0122 Communication Server Novell - Provo Corp HQ Corp HQ 0108 NetWare for VM & MVS Phaser Systems 0123 Communication Server Novell - Provo Inc Corp HQ 0109 NetWare for VM & MVS Phaser Systems 0124 Communication Server Novell - Provo Inc Corp HQ 010A NetWare for VM & MVS Phaser Systems 0125 Communication Server Novell - Provo Inc Corp HQ 010B NetWare for VM & MVS Phaser Systems 0126 SNA Test /Communication Server Novell - Inc Provo Corp HQ 010C Net 3270 McGill University Computing CT 0127 Communication Server Novell - Provo Corp HQ 010D Image Server File Net 0128 Communication Server Novell - Provo 010E RTK Owl Micro Systems Corp HQ 010F Novell SNA Gateway Novell - Provo Corp 0129 Communication Server Novell - Provo HQ Corp HQ 0110 Artefact Network Support 012A CSA Trace /Communication Server Novell - Provo Corp HQ 0111 Test Server Novell - Austin 012B Super SNA Agent /NetWare for SAA 0112 Print Server Hewlett Packard - Boise Novell - Provo Corp HQ 0113 Communication Server Novell - Provo 012C Communication Server Novell - Provo Corp HQ Corp HQ 0114 CSA MUX /Communication Server Novell - 012D Communications Server Novell - Provo Provo Corp HQ Corp HQ 0115 CSA LCA /Communication Server Novell - 012E Communications Server/IKARUS Virus Provo Corp HQ Scan Utility Novell - Provo Corp HQ 0116 CSA CM /Communication Server Novell - 012F Communications Server Novell - Provo Provo Corp HQ Corp HQ

0130 Communications 014F Netframe NetWare 386 Net Frame Executive/Communications Server Novell - Systems Provo Corp HQ 0150 Maxiback - VAP Sysgen 0131 Image Server Wang Laboratories Inc 0151 DCS System Server Computer Concepts 0132 BT X.25 British Telecom Corporation

0133 NNS Domain /Elmer Project Novell - Provo 0152 DCA IPX Communication Product/ Corp HQ IRMALAN Gtwy DCA

0134 Elmer Project Novell - Provo Corp HQ 0153 DCA IPX Communication Product DCA

0135 NNS Profile /Elmer Project Novell - Provo 0154 Forms Capability Rochester Telephone Corp HQ Corp

0136 Elmer Project Novell - Provo Corp HQ 0155 Forms Capability Rochester Telephone Corp 0137 NNS Queue /Elmer Project Novell - Provo Corp HQ 0156 Forms Capability Rochester Telephone Corp 0138 Elmer Project Novell - Provo Corp HQ 0157 Forms Capability Rochester Telephone 0139 Elmer Project Novell - Provo Corp HQ Corp

013A Elmer Project Novell - Provo Corp HQ 0158 Forms Capability Rochester Telephone Corp 013B Elmer Project Novell - Provo Corp HQ 0159 Forms Capability Rochester Telephone 013C Elmer Project Novell - Provo Corp HQ Corp 013D Securities Trading & Technology 015A Forms Capability Rochester Telephone 013E Securities Trading & Technology Corp

013F Network Designers Ltd 015B Forms Capability Rochester Telephone Corp 0140 Network Management System Accunetics 015C Network Computing Inc - NCI 0141 Software GMBH Lufthansa Information Service 015D Network Computing Inc - NCI 0142 Aladdin Knowledge Systems 015E Network Computing Inc - NCI 0143 CDROM Online Computer Systems 015F Network Computing Inc - NCI 0144 NetWise Inc 0160 Network Computing Inc - NCI 0145 Communication Processor Evergreen 0161 Advertising Remote Server Artefact Systems Network Support 0146 XDB Server Database XDB Systems Inc 0162 System 9 HBF Group 0147 Piggyback Login Net_inc Micro 0163 System 9 HBF Group Enhancement Inc 0164 System 9 HBF Group 0148 Network Software Associates 0165 System 9 HBF Group 0149 Advertising Remote Server Artefact 0166 NW Management Novell - Provo Corp HQ Network Support 0167 InstantCom Communications Server 014A ID 5001 Weather Station Zenith Data Instant Information Systems 0168 PickIt (Comm Server) Intel PCED - 014B Novell - Provo Corp HQ Hillsboro 014C Netframe NetWare 386 Net Frame 0169 Peer Logic Systems 016A Open Image for NetWare Wang 014D Netframe NetWare 386 Net Frame Laboratories Inc Systems 016B Open Image for NetWare Wang 014E Netframe NetWare 386 Net Frame Laboratories Inc Systems 016C Open Image for NetWare Wang

Laboratories Inc 019B APT Net Remote Automated Programming 016D Open Image for NetWare Wang Tech Laboratories Inc 019C APT Net Remote Automated Programming 016E Open Image for NetWare Wang Tech Laboratories Inc 019D APT Net Remote Automated Programming 016F Luminar Optical Server Corel Systems Tech Corp 019E APT Net Remote Automated Programming 0170 TXD Thomas Conrad Corp Tech 0171 LANFax Redirector Alcom Inc 019F Mailslots IBM - Franklin Lakes

0172 File Share Compaq Computer Corp 01A0 Terminal Gateway for Unisys Mainframe Upstanding Systems 0173 File Share Compaq Computer Corp 01A1 DB Server Lodgistix Inc 0174 Compaq SNMP Agent /File Share Compaq Computer Corp 01A2 Spare Lodgistix Inc

0175 File Share Compaq Computer Corp 01A3 “Gateway, Composite Page, & Etc Servers Teknos Systems” 0176 File Share Compaq Computer Corp 01A4 “Gateway, Composite Page, & Etc Servers 0177 LANWare Horizon Technology Inc Teknos Systems”

0178 LANWare Horizon Technology Inc 01A5 “Gateway, Composite Page, & Etc Servers Teknos Systems” 0179 LANWare Horizon Technology Inc 01A6 “Gateway, Composite Page, & Etc Servers 017A LANWare Horizon Technology Inc Teknos Systems”

017B LANWare Horizon Technology Inc 01A7 “Gateway, Composite Page, & Etc Servers Teknos Systems” 017C LANWare Horizon Technology Inc 01A8 “Gateway, Composite Page, & Etc Servers 017D LANWare Horizon Technology Inc Teknos Systems” 017E LANWare Horizon Technology Inc 01A9 “Gateway, Composite Page, & Etc Servers Teknos Systems” 017F LANWare Horizon Technology Inc 0180 NMI LAN Services Horizon Technology Inc 01AA “Gateway, Composite Page, & Etc Servers Teknos Systems” 0188 SYSM/LAN2 H&W Computer Systems 01AB “Gateway, Composite Page, & Etc Servers 0189 Xtree Server Central Point Software Teknos Systems” 018E PC Metro Crystal Point 01AC “Gateway, Composite Page, & Etc Servers Teknos Systems” 018F PC Metro Crystal Point 01AD Menu Program R&S Data Systems 0190 Service Point Interpoint Software 01AE Menu Program R&S Data Systems 0191 Service Point Interpoint Software 01B0 Object Type for GARP Server Net 0192 Netway 2000 Tri Data Systems Research Pty Ltd 0193 Netway SNA Tri Data Systems 01B1 “Licensing Restrictions/BindView LAN Support Group, Network Res” 0194 Maxway 500 Tri Data Systems 01B2 “Licensing Restrictions/Bindery Type LAN 0195 TCP/IP Gateway Computer Vision Support Group, Network Res” Services 01B3 Media Touch Systems 0196 Integrated Technologies Inc 01B4 Network Management Product NCR - SE 0197 Share Master Storage Dimensions Columbia 0198 Zenith Electronics Corp 01B5 Network Management Product NCR - SE Columbia 0199 Zenith Electronics Corp 01B6 Network Management Product NCR - SE 019A Zenith Electronics Corp Columbia

01B7 Network Management Product NCR - SE 01D9 Castelle Inc Columbia 01DA LANPress Print Server Castelle Inc 01B8 Network Management Product NCR - SE Columbia 01DB Castelle Inc

01B9 Bonsai Technologies 01DC FAX/Xerox 7033 Fax Server/Excel Lan Fax Castelle Inc 01BA BizTech 01DD Castelle Inc 01BB Bonsai Technologies 01DE Castelle Inc 01BC Bonsai Technologies 01DF Castelle Inc 01BD Bonsai Technologies 01E0 Castelle Inc 01BE Server Type KM Systems 01E1 Castelle Inc 01BF “Server Type for Value Added Product/ LanDesk Mgr Connect Computer Co/ 01E2 Area Code & Exchange Look-Up Server Equinox Information Systems Intel” 01E3 Sorting Server Equinox Information 01C0 “Object Type Collegiale, City of (Ottawa)” Systems 01C1 Object Types J&L Information Systems 01E4 Wall Data

01C2 Object Types J&L Information Systems 01E6 X25 Automated Bridge Monitor & Control Automated Interactions-Div Of 01C3 Object Types J&L Information Systems 01E7 Rational Data Systems 01C4 Object Types J&L Information Systems 01E8 Rational Data Systems 01C5 Object Types J&L Information Systems 01E9 Rational Data Systems 01C6 Distributed Application Folio Corporation 01EA Rational Data Systems 01C7 Bindery Type Microtest Inc 01EB Media Touch Systems 01C8 Object Bindery Type Madge Networks Inc 01EC Powergrid Network Daemon Cognos Inc 01C9 Object Types Funk Software 01ED Integralis Ltd 01CA Object Types Funk Software 01EE Integralis Ltd 01CB NetModem/E Shiva Corp 01EF Felsina Software 01CC LanRover/E Shiva Corp 01F0 Legato Systems 01CD LanRover/T Shiva Corp 01F1 Legato Systems 01CE Shiva Corp 01F2 Legato Systems 01CF E-mail Queue Object-type C&D Data Services 01F3 Legato Systems 01D0 E-mail Server Object-type C&D Data 01F4 Legato Systems Services 01F5 Legato Systems 01D1 Lanlord Product Microcom Client Server Tech Gr 01F6 Andersen Consulting - Chicago 01D2 Mark Hurst 01F8 Sytron Corp 01D3 Mark Hurst 01F9 “For Unibase Bv, Based in Holland Integralis Ld” 01D5 Centers for Disease Control 01FB Northeast Broadcast Consultant 01D6 On-Queue Task Queue NetPlus Software Inc 01FC Extended Systems 01D7 On-Queue Task Server NetPlus Software 01FD IBM - Endicott Inc 0200 NP/SQL Server Novell - Provo Corp HQ 01D8 FAXPress Server Castelle Inc 0201 The Make Server Novell - Provo Corp HQ

0202 Generic Job Server Novell - Provo Corp Corp HQ HQ 023D SMS Workstation Name Object Novell - 0203 RMF2 Utility Novell - Provo Corp HQ Provo Corp HQ

0204 Novell - Provo Corp HQ 023E SMS Testing & Development Novell - Provo Corp HQ 0205 Novell - Provo Corp HQ 023F SMS Testing & Development Novell - 0206 Novell - Provo Corp HQ Provo Corp HQ 0207 Novell - Provo Corp HQ 0240 Novell - San Jose

0208 Novell - Provo Corp HQ 0241 Novell - San Jose

0209 Novell - Provo Corp HQ 0242 Novell - San Jose

020A Novell - Provo Corp HQ 0243 Novell MHS DS Gateway for OCE Novell - Walnut Creek 020B Novell - Provo Corp HQ 0244 NDS Gateway for OCE Novell - Walnut 020C Novell - Provo Corp HQ Creek

020D Novell - Provo Corp HQ 0245 Superlab File Distribution Server Novell - Provo Corp HQ 020E Novell - Provo Corp HQ 0246 Version Control Queue Novell - Provo 020F Novell - Provo Corp HQ Corp HQ

0210 Novell - Provo Corp HQ 0247 NVT Remote Login over SPX Novell - Salt Lake City 0211 Novell - Provo Corp HQ 0248 Queue Server for IBM PSF/2 Novell - 0212 Novell - Provo Corp HQ Provo Corp HQ

0213 Novell - Provo Corp HQ 0249 Lantern RMON Novell - San Jose 0214 Novell - Provo Corp HQ 024A LAT Transport Service Provider Novell - 0215 Novell - Provo Corp HQ Sunnyvale Western Reg 021A OT_Messaging_Server Novell - San Jose 024B LAT Session Manager Novell - Sunnyvale Western Reg 021D MPR - NetWare Mobile IPX Home Router Novell - Fortune 024C LAT Network from NetWare Novell - Sunnyvale Western Reg 021E NetWare Lontalk Gateway Novell 024D Address Server Novell - Provo Corp HQ 0233 NW Management - Management Agent 1.x Novell - Provo Corp HQ 024F Appletalk Remote Access Service Novell - Sunnyvale Western Reg 0234 Network Management Info Server Novell - Provo Corp HQ 025E Xapia Interface for NW 3.11 Novell - Indisy Canada Inc 0235 Bindery Type - TIRPC Service Novell - Provo Corp HQ 025F X.400 Protocol Access Module Novell - Indisy Canada Inc 0236 Novell - Salt Lake City 0260 SNADS Protocol Access Module Novell - 0237 NMS IPX Discover or LANtern Read/Write Indisy Canada Inc Channel Novell - San Jose 0261 Superlab Network Switch Server Novell - 0238 NMS IP Discovery or LANtern Trap/Alarm Provo Corp HQ Channel Novell - San Jose 0262 Hub Services Novell - Sunnyvale - 0239 NW Management - HMI Hub Management Western Reg Novell - San Jose 0263 NetWare Management Agent Novell - 023A NW Management - Lanalyzer Agent Novell Sunnyvale - Western Reg - San Jose 0264 Global MHS Novell - Sunnyvale - Western 023B Bindery Type for Broadcast Novell - Provo Reg Corp HQ 0265 SNMP Novell - Sunnyvale - Western Reg 023C DOS Target Service Agent Novell - Provo 0266 Version Control Server Novell - Provo Corp

0267 Application Rights Program Novell - Provo 0301 VAP - Advertising Services Firefox Corp HQ Communications Ltd

0268 HP JetDirect Novell - San Jose 0302 VAP - Advertising Services Firefox Communications Ltd 0269 Superlab Automation Server Novell - Provo Corp HQ 0303 VAP - Advertising Services Firefox Communications Ltd 026A NW Management - NMS Console Novell - San Jose 0304 VAP - Advertising Services/ SAA Gateway Firefox Comm Ltd/Novell 026B NW Time Synchronization Novell - Provo Corp HQ 0305 VAP - Advertising Services Firefox Communications Ltd 026D Advertising Job Server Novell - Provo Corp HQ 0306 NPS (NetWare Print Services) InterConnections Inc 0272 Datalink Switching (DLSW) Novell - San Jose 0307 NPS Spool Client InterConnections Inc 0273 Nest Device Novell - Provo Corp HQ 0308 HP NS Util Hewlett Packard - Boise

0274 GroupWise Message Multiple Servers 0309 Document Management Package Soft Novell - Orem Solutions

0275 Sample Code from Dev. Support Novell - 030A Worldgroup BBS Server Galacticomm Inc Provo Corp HQ 030B Lucid Systems Pty LTD 0277 SAP Server Type Novell - San Jose 030C HP JetDirect/ Quick Silver Hewlett Packard 0278 Directory Server/ NDS Replica /Tree - Boise Novell - Provo Corp HQ 030D Broadcast Operation Sup Utah Scientific 0281 Domain Application Services Novell - Sunnyvale - Western Reg 030E Fault Tolerant Control Utah Scientific 0282 NDPS Service Registry Service Novell - 030F CD ROM Server Trantor System Ltd Provo Corp HQ 0310 CD ROM Server Trantor System Ltd 0283 Domain Application Services Novell - Sunnyvale - Western Reg 0311 CD ROM Server Trantor System Ltd 0284 Domain Application Services Novell - 0312 CD ROM Server Trantor System Ltd Sunnyvale - Western Reg 0313 CD ROM Server Trantor System Ltd 0285 Domain Application Services Novell - 0314 CD ROM Server Trantor System Ltd Sunnyvale - Western Reg 0315 CD ROM Serve Trantor System Ltd 0286 Domain Application Services Novell - Sunnyvale - Western Reg 0316 CD ROM Server Trantor System Ltd 0287 Domain Application Services Novell - 0317 Batch Processor Computer Aided Sunnyvale - Western Reg Business Sol 0288 Domain Application Services Novell - 0320 Gateway Attachmate Corporation Sunnyvale - Western Reg 0321 Chicago Research & Trading 028A MPR - IPX Address Mapping Gateway Novell - San Jose 0322 Frye Computer Systems 028B ManageWise Novell - San Jose 0323 Wang Laboratories 028D Salutation Manager Novell - Orem 0324 Wang Laboratories 028E Novell Administrator for Win NT/Tabasco 0325 X.500 DSA Server AAC Associates Novell - Provo Corp HQ 0326 Novell Remote ISDN Router LANWorks 0292 NetWare Client Libraries Novell - Provo Corp HQ 0327 BootWare/Microsoft Diagnostics (MSD) LANWorks 02FF Novell - Provo Corp HQ 0328 SQL Server Watcom 0300 VAP - Advertising Services Firefox

0329 Aetna Life & Casualty 034E Preferred Systems Inc.

032A Aetna Life & Casualty 034F Preferred Systems Inc.

032B Fax Server Digital Visions Corp 0350 Preferred Systems Inc. 032C Voice Server Digital Visions Corp 0351 Preferred Systems Inc.

032D Interprocess Exchange Server Digital 0352 Bindery Type Fujitsu Ltd Visions Corp 0353 Bindery Type Fujitsu Ltd 032E Application Server Nationsbank Mortgage Corp 0354 Bindery Type Fujitsu Ltd

0330 SAS Share Server SAS Institute 0355 Backup Exec Arcada Software

0331 SAS Connect SAS Institute 0356 LANovation

0332 Archetype 0357 LANovation

0333 Archetype 0358 Bindery Object Type CBIS Inc 0334 Aetna Life & Casualty 035A MBAC

0335 Multisynch Communications Server 035B Right-Hand-Man E-mail/scheduling Pkg Multitech LAN Aces Inc

0336 Communications Server Multitech 035C Fax Server Transfax Corporation

0337 Magee Enterprises Inc 035D Fax Print Server Transfax Corporation

0338 Magee Enterprises Inc 035E Fax Merge Server Transfax Corporation

0339 Magee Enterprises Inc 035F Network Management Server Transfax Corporation 033A Magee Enterprises Inc 0360 Object Type Funk Software 033B Magee Enterprises Inc 0362 “Object-type, Pseudo Peer-to-peer US 033C Magee Enterprises Inc Army Corps of Engineers” 033D Magee Enterprises Inc 0363 Print Server - Laser Jet Extended Systems 033E Magee Enterprises Inc 0364 Server-type for LAN Times Japan Softbank Corp 033F Magee Enterprises Inc 0365 Queue-type for LAN Times Japan Softbank 0340 Magee Enterprises Inc Corp 0341 Data Service to Workstation/School Admin 0366 MGATE - Communication Gateway/LANs Chancery Software + Vax Coefficient Systems Corp 0342 Bindery Type Microtest Inc 0367 Excalibur Technologies Corp 0343 Bindery Type Microtest Inc 0368 Excalibur Technologies Corp 0344 Bindery Type Microtest Inc 0369 Excalibur Technologies Corp 0345 Bindery Type Microtest Inc 036A Excalibur Technologies Corp 0346 Bindery Type Microtest Inc 036B Bindery Type Aetna Life & Casualty 0347 Bindery Type Microtest Inc 036C IPX Layer Peer-to-peer Communications Sewell Development 0348 Bindery Type Microtest Inc 036D Micro Integration 0349 Bindery Type Microtest Inc 036E NLM Server Praxis 034A Public Preferred Systems Inc. 036F Bindery Type Avail Systems Corp 034B Preferred Systems Inc. 0372 Digital Equipment - Merrimack 034C Preferred Systems Inc. 0373 NLM Advertising for UPS Info Brainstorm 034D Preferred Systems Inc. Engineering

0374 Shareware Communications Server Cherry Learning Corp Tree Software 03A1 Neumeier & Walch Systemtechnik 0375 Enterprise ECS Intel Corp - Hillsboro 03A2 Hyprotech Ltd

0376 Enterprise Initialization Mode Intel Corp - 03A3 “Kyocera Corp, Yohaga Office” Hillsboro 03A4 “Kyocera Corp, Yohaga Office” 0377 Comm Svr - Net Bios IPX US Robotics Software 03A5 “Kyocera Corp, Yohaga Office”

0378 NLM Advertising for UPS Info Brainstorm 03A6 “Kyocera Corp, Yohaga Office” Engineering 03A7 Object Type for a Group Stadt Pforzheim 0379 Fax Server Extended Systems 03A8 Object Type for a Queue Stadt Pforzheim 037A Fax Server Extended Systems 03A9 Object Type for a Server Stadt Pforzheim 037B Fax Server Extended Systems 03AA Universal Data Systems - Motorola 037C Fax Server Extended Systems 03AB Universal Data Systems - Motorola 037D Gateway Management Wall Data 03AC Universal Data Systems - Motorola 037E Powerchute Alert - UPS Monitoring American Power Conversion 03AD Universal Data Systems - Motorola

037F ViruSafe Notify Central Point Software 03AE Raima Corp

0380 Fax Server Optus Information Systems 03AF Copy Protection Server Pace Software Systems Inc 0381 “TNS Transport Network Substrate, Vers 2 Oracle” 03B0 TNA Communication with 2 NLM's Palindrome 0382 ID for Lasermaster Printer Products Laser Master Corp 03B1 Ethernet LAN Controller for NetWare Bus Tech 0383 PowerChute Administrative American Power Conversion 03B2 Server ID for NLM Network Designers LTD 0384 Sequel Link Client-server Middleware 03B3 File Management Services Systems Axis Techgnosis Inc PLC 0385 Mail Systems Synectic Systems Ltd 03B4 Queue Management Services Systems Axis PLC 0386 Hewlett Packard Bridges Hewlett Packard - Roseville 03B5 Object Type IWI - Integrated Workstation Inc 0387 Hewlett Packard Hubs Hewlett Packard - Roseville 03B6 LANtech Services 0388 Workstation Peer-to-peer Communications 03B8 Modem Protocall - Sharing Serial Ports IBM - Research Triangle Park LANsource Technologies 0389 Datanex Corporation 03B9 Global Info Application Exec Environment Funk Software 0394 NetWare Connect NCS (Mac) Server Novell 03BA Magix Database Server Advanced Software Technologies 039A HP Open Mail & Portable NetWare Hewlett Packard - Berkshire 03BB Performance Monitor Computer Communications Co/ Ameridata 039B Lotus Notes Iris Associates 03BC NetPort Advertising Intel PCED 039C Communications Server Bindery Dator 3 SPOL SRO 03BD Wan Connection Server IDE Corporation 039D Communications Server SAP Dator 3 03BE WICAT Jostens Learning Corp SPOL SRO 03BF WICAT Server Jostens Learning Corp 039E Fax Server Ferrari Electronic GMBH 03C0 Embedded in OEM Plotter Product 039F Computer Vision Services CalComp 03A0 Bindery Type for CD Server Jostens 03C1 Embedded in OEM Plotter Product

CalComp 03E4 Univel Server Type (Unixware) Univel

03C2 Embedded in OEM Plotter Product 03E5 Univel Server Type Univel CalComp 03E6 Univel Server Type Univel 03C3 Embedded in OEM Plotter Product CalComp 03E7 Univel Server Type Univel

03C7 LAN Spool 3.5 Intel - Hillsboro 03E8 Univel Server Type Univel

03C8 Network Management Madge Networks 03E9 Univel Server Type Univel Ltd 03EA Univel Server Type Univel 03C9 Diatek 03EB Univel Server Type Univel 03CA Point-of-sale Server Optical Mark Systems Ltd 03EC Univel Server Type Univel

03CB Software Access Control Server U of 03ED Univel Server Type Univel Plymouth 03EE Univel Server Type Univel 03CC Axnetwar - Envelope/label Print Server Thuridion Software Engineering 03EF Univel Server Type Univel

03CF Database Engine Blue Lance Network Info 03F0 Univel Server Type Univel Sys 03F1 First Call Thomson Financial 03D0 Report Engine Blue Lance Network Info Sys 03F2 Access Rights Server QM Consulting

03D1 Job Server Blue Lance Network Info Sys 03F3 Vital Signs/LAN Server Blue Line Software Inc 03D2 Object Type Blue Lance Network Info Sys 03F4 LAA Server Bindery Saber Software 03D3 Object Type Blue Lance Network Info Sys 03F5 Microsoft SQL Server IPX/SPX Support 03D4 Visinet NLM ID# Technology Dynamics Inc Microsoft 03D5 Print Servers Lexmark International 03F6 Asynchronous Serial Communications Black Creek Integrated Systems 03D6 Print Servers Lexmark International 03F7 Asynchronous Serial Communications 03D7 Print Servers (type 4033-011) Lexmark Black Creek Integrated Systems International 03F8 Asynchronous Serial Communications 03D8 XLE Print Servers (type 4033-301) Black Creek Integrated Systems Lexmark International 03F9 Asynchronous Serial Communications 03D9 Server Monitoring Program Trellis Black Creek Integrated Systems 03DA Multiple Services & Applications Think 03FA Watson - Communications Server Prodigy Systems Corp Services 03DB Multiple Services & Applications Think 03FB Netport Advertising Intel PCED - Hillsboro Systems Corp 03FC Netport Advertising Intel PCED - Hillsboro 03DC Multiple Services & Applications Think Systems Corp 03FD Netport Advertising Intel PCED - Hillsboro 03DD Developing Server Performance Analyzer 03FE Netport Advertising Intel PCED - Hillsboro Banyan Systems Inc 03FF Modular Software Corporation 03DE Gupta Sequel Base Server / NW SQL Gupta Technologies 0400 Bindery Object Types Artefact Network Support 03DF Remote Database Services Interactive Data Corp HQ 0401 Bindery Object Types Artefact Network Support 03E0 Object Store Server Object Design 0402 Bindery Object Types Artefact Network 03E1 Univel Server Type (Unixware) Univel Support

03E2 Univel Server Type Univel 0403 Bindery Object Types Artefact Network Support 03E3 Univel Server Type Univel

0404 Bindery Object Types Artefact Network 0421 Dealing Room Servers Teknos Systems Support Ltd

0405 Bindery Object Types Artefact Network 0422 Dealing Room Servers Teknos Systems Support Ltd

0406 Bindery Object Types Artefact Network 0423 Dealing Room Servers Teknos Systems Support Ltd

0407 Bindery Object Types Artefact Network 0424 Dealing Room Servers Teknos Systems Support Ltd

0408 Bindery Object Types Artefact Network 0425 Dealing Room Servers Teknos Systems Support Ltd

0409 Bindery Object Types Artefact Network 0426 Dealing Room Servers Teknos Systems Support Ltd

040A Image Application Laser Data 0427 Dealing Room Servers Teknos Systems Ltd 040B Image Application Laser Data 0428 Dealing Room Servers Teknos Systems 040C Image Application Laser Data Ltd

040D Image Application Laser Data 0429 Dealing Room Servers Teknos Systems Ltd 040E Image Application Laser Data 042A Full Text Retrieval Client/server DB Eng 040F Image Application Laser Data Impact Italiana SRL

0410 Image Application Laser Data 042B Gateway Software Datev HA 0411 Image Application Laser Data Systemtechnik 0412 Image Application Laser Data 042C Gateway Software Datev HA Systemtechnik 0413 Image Application Laser Data 042D Client-server Driver for IPX/SPX Reference 0414 Netsprint Digital Products Inc Point Software 0415 Remote Database Services - Bindery 042E Intrak Inc Interactive Data Corp Corp HQ 042F Loader Bindery Type Casper Systems Inc 0416 Dealing Room Servers Teknos Systems Ltd 0430 Finder Bindery Type Casper Systems Inc 0417 Dealing Room Servers Teknos Systems 0432 Filemaker Pro Claris Corp Ltd 0433 Networking Hub (281x Advanced SNMP 0418 Dealing Room Servers Teknos Systems Agent) Synoptics Ltd 0434 Network Terminal Emulator IDE 0419 Dealing Room Servers Teknos Systems Corporation Ltd 0435 Administration Server McGill University 041A Dealing Room Servers Teknos Systems 0436 Network Dynamic Data Exchange Net Ltd Logic 041B Dealing Room Servers Teknos Systems 0437 Asynchronous Communications Server US Ltd Robotics Inc 041C Dealing Room Servers Teknos Systems 0438 Back up Product Corel Systems Corp Ltd 0439 Back up Product Corel Systems Corp 041D Dealing Room Servers Teknos Systems Ltd 043A Miscellaneous Software Communications Tentera Computer Services 041E Dealing Room Servers Teknos Systems Ltd 043B Enterprise in Maintenance Mode Intel PCED - Hillsboro 041F Dealing Room Servers Teknos Systems Ltd 043C Connection Station Service Type Corollary Inc 0420 Dealing Room Servers Teknos Systems Ltd

043D Connection Station Service Type Corollary 045E Fax Server Ferrari Electronic GMBH Inc 045F Fax Server Ferrari Electronic GMBH 043E Connection Station Service Type Corollary Inc 0460 Fax Server Ferrari Electronic GMBH

043F Connection Station Service Type Corollary 0461 Communications Gateway - OSI Eicon Inc Technology

0441 Connection Station Service Type Corollary 0462 Communications Gateway - SNA Eicon Inc Technology

0442 Connection Station Service Type Corollary 0464 Batchfiler Application Jovandi International Inc Inc

0443 Connection Station Service Type Corollary 0465 NLM on File Server Jovandi International Inc Inc

0444 SNA Gateway / Microsoft SNA Server 0466 Time Synchronization Server Jovandi Microsoft International Inc

0445 Workstation Terminal AccessHSD 0468 Telephone Answering System A & M Hardware Software Dev Communications

0446 DE International Ltd 046A Fax Server Extended Systems

0447 Distributive Cache Product Raima Corp 046B Cadence Time Service Polygon Inc

044D IBM Host Gateway Idea Courier 046C Poly-portal for NetWare/Ethernet Gateway Polygon Inc 044E Project ID Urban Science Applications 046D Poly-link PC to Vax Networking Utilities 044F Common Communication Interface Polygon Inc Computer Associates 046E LAT ServicePolygon Inc 0450 Communications Server SDD Synthesizer Scandinavian Airlines 046F Automatic Tracking System Automated Interations 0451 Tape Back-up for NLM Applications Mountain Network Solutions Inc 0470 Measureservers and Measureclients Advantech Benelux BV 0452 Tape Back-up for NLM Applications Mountain Network Solutions Inc 0471 Disk Monitor Storage Dimensions 0453 Tape Back-up for NLM Applications 0472 Enterprise Network Services Banyan Mountain Network Solutions Inc Systems Inc 0454 Tape Back-up for NLM Applications 0474 Sybase SQL Server Sybase Mountain Network Solutions Inc 0475 Sybase SQL Server Console Sybase 0455 Tape Back-up for NLM Applications Mountain Network Solutions Inc 0476 Sybase SQL Server Monitor Sybase 0456 Tape Back-up for NLM Applications 0477 Sybase SQL Server Back-up Sybase Mountain Network Solutions Inc 0478 Sybase Open Server Sybase 0457 Canon Peripheral Server (GP55) Canon 0479 Sybase Open Server Console Sybase Information Systems 047C Remote Printer Console Peerless 0458 NetWare Server Product Intel - Phoenix 047D Auto-on/off Control NLM Mitsubishi Denki 0459 Object Oriented Database System Ontos Computer Inc 047E Ascom Fax Server Ascom 045A QMS Printer - Remote Configuration QMS Telecommunications Ltd 045B Client Server Monitoring Util (SCSI Array 047F Ascom Advertising Fax Server Ascom Monitor) Dell Computer Corp Telecommunications Ltd 045C Bindery Type - Application Definition 0480 Ascom Fax Queue Ascom LANovation Telecommunications Ltd 045D Fax Server Ferrari Electronic GMBH 0481 Job Server High Aspect Development

0482 Job Queue High Aspect Development Server Attachmate Canada

0483 Finance Think Systems Corp 04A1 Automation Information Router Kurt Manufacturing 0484 Forcasting Think Systems Corp 04A2 Xbase Record Engine Extended Systems 0485 Schema Think Systems Corp 04A3 Remote Procedure Call System Fortunet 0486 Fail Safe Analysis Think Systems Corp Inc

0487 Think Systems Corp 04A4 Delivery of Valuable Info W/usage Tracking Wave Systems Corporation 0488 Communication Between Client and Server CDC Federal Credit 04A5 Remote Access Server Traveling Software Inc 0489 Store Name of Special File on Fileserver Delta Information Systems 04A6 Bindery for Program Metering Database Pilot Systems 048A Main NLM Server for Calendar Manager Russell Information Sciences 04A7 Lt Auditor 4.00 Plus Blue Lance Network Info Sys 048B Array Monitor Server Core International 04A8 Bindery Service Fujitsu 048C Document Processing Server NLM Boss Logic Inc 04A9 Bindery Service Fujitsu

048D Document Processing Server NLM Boss 04AA SAP Service Fujitsu Logic Inc 04AB SAP Service Fujitsu 048E Document Processing Server NLM Boss Logic Inc 04AC Calendar Server Campbell Services Inc 04AE LED Server Inova Corporation 048F Document Processing Server NLM Boss Logic Inc 04B0 CDnet Server Meridian Data Corp 0490 Power Product for File Server Brainstorm 04B1 Policy Engine Emerald Systems Engineering 04B2 Policy Engine Emerald Systems 0491 NetBlazer Communication Server Telebit Corp 04B3 Policy Engine Emerald Systems 0492 RTS Terminal Emulation Data Research & 04B4 Policy Engine Emerald Systems Applications 04B5 Policy Engine Emerald Systems 0493 RSCF Client-Server API Data Research & Applications 04B6 Policy Engine Emerald Systems 0494 CD Networker Bindery Type Lotus 04B7 LAN Assist plus Remote Control Microtest Development 04B8 LAN Assist plus Remote Control Microtest 0495 Remote Back-Up Device Astora Software Inc 04B9 LAN Assist plus Remote Control Microtest 0496 SQL Server IPX/SPX Hidden Server 04BA LAN Assist plus Remote Control Microtest Microsoft 04BB Map Assist Peer-to-peer Microtest 0497 Database Lock Server High Aspect 04BC Map Assist Peer-to-peer Microtest Development 04BD Map Assist Peer-to-peer Microtest 0498 Meter Server Polymeter Response Ltd 04BE Map Assist Peer-to-peer Microtest 0499 Lancorp EOMS Lancorp Pty Ltd 04BF Jetnet Driver for Novell IPX Protocols 049A Bull HN SDMLancorp Pty Ltd Jetstream Technology Ltd 049B Network Management Agent Eicon 04C0 Database Server Running as NLM Technology Lodestar Data Systems Inc 049C ICOT SNA Gateway ICOT 04C1 Asynchronous Communications Servers 049D Software NLM Interconnections US Robotics Inc 049E Internet Gateway Metascybe Systems Ltd 04C2 Database Server Faircom 049F Email & Calendaring Communication 04C3 Taurus Database Server DCI

04C4 Taurus Serial Server DCI Communications Ltd

04C5 Casper Queue Casper Queue 04E4 Communication Server Firefox Communications Ltd 04C6 Casper Ghost Casper Systems Inc 04E5 Communication Server Firefox 04C7 Conferencing Service Communications Ltd

04C8 Mail System Queue Service Mitsubishi 04E6 Communication Server Firefox Electric Communications Ltd 04C9 Video Server Novell - Multimedia 04E7 Communication Server Firefox Communications Ltd 04CA Message Express Product Horizon Strategies Inc 04E8 Communication Server Firefox Communications Ltd 04CB CD ROM Server CBIS Inc 04E9 Communication Server Firefox 04CC Cost Recovery Server Vincent Larsen Communications Ltd

04CD PC-based SNA Gateway Ungermann 04EA Communication Server Firefox Bass Communications Ltd

04CF User Restrictions Val Laboratory Co Ltd 04EB Communication Server Firefox Communications Ltd 04D0 User Restrictions Val Laboratory Co Ltd 04EC Communication Server Firefox 04D1 SAP Advertising on Print Server Nissin Communications Ltd Electric Co Ltd 04ED Communication Server Firefox 04D2 OT Ellipse Server Bachman Information Communications Ltd Systems 04EE Remote Access Server ICC 04D3 Asynchronous Access Server Skyline Technology 04EF Statistic Management MultiTech 04D4 Enterprise Description Object 04F0 Statistic Management MultiTech Ingenieurburo Spatzier 04F1 Remote Control Software MultiTech 04D5 Print Server Foresyte Technologies 04F2 Remote Control Software MultiTech 04D7 Cubix QL Server Cubix Corp 04F3 MultiTech 04D8 Cubix QL Client Cubix Corp 04F4 NetLynx Communication Server Andrew 04D9 Job Server Storage Dimensions Corporation 04DA Communication Server Firefox 04F5 NetLynx Communication Server Andrew Communications Ltd Corporation 04DB Communication Server Firefox 04F6 Netlynx Communication Server Andrew Communications Ltd Corporation 04DC Communication Server Firefox 04F7 Netlynx Communication Server Andrew Communications Ltd Corporation 04DD Communication Server Firefox 04F8 Netlynx Communication Server Andrew Communications Ltd Corporation 04DE Communication Server Firefox 04F9 Netlynx Communication Server Andrew Communications Ltd Corporation 04DF Communication Server Firefox 04FA Netlynx Communication Server Andrew Communications Ltd Corporation 04E0 Communication Server Firefox 04FB Netlynx Communication Server Andrew Communications Ltd Corporation 04E1 Communication Server Firefox 04FC Netlynx Communication Server Andrew Communications Ltd Corporation 04E2 Communication Server Firefox 04FD Netlynx Communication Server Andrew Communications Ltd Corporation 04E3 Communication Server Firefox 04FE Netlynx Communication Server Andrew

Corporation 051C 1012 Hub Agent Asante Technologies

04FF Netlynx Communication Server Andrew 051D 1012 Hub Agent Asante Technologies Corporation 051E Advertising Network Modems LANsource 0500 Netlynx Communication Server Andrew Technologies Corporation 051F Application Programs U of Plymouth 0501 Netlynx Communication Server Andrew Corporation 0520 Bloomberg Audio Server Bloomberg LP 0502 Netlynx Communication Server Andrew 0521 Bloomberg Process Server Bloomberg LP Corporation 0522 Net Modem Server Practical Peripherals 0503 Netlynx Communication Server Andrew Inc Corporation 0525 Agent for Hub Management Idea Courier 0504 Deskview X Bindery Type Quarterdeck Office Systems 0526 Named Pipe Communications Service Symantec Group 0505 Print Server Add-on Intel - Hillsboro 0527 Print Server/Remote Printer Pacific Data 0506 Index Sequential Access NLM Infopoint Products Systems 0528 Print Server Seiko Epson Corp 0507 Associative Index Server Infopoint Systems 0529 InterServer File Copying Bankers Trust Co 0508 Netscribe Server Meridian Data Corp 052A Fax & Voice Server DCA 0509 Print Server for Remote Workstations Fuji Xerox Co Ltd 052B Angora Enterprise Gateway Rabbit Software Corp 050A Netmagic Bindery IdNet Magic Systems Inc 052C LANtronix / Remote Login Terminal Gordian 050B Financial Market Information Server AT Financial 052D Application Server Citrix Systems 050C Network Modem Anagram 052E OT_Bloomberg Media Touch Systems 050D Network Modem Anagram 052F Microcom Remote Access Server Microcom Inc 050E Document Management Service Imagery Software Inc 0530 Remark Voice Server Simpact Associates Inc 050F Image Management Service Imagery Software Inc 0531 IPX Communication Server Symantec Group 0510 Mass Storage Service Imagery Software Inc 0532 Access Server for Modem Sharing Bay Technical Associates Inc 0511 Database Server Tobit Hard & Software GMBH 0533 Gateway Between Network & Visa Pos- Port Hemko Systems 0512 Teli-Link Voice Server Computer & Communications Co 0534 Device Location via Remote Config Tool Milan Technology Corp 0513 Print Server Emulex Corporation 0535 Device Location via Remote Config Tool 0514 1012 Hub Agent Asante Technologies Milan Technology Corp 0515 1012 Hub Agent Asante Technologies 0536 Device Location via Remote Config Tool Milan Technology Corp 0516 1012 Hub Agent Asante Technologies 0537 Device Location via Remote Config Tool 0517 1012 Hub Agent Asante Technologies Milan Technology Corp 0518 1012 Hub Agent Asante Technologies 0538 Device Location via Remote Config Tool 0519 1012 Hub Agent Asante Technologies Milan Technology Corp

051A 1012 Hub Agent Asante Technologies 0539 Device Location via Remote Config Tool Milan Technology Corp 051B 1012 Hub Agent Asante Technologies 053A Device Location via Remote Config Tool

Milan Technology Corp 055D Hostview Utility Attachmate Corp

053B Device Location via Remote Config Tool 055E Print Server Lexmark International Inc Milan Technology Corp 055F Print Server Lexmark International Inc 053C Device Location via Remote Config Tool Milan Technology Corp 0560 Print Server Lexmark International Inc

053D Device Location via Remote Config Tool 0561 Print Server Lexmark International Inc Milan Technology Corp 0562 Statistics Gathering Agent Netcraft 053E Remoted SMS Server New Era Systems Software Development Services Ltd 0563 ERL Database Server Silver Platter 053F Listener/NetWare Sterling Tefen Lab Information Ltd

0540 Listener/DOS Sterling Tefen Lab 0564 ERL Directory Server Silver Platter Information Ltd 0541 Listener/Windows Sterling Tefen Lab 0565 Newswire Notification Generation 0542 Listener/OS2 Sterling Tefen Lab Technologies Corp

0543 Listener/MAC Sterling Tefen Lab 0566 Ziff Proprietary Services Ziff Information 0544 Listener/Unix Sterling Tefen Lab Services 0545 Techra Client/Server RDBMS Kvatro As 0567 Time Server NLM Meinberg Funkuhren

0546 DOCRA Client/Server Doc Mgmt System 0568 X-Base Database Server Extended Kvatro As Systems

0547 Voice/fax Responding Machine System 0569 Advertising Media-DB Server Ravi Sophia Technologies Inc

0548 I4/LS Naming Service Gradient 056A OEM Remote Access for Ethernet Shiva Technologies Corp 0549 TNSI Network Utilities Toadally Network 056B OEM Remote Access for Tokenring Shiva Systems Inc Corp 054A RM3 Configuration Cayman Systems Inc 056C Integrated Remote Access for Ethernet (LanRover/E Plus) Shiva Corp 054B SNMP Configuration Cayman Systems Inc 056D Integrated Remote Access for Tokenring 054D Imagesolve_ofs Imagesolve International (LanRover/T Plus) Shiva Corp 054E District Communication Gateway 056F Med Station Server Pyxis Corporation Chancery Software Ltd 0570 Telnet IPX Router Teletrol Systems Inc 054F District Link Chancery Software Ltd 0571 NLM Server SR Associates/Cybermedia 0550 EDM Client/PC Computer Vision 0572 Advertising NetModem Server Practical 0552 Security Object Bank of New Zealand Peripherals Inc 0555 “Printers, Plotters & Routers Seiko 0573 Satellite Connections ULF Zimmermann Instruments Inc” 0574 LAN/CD Server Logicraft 0556 Fax Services OAZ Communications Inc 0576 Peer Communications Tool Intelec 0557 Fax Services OAZ Systems Corporation 0558 Fax Services OAZ 0577 Communication Server Norman Data Defense Systems 0559 AT&T Joint Venture Telephony Server Novell - Provo Corp HQ 0578 Modem Sharing Software SEG 055A AT&T Joint Venture Telephony Server 0579 Hops Database Server Hops Novell - Provo Corp HQ International 055B AT&T Joint Venture Telephony Server 057A Datafile Access Handler LMS Novell - Provo Corp HQ 057B Novus Gateway Product Firefox 055C AT&T Joint Venture Telephony Server Communications Ltd Novell - Provo Corp HQ 057C LGS Interconections

057D LGS-PFT Interconections 05A6 NMS Icons Networth Inc

057E LGS-PPS Interconections 05A7 NMS Icons Networth Inc

057F TN 3270 Gateway Bus Tech Inc 05A8 NMS Icons Networth Inc 0580 McAfee Virus Pattern Server (NetShield) 05A9 NMS Icons Networth Inc McAfee Associates 05AA NMS Icons Networth Inc 0581 Optical Server Optisys 05AB NMS Icons Networth Inc 0582 Proride X.500 LDAP Support Control Data Systems 05AC NMS Icons Networth Inc

0583 Net Trax Alarm Monitor Net X Corp 05AD NMS Icons Networth Inc

0584 Net Trax File Server Agent Net X Corp 05AE NMS Icons Networth Inc

0585 Net Trax Workstation Agent Net X Corp 05AF NMS Icons Networth Inc

0586 Net Trax Bridge Agent Net X Corp 05B0 NMS Icons Networth Inc 0587 Team Office Product ICL Personal 05B1 NMS Icons Networth Inc Systems OY 05B2 NMS Icons Networth Inc 0589 Hyperdesk Distribute Object Mgmt System Hyperdesk 05B3 Multi-System Manager - Netview Interface IBM - Research Triangle Park 058A Hyperdesk Database Type Hyperdesk 05B4 Online Transaction Transportation System 058B TCP/SuperLAT Host Print SAP Meridian ABG Technology/United Card Svc Technology Corp 05B6 Datastar NLM Apertus Technologies 058C OCS SafeServer Omnitech Corporate Solutions 05B7 DS_LCC - Logical Link Controller Apertus Technologies 058D Jukebox User Group Todd Enterprises Inc 05B8 Database Management Services 058E Full Screen Login Confirm Revelation Technologies 058F Meeting Space Server World Benders 05B9 Distribution Services Discovery IBM - Inc Rome 0590 LAN Product Server BMC Software Inc 05BA Managing Hardware Routers Compatible Systems Corp 0591 CBT Server First Class Systems 05C0 Calendar Server Campbell Services Inc 0592 Net Tune Service Hawknet Inc 05C1 Network Management Application Xircom 0593 Print Server Ricoh Company Ltd 05C2 Network Management Application Xircom 0594 Remote Printer Ricoh Company Ltd 05C3 Network Management Application Xircom 0595 Slathp Status NLM Meridian Technology Corp 05C4 Network Management Application Xircom 0597 IPX Named Pipes Communication Service 05C5 Network Management Application Xircom Symantec Group 05C6 Network Management Application Xircom 0598 Appmeter for Suites Funk Software 05D9 Ethernet-Managed Stackable Hub IBM - 059C ServerLog Diamond Software Inc Research Triangle Park 05A0 Service Location Protocol Eicon 05E4 FileNet Network Clearinghouse File Net Technology 05E5 HPCS Data-Based Products Tobit Hard & 05A1 NMS Icons Networth Inc Software GMBH 05A2 NMS Icons Networth Inc 05E6 AST SNMP Instrumented Server AST Research Inc 05A3 NMS Icons Networth Inc 05EB Office Extend Server Fransen King 05A4 NMS Icons Networth Inc 05EC Windows NT Named Pipe Server Optus 05A5 NMS Icons Networth Inc Information Systems

05ED Gateway Server Fujitsu Ltd 062F Metering Program Secure Design

05EE Bindery File Fujitsu Ltd 0636 Comet Terminal Server Goodall Software Engineering 05EF Fax Workstation Object Sofnet Inc 0637 Comet File Server Goodall Software 05F2 Router Administration Server Livingston Engineering Enterprises 0640 Windows NT Server-RPC Services 05F3 Client Server Array Monitor Program Allodyne Inc Gateway Services for NW 05F4 Evergreen Management Agent Goodall Win 95-User Level Security Microsoft Software Engineering 064E NT Server-Internet Information Server 05F5 Windows Bulletin Board System Pacer Microsoft Software 073D Connect:Direct NLM Server Sterling 05F8 UPS SNMP Monitor NLM Computer Site Software Technologies Inc 073E Connect:Direct NLM Server Sterling 05FA Goodall Virtual Protocol Adaptor Goodall Software Software Engineering 073F Connect:Direct NLM Server Sterling 0603 Time Card Server Advanced Software Management Solutions 0740 Connect:Direct NLM Server Sterling 0606 Image Server Address Look-up Software Watermark Software 0741 Connect:Direct NLM Server Sterling 0607 Arts RLogind Server Reuters/ American Software Real Time 0742 Connect:Direct NLM Server Sterling 0608 Arts Generic Server Reuters/ American Software Real Time 0743 Maxserv 3270 Maxserv 0609 Arts RUUPD - Are You up Daemon Reuters/ American Real Time 0744 Maxserv Price Maxserv 060A Money Center Data Server Knight Ridder 0745 Maxserv Mail Maxserv Financial Inc 0746 Maxserv Macs Maxserv 060C Axis Printer Server Axis Communications AB 0747 Maxserv Reserved Maxserv 060D Unix Mail Server Felpausch 0748 Maxserv Reserved Maxserv 0610 SCSI Management Adaptec Inc 0749 Tasking IPX/LWSI Gateway Tasking Software BV 0611 Stealth Event Capture Engine Intelligence Quotient Intl Ltd 074D NLM Applications KNX Ltd 0613 Universal Data Transporter Conseil 074E NLM Applications KNX Ltd Formation et Developpe 074F NLM Applications KNX Ltd 0614 Communication Software (NLM) NEC - 0750 NLM Application KNX Ltd Nippon Electric Company 0753 STP Protocol Service Agent (CSA_FTP) 0615 Communication Software (NLM) NEC - Digital Technologies Nippon Electric Company 0754 IndF$file File Transfer Agt (CSA_indfile) 0616 Fax Gateway Server Russell Consulting Digital Technologies 061C Print Server Emulex Corporation 0755 All Kalpana Switches Kalpana 061D Print Server Emulex Corporation 0756 Chat Server Microsoft 061E Print Server Emulex Corporation 0757 Titanium Database Engine Micro 061F Print Server Emulex Corporation Database Systems Inc 0620 Print Server Emulex Corporation 0758 TCS Communication Server Micro Tempus Inc 0625 Setup Manager Access Control Maximized Software 0759 PC Communication Partner SAP Fujitsu

Ltd 07A8 Backup Exec Job Manager Arcada 075A PC Communication Partner SAP Fujitsu Software Ltd 07A9 Backup Exec Job Service Arcada Software

075B PC Communication Partner Bindery 07AA Serverbench Server PC Weeks Labs Fujitsu Ltd 07AB Serverbench Controller PC Weeks Labs 075C DPC Server SAP Fujitsu Ltd 07AC Service NW_Connect_PW_Server 075D DPC Server Bindery Fujitsu Ltd Flagstar 075E CAM Host TMD Consulting 07AF Site Meter Server Brightwork 075F Server Monitoring Application Softwork Development GMBH 07B0 Proxy Agent Site Meter Brightwork 076A Alarm Manager NLM Arcada/ Conner Development Peripherals 07B3 Disc Disaster Recovery Software 076B Event Manager NLM Arcada/ Conner Scheduler Columbia Data Products Peripherals 07B4 Cubix Comm Server Cubix

076D Desktop Management NLM Advanced 07B8 Identify Server Vendor for NMS Siemens- Modular Solutions Inc Nixdorf Information Sys

0770 Real-Time Integration Services Industrial 07BA File Transfer Between LAN/Mainframe Peer-to-Peer Proginet Corp

0771 LANDeep Server Monitor Deerfield 07BF Database Server Comp Soft PLC Computer Solutions 07C0 Application Advertisement Comp Soft PLC 0773 Hitecsoft Api Manager Hitecsoft Corp 07C1 Internet Apps on NW PCs Mango Systems 0774 Hitecsoft Public Library Hitecsoft Corp Inc 0775 Hitecsoft Phone Server Hitecsoft Corp 07CE Computer Supported Telephony Apps 077B Advantage X-Base Server Extended Global Communications Systems 07D1 Asynchronous Communication LAN 077F Security Auditor Secure Design Access Corp 0780 “U of Wisconsin Utilities U of Wisconsin - 07D2 RM Auditor-Monitoring NW Usage Madison, CAE” Research Machines 0781 “U of Wisconsin Utilities U of Wisconsin - 07D3 Generic NW Management Product 3Com Madison, CAE” Corp 0782 “U of Wisconsin Utilities U of Wisconsin - 07D4 SCSI Mgmt Adaptec Inc Madison, CAE” 07D9 Distribution Job Server Emotion Inc 0783 “U of Wisconsin Utilities U of Wisconsin - 07DA Distribution Queue Emotion Inc Madison, CAE” 07DB Distribution Feedback Job Server 078B A Non-Name-Pipe Server Team Emotion Inc Development Corp 07DC Voice Processing Server International 0798 NetHopper Router Rockwell Network Voice Exchange Systems 07DD Telephony Server Monitor International 0799 NetHopper Client Router Rockwell Voice Exchange Network Systems 07E0 Print Server Creative Controllers Inc 079A NetHopper Client Rockwell Network Systems 07E1 “Box Router Supporting IP, IPX & Appletalk Furukawa Electric Co Ltd” 079F Timbuktu Address Resolutions Farallon Computing 07E2 TEL Serve Fujitsu NS Center 07A0 Remote Access Server Meridian 07E3 Telemarketing Library Fujitsu NS Center Technology Corp 07E4 Multi-Server Metering Brightwork 07A7 Backup Exec Job Queue Arcada Development Software

07E6 Stress Magic Installation Utility Handler 0830 Pin64 Asahi Electronics Co Ltd Net Magic Systems Inc 0832 Appmeter 2-Licensing Product Funk 07EC Financial Data Server Telemet America Software

07ED ISDN Software Sharing of ISDN Boards in 0833 Communication Server Digital Products Network High Soft Tech Ingenieurburo Inc

07EE Comgate-Comm Gateway for IBM 0834 FTanalyzer Mitsubishi Electronic Corp AS/400Comware International 0835 Instant Internet Performance Technology 07F0 Zip Code Server Third Planet Software 0836 High Speed Communication Server C 07F2 Norton Anti-virus Client Server Comm Spec Corp Symantec 0837 Atlanta/3 Print Server Kelly Computer 07F8 Software Entertainment Origin System Inc Systems 07F9 Remote Management of Remote Access 083D Application Server for NT Citrix Systems Server Meridian Technology Corp 083E Custom Authentication/Load Balancing 07FC FTmanager - Controls NetWare Server Univ of Pittsburgh Mitsubisi Denki Computer 0840 IP to IPX Gateway InterNet Junction 07FD SAP for Audittrack version 2.0 EG Software 0841 RDB/7000 Fujitsu Ltd LAN Technical Ctr

07FF Soft-tub Agent Proxy for Tri-com Adaptor 084C ROUTE ONE and Related 2 Software 3Com Bug Inc

0801 SAP for Onguard EG Software 084D 98 Server Manager NEC Corp

080D IFONYFLOW for NetWare Fujitsu Social 0850 APLinkterm Mikasa System Engineering Science Lab 0853 APLinkgate Mikasa System Engineering 080E Print Server for NW 3.x Ishigaki Computer System Corp 0854 Automation Protocol Server Arcada Software 0810 ELAN License Server Demo ELAN Computer Group 0855 Tape ID Server Arcada Software 0811 ELAN License Server ELAN Computer 0858 NetWare to Internet Gateway On Group Technology 0813 “BVNCS Enterprise WAN LAN Support 085A RDB/7000 Server for NetWare Fujitsu Group, Network Res” Limited 0814 Evergreen Windcap Management Agent 085C DB-Express Fujitsu Kobe Engineering Goodall Software Engineering Limited 0816 Policy Engine Emerald Systems 085F Agent Router Proxy Arcada Software 0817 Policy Engine Emerald Systems 0860 Catalog Server Arcada Software 0861 Inetix Gateway Micro Computer Systems 0818 Policy Engine Emerald Systems 0819 Policy Engine NCSU 0868 SoundByte Server Envision Telephony Inc 081A Policy Engine NCSU 0869 Peer-to-Peer File Redirection Alex Lloyd 081B Policy Engine NCSU 086F Vision 20 Multi-Functional Product Ricoh 081C Policy Engine NCSU Corp 081D Off Line Copying On Technologies 0870 DPS-SV PFU Limited 0827 Palindrome Service Broker Palindrome 0876 “Audit Server LAN Support Group, Network Res” 0829 LAN LENS Server Digital Equipment Corp 0877 “Alert Server LAN Support Group, 082A LAN LENS Probe Digital Equipment Corp Network Res” 082B Job Queue Arcada Software 0878 “NetSqueeze LAN Support Group, Network Res” 082F DB Server 3.x Simultan AG

0879 “EWAM LAN Support Group, Network 08BC IP Access American Internet Corporation Res” 08BE “Electronic Arts Games Electronic Arts, 087A “Binding Server LAN Support Group, Inc” Network Res” 08BF IPX/IP Gateway Ukiah Software Solutions 087B “Authentication Server LAN Support Group, Network Res” 08C0 Norton Enterprise Framework (NEF) Symantec Corporation 087D Modem Pool Server Attachmate 08C1 Xyratex VirtualSCSI NLM Xyratex 087E Flora Manager for NetWare Hitachi Ltd Software Devt Ctr 08C2 8235 DIALs Switch for Token Ring IBM

0886 Multi-user DOS Gold Concurrent Controls 08C3 Stampede Overdrive Stampede Inc Technologies Inc

088B SPX Telenet Agent Telebit 08C4 Intergate Netsphere Communications Corp 0892 “UPS Control Software (UPSCON) Koubunsha, Ltd.” 08C6 Piccolo Cornerstone Software

0897 Shared LAN Cache Measurement 08C8 ServerTrak Intrak Inc Techniques 08C9 CDserve M4com Limited 089A Clear it Dell Computer Corp 08CC Powerburst/Integrated Shiva Corp 089D Fax Server - Perfect Fit Newtech Systems 08CD SurfCONTROLJSB Computer Systems Ltd

089F Net Tune Pro License Hawknet Inc 08CE “Trend Trak Intrak, Inc”

08A0 Net Tune Pro Alert Service Hawknet Inc 08CF SurfCONTROLJSB Computer Systems Ltd

08A1 “PowerVisor, PowerMonitor S Alfatech Inc” 08D0 Internet LANbridge Virtual Motion Inc 08D1 Hyperdrive Paperwise 08A4 Inetix Gateway Admin Service Micro Computer Systems 08D2 Golf Scoring System Information & Display 08A8 Rapport 112Shiva Corp 08D3 SurfCONTROLJSB Computer Systems Ltd 08AA CPA Corp Print Accounting Blue Lance 08D4 SurfCONTROLJSB Computer Systems Ltd Network Info Sys 08D5 SurfCONTROLJSB Computer Systems Ltd 08AC GroupEase for Windows Neighborhood Watch Ethosoft 08D6 SurfCONTROLJSB Computer Systems Ltd 08AD CS-Care Network Management System 08D7 SurfCONTROLJSB Computer Systems Ltd Compu-Shack Prague 08D8 SurfCONTROLJSB Computer Systems Ltd 08AE Firecall Team Development Corp 08D9 SurfCONTROLJSB Computer Systems Ltd 08B0 NetWare Enhanced Integration for AS400 IBM 08DA SurfCONTROLJSB Computer Systems Ltd 08B2 Overdrive Stampede Technologies Inc 08DB SurfCONTROLJSB Computer Systems Ltd 08B3 IIR AnswerSoft Inc 08DC SurfCONTROLJSB Computer Systems Ltd 08B4 Wanderlink Dialout Funk Software 08DD SurfCONTROLJSB Computer Systems Ltd 08B6 F-PROT Professional for NetWare 08DE SurfCONTROLJSB Computer Systems Ltd Command Software Systems 08DF SurfCONTROLJSB Computer Systems 08B7 Web Management Coffee Computing Ltd` 08B8 CNA Distributed Traffic Monitor Chevin 08E0 “HTTP-WebMail, ExpressIt!_2000 Infinite Software Engineering Ltd Technologies” 08B9 DS Gate Datastream International 08E1 “SMTP-WebMail, Infinite InterChange, ExpressIt!_2000 Infinite Technologies” 08BA VTD/X Gateway Micro-Matic Research 08E2 “POP3-Infinite InterChange, 08BB Salient Corp Salient Technologies Inc ExpressIt!_2000 Infinite Technologies”

08E3 “IMAP4-Infinite InterChange, 090F Omniguard/ESM Manager Axent ExpressIt!_2000Infinite Technologies” Technologies

08E4 “NNTP-Infinite InterChange, 0910 Omniguard/ESM Agent Axent ExpressIt!_2000 Infinite Technologies” Technologies

08E5 MPR for ISDN AVM GMBH 0915 Server Transfer System (STS) Prophet Systems Inc 08E7 Procomm Remote Control Quarterdeck Corp 0916 KeyServer Sassafras Software Inc

08E8 fiNDS Netoria 0918 Client/Server Database UMB Drecker GMBH 08E9 MyNet CKS Software Ltd 091A SNA Gateway Product (GAP Protocol) 08F1 Axis StorPoint Axis Communications Attachmate Corporation

08F4 Keylabs Automation Server Keylabs 091B “Control, Configure, Administer TCP and SNA nets IBM Corporation of Raleigh” 08F5 “LiftOff NewMoon Software, Inc” 0C29 License Profile Integrity Software 08F9 TSI Name Services Traveling Software Incorporated 0C2A Virus File List Integrity Software 08FA ITA Agent Axent Technologies 0C2C Global License SAP Integrity Software

08FC CD FORCE Procom Technology 0C31 License Report Definition / PlotterCalcomp

08FD CallWare TAPIserve CallWare 238C Meeting Maker XP On Technology Technologies 238D NLMOn Technology 08FE Yoda Extended Systems Inc 238E NLMOn Technology 08FF Communications Servers for Windows NT IBM of Research Triangle 8202 NDPS Broker Agent Novell - Provo Corp HQ 0909 Dash Network Phone System Dash Inc. 9620 License Profile Administrator Integrity SW 090A AutoXfer Platinum Technology FFFF All Types Novell - Provo Corp HQ 090C Network Scan Server Axis Communication 090D CD-Vision Ornetix

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.

Page 289 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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

IP/IPX Backbone

NetWare Server with NetWare Server with SCMD /bs /net=FFFFFFFC SCMD /bs /net=FFFFFFFD

Router Router IP only via the MA to MA Protocol IP only via the MA to MA Protocol

NetWare Server with NetWare Server with SCMD /bs /net=FFFFFFFC SCMD /bs /net=FFFFFFFD

IP and IPX IP and IPX

Dual Stack Clients

PC PC PC PC

Ethernet Segment Ethernet Segment

Dual Stack Servers

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 MA- to-MA protocol, or “Backbone support” feature.

Page 291 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 1. Using the customer’s LAN/WAN diagrams, including locations of servers, clients, and 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 related parameters deemed necessary in the design. 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.

IP/IPX Backbone

Router Router

IP and IPX IP and IPX

NetWare Server with NetWare Server with SCMD /bs /net=ABF02A14 SCMD /bs /net=ABF02A15

IP and IPX IP and IPX

IP/CMD Clients

PC PC PC PC NetWare Clients with NetWare Clients with CMD /net=ABF02A14 CMD /net=ABF02A15

Ethernet Segment Ethernet Segment

IP/CMD Servers

NetWare Servers with NetWare Servers with SCMD /net=ABF02A14 SCMD /net=ABF02A15

Dallas Sydney

This diagram shows the CMD "island" concept.

Figure J2. Full CMD Implementation Method 1. Using the customer’s LAN/WAN diagrams, including locations of servers, clients, and 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.

Page 293 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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 related parameters deemed necessary in the design. 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.

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.

Page 295 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. Page 296 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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)

Page 297 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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)

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.

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.

Page 300 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 301 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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?

Page 302 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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 :

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:

Page 305 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. Timesync Set Parameter to be Notes of the use of the set Recommendations Traffic Type used parameter Advertisemen Timesync service Set timesync service advertising = This server cannot be discovered using t advertising off eliminates all advertisement auto discovery; explicit configuration is Traffic traffic. needed to take time from this server. Recommended for IPX and not for IP. Discovery No set parameter This traffic is quite minimal anyway. Traffic can control this traffic. Time request Timesync polling Increase in polling interval may Polling interval may be increased up to traffic interval reduce traffic. 60 minutes. Increasing the interval Timesync Increase in synchronization radius beyond 60 is not recommended. synchronization may reduce traffic. radius Timesync polls 3 times (the default Synchronization radius depends on the Time polling count value of this parameter). A reduced kinds of applications that run on value will obviously reduce traffic. 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. Time Depends entirely on response request traffic. All traffic the set parameters that impact request traffic also impact response traffic.

TIMESYNC NLM, Transport Protocols, and Firewalls

What transport protocols does TIMESYNC NLM use? What are the port numbers used?

TIMESYNC NLM uses datagrams over IPX and IP.

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?

Page 306 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

Page 307 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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.

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.

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

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.

Page 311 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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.

Page 312 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. • 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

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.

Page 314 of 317 Novell PartnerNet Confidential 07/24/00 Copyright © 2000 by Novell, Inc. 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) To-Do: From the preliminary meeting.

Licensing Scheme

______is a customer for NetWare 5.1.

To-Do: From the preliminary meeting.

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: ______

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: ______