Novell is now a part of Micro Focus

Planning for NetWare 4.0 Installation, Server Migration, and Coexistence

Articles and Tips: article

MORGAN B. ADAIR
Senior Consultant
Systems Research Department

RENA R. JAMES
Lab Integration Technician
Systems Research Department

01 Apr 1993


Before you begin installing NetWare 4.0, you must spend some time planning and preparing your network. This AppNote will make you aware of some of the issues you must consider and the preparatory steps you should take before installing. Particular emphasis is given to the process of migrating from NetWare 2.x/3.x to NetWare 4.0. This AppNote also discusses issues related to the coexistence of NetWare 4.0 and previous versions of NetWare on the same network.

Introduction

When most sophisticated computer users receive a new software package, they tear open the box, put Disk 1 into drive A, and run INSTALL. If they open the manual at all, they pass over the introduction and go directly to the Installation chapter.

NetWare 4.0, however, is a powerful network operating system that requires considerable planning before installation. This AppNote will help you:

  • Make decisions regarding the organization and management of your network.

  • Prepare existing NetWare 2.x or 3.x servers for upgrade (migration)to NetWare 4.0.

  • Select hardware for new NetWare 4.0 file servers.

  • Select an installation method.

  • Collect information you will need when upgrading to or installing NetWare 4.0.

  • Manage the period of time when you have both NetWare 4.0 and NetWare 2.x or 3.x servers operating on your network at the same time (coexistence).

Go Back to Start

Before beginning the installation planning process, you should be familiar with NetWare Directory Services (NDS), have read the AppNotes on NetWare Directory Services in this issue, and have a diagram of your planned Directory tree.

Before you proceed from designing your Directory tree to installing NetWare 4.0, your Directory design should be detailed enough that you can answer the following questions:

  • Where will each file server be located in the Directory tree (that is, where will each file server's leaf object be located in the Directory)?

  • How will you partition your Directory tree?

  • Which file server in each partition will hold the partition's Master replica?

  • Which file servers in each partition will have Read or Read/Write replicas?

  • What time service will each file server provide (Single Reference, Reference, Primary, or Secondary)?

Installation, Migration and Coexistence

There are so many ways to install or migrate to NetWare 4.0 that we have written a large portion of this AppNote to help you choose which method you need. But first, let's clarify a few terms:

  • Installation is the process of setting up a new NetWare server.

  • Server migration is the process of moving an existing NetWare 2.x or 3.x server to NetWare 4.0.

  • Coexistence is the period of time in which a network operates with NetWare 4.0 and previous versions of NetWare.

We use the term "migration" (rather than upgrade) because upgrading a program usually consists of deleting the original program and installing the new version. By contrast, migrating to NetWare 4.0 involves transferring bindery objects to corresponding Directory Services objects; upgrading file server volumes from NetWare 2.x or 3.x to 4.0 (while preserving their contents); installing new utilities, NLMs, and drivers; and installing new server software.

To avoid confusion, we should also alert you to the fact that NetWare 4.0 has another type of migration: data migration. Data migration is a feature in which data that hasn't been accessed in a certain amount of time is moved to a storage device such as optical disk or tape, freeing up space on your server's hard drive.

(For more information about data migration, refer to the "Overview of NetWare 4.0 New Features" AppNote in this issue and to the NetWare 4.0 documentation.)

Near the end of this AppNote, we provide a list of tips and guidelines that will make the coexistence period more manageable. Despite the fact that we discuss coexistence after installation and migration, if you plan to have a mixed NetWare 4.0 and 2.x/3.x network (and many organizations will have an indefinite coexistence period), you should read the section on coexistence before installing or upgrading any file servers to NetWare 4.0.

Network Planning

General Directory tree design principles are discussed in the Directory Services AppNotes in this issue. In addition to those, a number of practical issues, most of them related to NetWare Directory Services (NDS), must be considered before you begin installing or migrating your network. The following pages list a number of these issues, and give you information that will help you arrive at the best solution for your network.

Decide Who Will Manage Your Tree

One of the first decisions you will need to make is who will manage your Directory:

  • One central group, perhaps an MIS group, can administer the entire tree.

  • One central group can administer the top levels of the tree and an administrator from each group (division, department, etc.) can manage the group's organizational unit.

Using one central group to control the entire Directory is a good method if you want someone to keep strict control of the Directory. This would not work very well in a company where different groups are used to having complete control over their own servers.

One central group (perhaps a single individual) is needed to administer the top level of the tree, regardless. Someone needs to be responsible for keeping the structure of the tree organized. For example, this group could have the authority to create the top level of Organizational Units and give the management of these containers to members of other groups.

If you decide to give members of different groups authority over the containers for their groups, you should consider creating a "Container-Admin" User object for each container and give that user all rights to the container.

Directory Services Naming Conventions

Your Directory tree will be easier to use and manage if you establish standards for naming objects in the Directory. For example, user names could be the same as E-mail names. Names of printer objects in the Directory could be abbreviations of the printer type and location. For example, a printer object for an Apple LaserWriter located on the second floor of building C could be named APL_C2. An HP Laserjet III at mail stop E-23 could be named HPL3_E23.

An example of a NetWare Directory Services "Naming Standards" document is given at the end of the "Planning a NetWare 4.0 Directory Tree" AppNote in this issue.

Partition Management Planning

NetWare Directory Services is implemented as a distributed database. NDS does not require you to store the entire database on a single server, and parts of the database are replicated on servers throughout the network. The replicated units of the Directory are referred to as Directory partitions(not to be confused with disk partitions).

Each Directory partition consists of a container object, all objects contained in it (possibly other container objects), and all data about those objects. Partitions only contain NDS objects and related data. They do not include any information about the file system or the directories and files contained there. Figure 1 shows the partitions of a Directory tree.

Figure 1: Partitions of a Directory tree.

A Directory partition is identified by the root-most object (the container closest to the root). So in Figure 1, partition ENG contains the organization unit called ENG and all the Directory objects under it in the tree.

NDS uses replicas of partitions to make the Directory fault tolerant. If a server that contains Directory information for a partition goes down, the information will be available from another server on the network.

Replicas can also be used to make your network more responsive to users. For example, if your network has WAN links, you can use replicas to prevent users from routinely having to traverse the WAN to get Directory information.

There are three kinds of replicas:

  • Master (each partition has only one Master replica)

  • Read/Write

  • Read Only

Partition Management Defaults

NetWare 4.0 has a default partition management scheme that results from how the Directory Services part of the installation process works. When you install the first server in a tree, the INSTALL NLM creates the Root partition and places a Master replica on the server. Because there are no other servers in the tree, the Root partition is not replicated on any other server.

When you bring up the second server in the tree, INSTALL asks you for the Directory context of the new server. If you enter a context that differs from the Directory context of the first server, INSTALL creates a new partition, stores a Master replica on the new server, and a Read/Write replica on the first server, as shown in Figure 2.

Figure 2: Default partitions with two servers.

As you add servers to the tree, you will either install each server into an existing context or you will create a new context. If you add a server to an existing context, INSTALL asks you if you want a Read/Write replica of the partition into which you are installing the server stored on the new server.

If you create a new context, INSTALL creates a new partition, stores a Master replica of the new partition on the new server, and stores a Read/Write replica on the server containing the new server's parent context. Partitions and replicas in your Directory tree will be similar to those in Figure 3.

Figure 3: Default partitions with several servers.

The default partition management scheme is adequate for small organizations, and for many medium-sized organizations - particularly those that are based at one location (no WAN links) and which have simple Directory trees.

Under the default partition management scheme, if you have a wide, flat tree, with 20 Organizational Units below the Organization container, your root server will hold the Master replica of the Root partition, plus 20 Read/Write replicas of the partitions below it in the tree (see Figure 4). Managing that number of replicas could impact performance of the root server.

Figure 4: Using default partitions in a wide, flat Directory tree could affect the performance of the root server.

Another flaw in the default partition management scheme is that it doesn't guarantee that the Root partition will be replicated. If you install only one server at the context in which you install the first server, there will only be the Master replica of the Root context. You should assure that the Root partition is replicated, either by installing another server at the same context, or by replicating it with one of the partition management utilities (PARTMGR or the Partition Manager function of NWAdmin).

In many organizations, a central group will manage the upper levels of the Directory tree, and grant the right to manage lower levels of the tree to administrative users at the division or department level. When an administrative user installs the first server into a new Organizational Unit, the INSTALL NLM creates a new Directory partition and attempts to replicate the partition in the new partition's parent partition (refer back to Figure 3). Because the user installing the server has not been granted rights to create Directory partitions in the parent partition, INSTALL will fail during the Directory Services part of the installation process.

To prevent this from happening, do the following:

  1. Run NETADMIN or NWADMIN and create the new Organizational Unit in its proper place in the Directory tree.

  2. Run PARTMGR or select the Partition Manager menu option in NWADMIN.

  3. Select the Directory partition you just created and select the Modify Partitions option. The utility will display a message asking you if you want to create a new partition. If you select "Yes" to confirm, the utility will create a new partition and store a master replica of it on the root-most server in the parent partition, and read/write replicas on every server that stores replicas of the parent partition.

  4. When the administrative user of the new partition installs the first server into the partition, the INSTALL NLM will ask "Do you want to create a partition replica on the new server?" If the administrative user selects "Yes,"a read/write replica of the partition will be placed on the new server.

  5. After the new server is installed, you can use PARTMGR or NWADMIN's Partition Manager to change the read/write replica on the new server to a master replica (if desired).

Note: Whenever you make a significant change to the Directory (like adding a server or replicating a partition), you should allow the network to have some time to synchronize before you make further changes. For example, if you add a migrate a server to the Directory, you should wait before replicating the partition containing the new server. The amount of time you must wait depends upon your network configuration. If you have a 20 file servers in a single location, a typical waiting period might be 20-30 minutes. If you have many servers connected by WAN links, you should wait several hours between major changes to the Directory, especially if partitions are replicated on servers connected by a WAN link.

Servers with Designated Functions

When you are planning your NetWare 4.0 network, you may want to consider designating servers for specific functions. Some examples are:

  • User directories

  • Word processing

  • Database processing

  • E-mail

  • Applications

There are three important things to consider when designating functions for each server:

  • The physical layout of the network. Make sure there is a server for each application "near" enough to the users who need to use those applications.

  • If too many users map to a server to access an application, performance can be significantly degraded. Instead, copy the application on another server. (Make sure you follow the licensing agreement for the application.)

  • The copy of NetWare installed on each server must have sufficient user licenses for the number of users who are concurrently attached to the server.

When you have a large network, you will probably have a server in each area (building, floor, or location) for each designated purpose. Create groups of users who will access the application in each area and use the group name to map a drive to the correct location of the application.

Network Addressing

By default, the NetWare 4.0 INSTALL NLM generates random network addresses (internal IPX addresses and cable segment addresses). INSTALL verifies that these randomly-generated addresses are unique within your network. The result, however, is less than ideal for large organizations.

Your network will be easier to manage if you have a system for assigning network addresses. Each new cable segment could be assigned an address before it is installed. Divisions or departments in your organization could be assigned ranges of addresses, so that network administrators do not have to contact a corporate IS department every time they have to bring up a new server.

Ethernet Frame Type

Novell first implemented local area networking on Ethernet before the IEEE formalized its 802.2 data-link layer standard. Novell's implementation of 802.3 Ethernet (referred to as 802.3 Raw frame type) is incompatible with the 802.2 standard.

NetWare now supports a number of Ethernet frame types. There are a number of advantages to using the 802.2 frame type (which actually consists of the 802.2 data-link layer encapsulated in the standard 802.3 frame):

  • It is a standard. You will have a greater selection of compatible bridges, routers, and other network products. It is also acceptable to government installations where adherence to standards is required.

  • It allows checksumming. IPX packets in a 802.3 Raw frame have 0xFFFF in the first two bytes of the data field. The 802.2 standard specifies a field that identifies the protocol, so the first two bytes of the data field can be used to send a checksum. Checksumming assures that a packet has arrived unchanged.

  • It enables the use of 802.2 diagnostics. Some 802.2 diagnostic packets are indistinguishable from 802.3 Raw packets. Using the 802.2 frame type enables you to use the diagnostics specified in the 802.2 standard.

  • It lets you use MAC layer bridging. Media Access Control (MAC)layer bridges are able to transfer packets from Ethernet to Token Ring networks.

We recommend that you use the 802.2 frame type wherever possible.

When you install NetWare 4.0, INSTALL will by default enable support for both the 802.2 and 802.3 Raw frame types. It will also make the appropriate entries in AUTOEXEC.NCF to support both frame types whenever the server is loaded. When you load an Ethernet driver from the server command line on NetWare 4.0, the driver will use the 802.2 frame type unless you specify otherwise.

If other servers are configured only for 802.3 packets, and workstations on your network are configured for 802.2, your newly-installed NetWare 4.0 server can act as a router between the workstations and the servers that are not yet configured for 802.2 packets.

Your network might have third-party routers that are unable to route 802.2 packets. If so, when installing the server's LAN drivers, specify that only 802.3 frames are to be used. If you are unsure, check with the router manufacturer before installing NetWare 4.0 on your network.

Workstations or Servers First?

NetWare 4.0 requires new client software before client workstations can take advantage of NetWare Directory Services. PCs can still log into a NetWare 4.0 using the NetWare shell (NETX) under bindery emulation, and PCs running the new NetWare client (VLM) can log into NetWare 2.x and 3.x file servers. This leads to the question, should you upgrade your servers or workstations first?

Figure 5 illustrates the two basic approaches.

Figure 5: Server and workstation installation order.

We recommend that you upgrade your workstations first. Because you have made the investment of time and resources to move to NetWare 4.0, you will want to take advantage of its features as soon as possible. Besides, bindery emulation has a number of limitations that make it less flexible and powerful than NetWare Directory Services. These are described below.

Limitations of Bindery Emulation. Some of the inherent limitations of bindery emulation are:

  • Users logging in under bindery emulation must have user names that conform to bindery object specifications (up to 47 characters, no spaces, slashes, backslashes, colons, semicolons, commas, asterisks,or question marks).

  • Users logging in to the network under bindery emulation will not be able to access Directory Services information that is not in the bindery (E-mail name, phone number, or print job configurations, for example).

  • Users cannot log in under bindery emulation to a NetWare 4.0 file server that does not have a writable replica of the Directory partition in which it resides. This is not a problem if you use NetWare 4.0's default partition management scheme, but for performance reasons you may want to manage your Directory partitions differently.

Figure 6 illustrates how bindery emulation fits into the default partition management scheme.

Figure 6: Bindery emulation and partition management.

Interim NET.CFG Parameters. When you install the client software on your workstations, you should set the PREFERRED SERVER in the NET.CFG to the server the client will log in to. You can also set the NAME CONTEXT value at this time, even though you have not yet migrated your 2.x/3.x server to 4.0. VLM will ignore this setting if the preferred server is bindery-based.

If you will have more than one Directory tree on your network, you will also need a PREFERRED TREE statement in NET.CFG. When this statement is in NET.CFG, however, VLM tries to attach to the specified Directory tree before looking for the preferred server.

This can create problems during the migration process, when you have upgraded some servers to NetWare 4.0 (and have created part of your Directory tree), but have not migrated the server named as preferred server in some users' NET.CFG files. These users will attach to a server in the Directory tree rather than the server specified as preferred server. They will be able to log in to their preferred server by specifying the name of the server on the LOGIN command line, but the difference may cause confusion for some users. You might want to comment out the PREFERRED TREE statement until the preferred server has been migrated to NetWare 4.0.

For more information on VLMs and NET.CFG settings, see the "Using the DOS Requester with NetWare 4.0" AppNote in this issue.

Preparing a NetWare 2.x/3.x File Server for Migration

Before you migrate a NetWare 2.x or 3.x file server to NetWare 4.0, there are a number of preparatory steps you can take to make the resulting Directory tree closer to what you have planned.

Cleaning Up the Bindery

Most of the preliminary steps you should take fall under the category of "cleaning up" the bindery on the server to be migrated. These steps are described below.

  1. Change the names of users, printers, and print queues to conform to the standards you have set for Directory objects (if the standards are compatible with the naming requirements for bindery objects). Users can begin to become accustomed to the new object names before the server is migrated.

  2. Delete obsolete bindery objects: users who no longer exist, unused print queues, and soon. Two utilities named PRINTUSR and PRINTGRP are available on CompuServe's NetWire forum (GO NOVLIB) to help identify obsolete objects.

  3. Check for bindery objects with the same name, but of different object type-for example, both a group and a print queue named MAC. We have provided a utility program that will scan a server's bindery for duplicate bindery object names. The utility, DUPBIND, can be downloaded from NetWire (GO NOVLIB).

  4. Before migrating your 2.x/3.x server, back up the file system and run BINDFIX. If BINDFIX repairs problems in the bindery, back up the file system again before migrating.

  5. Check for users who have accounts on multiple 2.x/3.x servers. You will have to deal with this problem at some point in the migration process.

    If both servers are being installed into the same partition, INSTALL will list the users with duplicate names and ask you if you want to rename the user on the second server migrated, or if you want to merge the two user objects. If you merge the users, properties (such as login scripts) on the first server migrated take precedence.

If the two servers are being installed into different partitions, you will have two user objects with the same name in different contexts (see Figure 7). The user will be able to log in at either context and have different parts of the Directory tree visible in each one. If the user really belongs in both contexts, you can solve the problem after both servers are migrated by deleting one user and creating an alias of the other.

Figure 7: One user represented by two user objects in different contexts.

Login scripts also require some attention before you start to migrate servers. When two 3.x file servers are migrated to the same Directory context, if a user has a login script on both file servers, only the login script on the first server upgraded will migrate to the Directory (see Figure 8).

Cleaning Up the File System

If you are doing an in-place migration, the INSTALL program will need about 50 MB free disk space on volume SYS for temporary storage during the migration process (less if you have few users and other bindery objects). While freeing disk space for migration, you might also want to delete any obsolete directories from the file system.

Be sure you back up the file system just before migrating your server.

Figure 8: Migrating login scripts.

NetWare 4.0 Hardware Requirements

NetWare 4.0 servers must be 386 or 486 PCs. If you are on a medium- to large-sized network, we strongly recommend that your root server be a 25 MHz (or faster) 486 PC. (The first server you create is the root server.)

The root server needs to be relatively fast because it will hold your root container object and (usually) the Master replica of your organization's root-most partition. Users logged in to a server on a sub-partition that map a drive to a server on a separate sub-partition will have to access the root server. All this is transparent to the user, but the root server needs to be fast so performance won't be degraded. In addition, you should have:

  • A minimum of 8 MB RAM (see "Estimating RAM Requirements," below).

  • One or more internal hard disks or external disk subsystems with sufficient disk space for your network (see Estimating Disk Requirements," below).

  • One or more network interface cards.

  • A tape drive or other backup device, either on your file server or on your network.

Another important attribute of a file server machine is that its internal clock should keep accurate time. This is not a problem with most computers, but because correct time stamps are so critical to the operation of Directory Services, you should verify the accuracy of your server's clock (before installing NetWare 4.0 on it) by comparing it to an accurate time source over a 24-hour period.

(See the "Time Synchronization" section in the "Introduction to NetWare Directory Services" AppNote for more information).

Estimating RAM Requirements

Use the following formula to approximate the amount of RAM (in megabytes) you need to have in your file servers:

5.5 + (2 x A) + (.008 x D) + (5 x F / 1,048,576) + C + O

where

  • A is 1 if you plan to install PSERVER or any NLM that uses CLIB.NLM or BTRIEVE.NLM. If you will not load any of these NLMs A is zero.

  • D is the number of megabytes of disk space on the file server.

  • F is the number of files that have an additional name space entry (MAC or FTAM, for example). If you have multiple name spaces loaded, F is the number of files on the volume times the number of additional name spaces (do not count the default DOS name space).

  • C is additional cache buffer memory for increased performance (pick a number from 1 to 4).

  • O is the memory required by other NLMs you will have loaded during normal server operation.

If you need a precise estimate, Appendix B of the NetWare 4.0 Installation and Upgrade manual gives a formula for precisely calculating server RAM requirements.

Estimating Disk Requirements

While it is possible to boot NetWare 4.0 from a floppy disk, you will probably find it more convenient to have a small DOS partition on your server's hard disk. You can boot DOS from the server's hard disk, then run SERVER.EXE. A 5 MB DOS partition is sufficient to store DOS (the system files, COMMAND.COM, and utilities), SERVER.EXE, STARTUP.NCF, and your file server's disk drivers (ISADISK.DSK, for example).

The following are the disk space requirements of various components of NetWare:


DOS/Windowsclient installation program

5 MB

OS/2 client installation program

5 MB

Login utilities (LOGIN directory)

2 MB

NetWare utilities (PUBLIC directory)

24 MB

System programs, LAN and disk driver(SYSTEM directory)

6 MB

On-line help (Novell ElectroText)

25 MB

If users on your network will normally access more than one file server, you may choose to install NetWare utilities or the on- line help system on only one file server. Doing so reduces the total amount of disk space required on your network, but increases the number of users that must attach to the file server where the utilities and documentation reside. However, this may require you to purchase, for example, a 100-user version of NetWare rather than a 50-user version.

Workstation Requirements

You can run NetWare 4.0 workstation software on any PC. As there is no Macintosh client software currently available for NetWare 4.0, Macintosh workstations must log in to NetWare 4.0 file servers under bindery emulation (see "Coexistence" near the end of this AppNote).

Installation Methods

NetWare 4.0 can be installed from a number of sources:

  • Floppy diskettes

  • CD-ROM on the server machine being installed

  • CD-ROM on an existing network server

  • Network disk

The installation program runs virtually identically, regardless of which installation source you choose. There are only a few things you need to consider as you prepare to install:

  • Cost. NetWare 4.0 will primarily be distributed on CD-ROM. If you must install from floppy diskettes, they are available for a small additional cost. Complete online documentation is also included on the CD-ROM, with a Microsoft Windows-based viewer. Printed manuals are also available at additional cost.

  • Installation time. If you plan to install or upgrade many servers, installation time can become a significant consideration. The time required to do a basic installation (including PUBLIC utilities, NLMs, and server LAN and disk drivers, but not on-line documentation) can vary considerably depending on installation source:


    Floppy diskette

    80 minutes

    CD-ROM

    40 minutes

    Network disk

    30 minutes

    These times are approximate and do not include time to back up or migrate existing file systems. In addition, installation from floppy diskette requires closer attention. About half of the time required to install NetWare 4.0 is spent simply copying files to the PUBLIC directory. When installing from CD-ROM or a network directory, this process canrun unattended.

  • LAN driver installation order. If you are installing from a network disk, the installation program must maintain its network connection during the entire installation process. This means that before you run INSTALL, you should know which of the new server's network interface cards is communicating with the server from which you will be running INSTALL. You must know the interrupt and port address settings for the card, so you can load the server driver for this card last. That way, the new server can maintain its connection with the server from which you are installing.

    Note: If you are installing over the network, you must install client software (a LAN driver, IPX, and either NETX or VLM) on the machine you want to install or migrate to NetWare 4.0, then log in to the server where the NetWare 4.0 installation files have been copied. Do not use a memory manager (such as HIMEM, QEMM, or 386MAX) when logging is as a client to run INSTALL.

New Installation

There are basically two reasons to do an original installation:

  • You are putting in a new NetWare network.

  • You want to keep your 2.x and 3.x servers as they are and install some new NetWare 4.0 servers.

Because NetWare 4.0 is so different from previous versions of NetWare, migrating an existing NetWare network to version 4.0 is much like planning a new NetWare 4.0 network. For this reason, we will cover both processes concurrently, and note when different actions are required, depending on whether you are migrating an existing network or installing a new network.

Migration

NetWare 4.0's server migration utilities are focused on allowing a company to gradually switch a large network from 2.x or 3.x to 4.0. The idea behind these utilities is that a company will not try to upgrade over a weekend. A large system cannot be changed in such a short period of time and shutting down long enough to do the upgrade is simply not feasible. In addition, network administrators and users need time to get used to changes in how the network operates.

Although it is beyond the scope of this report to address the issue, you can also migrate to NetWare 4.0 from IBM LAN Server. Look in the NetWare 4.0 manuals for more information.

Migration Methods

There are three methods of migrating a NetWare 2.x or 3.x system to version 4.0:

  • Across-the-wire to an installed 4.0 server

  • Across-the-wire to the same server

  • In-place

Below are brief descriptions of the different methods, along with the advantages and disadvantages to help you decide which method to use. Step-by-step instructions for each of these methods are given in the NetWare 4.0 Installation and Upgrade manual.

Across-the-Wire to an Installed 4.0 Server

To use this method you run the migration utility at a workstation attached to the original server (or servers) and a newly installed 4.0 server. Bindery information from the original server is migrated to the 4.0 server. Bindery objects are created as Directory objects in the 4.0 Directory tree and are placed in the same container with the server and server volume.

Advantages. The advantages of the across-the-wire to an installed 4.0 server method are:

  • There is no risk of data loss because the original server still exists with all of the information on it.

  • You can migrate multiple servers to a single server.

  • You can choose which data you migrate.

  • You can direct data to a volume or directory to keep the system files separate from the 4.0 system files.

Disadvantage. The only disadvantage of this method is:

  • You need additional hardware; namely, a NetWare 4.0 server.

This method is an excellent choice if you are planning to get new hardware for your 4.0 servers. If you are running NetWare 2.x on a 286 machine, you will need to upgrade to a 386 or 486 machine to run NetWare 4.0.

This method is also good if you want to merge data from several servers onto one server, or if you want to place bindery objects from several servers in one container. Remember that the maximum number of objects for one container is 1,000.

Across-the-Wire to the Same Server

To use this method, you run the migration utility at a workstation that has enough hard disk space to temporarily hold your data. The data and bindery information are migrated to files on the workstation's hard disk. You then run the 4.0 installation on the server. When the new 4.0 server is installed you migrate the data to the server and the bindery information to the Directory.

The migration utility does both of these tasks automatically. We have described it this way to keep the language consistent.

Advantages. The advantages of the across-the-wire to the same server method are:

  • You can choose which data you migrate.

  • You can direct data to a volume or directory to keep old system files separate from the 4.0 system files.

Disadvantages. The disadvantages of this method are:

  • There is some risk of data loss because the data on the original server is destroyed when NetWare 4.0 is installed.

  • You need a workstation with enough hard disk space. If you don't have one, you can migrate the bindery information to a workstation and restore data from your regular backup system.

In- Place on the Same Server

This method has different implementations for 2.x and 3.x servers. If you are migrating a server running 2.1x or above, you boot the machine from the In-place Upgrade floppy diskette, run the SERVER.EXE on this diskette, and load 2XUPGRDE.NLM. This will upgrade the bindery to 3.x.

You can then follow the same procedure as you would for a 3.x server, which is to run the 4.0 installation program. There is an option on the main menu to "Upgrade a 3.x server to 4.0".

Advantage. The advantage of the in-place upgrade method is:

  • You don't need any additional hardware in the form of a workstation or another server to migrate to.

Disadvantages. The disadvantages of this method are:

  • You can't do an In-place Upgrade from NetWare v2.0a or v3.0.

  • If the upgrade fails, you have to restore from your regular backup.

  • On 2.x versions of NetWare, the upgrade is a two-step process.

This is the best method if you want to upgrade the same server to 4.0 and you are running a version of NetWare 2.x above 2.0a or a version of NetWare 3.x above 3.0.

Information Required During Installation

NetWare 4.0's INSTALL program asks you for information at several points during installation. We have prepared a worksheet to help you collect all the information you might need to know when running INSTALL. The worksheet pages are found at the end of this AppNote, and they can be photocopied as needed.

Coexistence

Most organizations will not migrate their existing networks to NetWare 4.0 overnight, or even over a weekend. To accommodate those who need an extended period of time to make the transition, Novell has included some features in NetWare 4.0 that enable it to coexist on the same network with bindery-based versions of NetWare.

Bindery Emulation

NetWare Directory Services can emulate the flat structure of the NetWare 2.x/3.x bindery. This feature allows clients to log in using NETX or the current Macintosh client software. When bindery emulation is on, bindery-based clients or utilities will see all leaf objects in the server's bindery context as if they were in a bindery (see Figure 6 above).

The Common Name of all objects in the container set as the bindery context must have Common Names that conform to bindery conventions (up to 47 characters, no question marks, etc).

The NetWare 4.0 INSTALL program enables bindery emulation by default by setting the server's SET BINDERY CONTEXT parameter. You can turn off bindery emulation by executing the "SET BINDERY CONTEXT=" command at the file server console.

NetWare Server Objects

Bindery-based (2.x/3.x) servers can be added to the Directory tree as NetWare Server objects. This allows NDS users to access volumes on those servers the same as NetWare 4.0 volumes. Use NETADMIN or NWAdmin to create NetWare Server and Volume objects for the server you are adding to the tree.

Once you have started building your Directory tree, you might be tempted to set up user, printer, or other objects for a 2.x/3.x server before migrating the server. Doing so might result in your losing login scripts, passwords, and rights that are stored in the bindery. You should let the 4.0 INSTALL program migrate bindery objects to the Directory.

Conclusion

This is the conclusion

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates