Novell is now a part of Micro Focus

Migrating to NetWare 4.11 Using the Across-the-Wire Method

Articles and Tips: article

Senior Software Engineer
Management Products Division

Software Engineer
Management Products Division

01 Oct 1996

Describes how to migrate a NetWare 3.x server to NetWare 4.11 using the new migration utilities included with the product.


In the past, the migration procedure to upgrade from bindery-based versions of NetWare (v2.x and v3.x) to Novell Directory Services (NDS)-based NetWare 4.x has been fraught with problems. This is no longer the case with NetWare 4.11 (also known as "Green River"). This latest release of NetWare includes a new pair of utilities that make upgrading to NetWare 4.11 as simple as installing a new application.

The first utility, DS Migrate, was written by Preferred Systems Inc. (PSI). It moves the NetWare bindery data--users, groups, queues, and so on--into NDS. DS Migrate appears as a Tools option in the NetWare Administrator (NWAdmin) utility and provides a subset of the features currently found in PSI's DS Standard. (See "Using DS Standard to Migrate Networks to NetWare 4.1" in the February 1996 issue for more information about the full-fledged DS Standard product.)

The second utility, File Migration, was written by Novell. It moves the file system information and associated data--attributes, trustees, restrictions, and so on--to the new server. For its migration engine, this utility uses the Storage Management System (SMS) libraries that Novell and third-party vendors use to back up servers. File Migration is thus built on top of a reliable, efficient, and thorough engine that has been used heavily in various complex conditions by thousands of customers over the years. You can be assured that every piece of information that can be associated with a NetWare file or directory will be brought over and correctly set up on the NetWare 4.11 server.

Our purpose in this AppNote is not to expose all the features available in these two utilities, but rather to show how simple the migration can be. Accordingly, we will demonstrate the use of the default configuration to move bindery information to NDS. Also, we won't cover the steps for migrating from NetWare 2.x servers, although DS Migrate does work with both NetWare 2.x and 3.x. Refer to the documentation that comes with NetWare 4.11 for information on the NetWare 2.x migration procedure.

Two Ways to Upgrade to NetWare 4.11

Novell privdes two methods for upgrading to NetWare 4.11: the In-Place method and the Across-the-Wire method. We will briefly describe both and then go into greater detail on the second method--the one we recommend.

The In-Place Method

For this method, you use the NetWare 4.11 Installation program (INSTALL.NLM) to install the new version of NetWare right over your existing 3.1x server. All the bindery information and file system information is upgraded in-place on your existing server. The sole disadvantage of this method is that if something goes wrong and you need to return to your previous version of NetWare, you must restore from a backup made prior to the installation of NetWare 4.11. Reverting to a previous version of NetWare can be very time-consuming.

The Across-the-Wire Method

For this method, you set up a new NetWare 4.11 server using new hardware, while the old server continues to function. Thus you have a source server and a destination server. Information from the existing 3.1x server is migrated to the new server using the DS Migrate and File Migration utilities, which are run from a workstation attached to both servers. You can keep the old server running until you've completed the migration. Since your 3.1x server remains operational throughout the migration process, you can continue to access information on it until you have verified that the migration was successful.

Note: If you have Microsoft Windows NT or Banyan VINES servers, NovellConsulting Services offers a product for migrating to NetWare 4.11 fromthese competitive products. Visit the Novell site on the World Wide Web( for more information about the Novell Consulting migration product.

Migrating to NetWare 4.11 Across-the-Wire

This section describes the actual process of converting a NetWare 3.1x server to NetWare 4.11 using the Across-the-Wire migration method. We have divided the process into ten steps. Each step is explained in detail below. (See the sidebar "Ten Easy Steps from NetWare 3.1x to 4.11" for a quick summary of the process.)

Ten Easy Steps from NetWare 3.1x to 4.11

Migrating to NetWare 4 is easier than ever with the two Across-the-Wire migrationutilities included with NetWare 4.11. DS Migrate and File Migration are bothaccessible as options under the Tools menu item in the NWAdmin utility.


  1. Plan your NDS tree.

  2. Install NetWare 4.11on a new destination server.

  3. Log in to the destination NDS tree and to the source NetWare 3.1x server.


  1. Start DS Migrate and run the Discover option to read the currentbindery information from the source server into an offline tree template.

  2. Model the offline tree by creating new containers, merging containers, combining duplicate objects, and deleting unneeded objects as needed to make the template match your planned NDS tree.

  3. Configure the live NDS tree with your offline tree.


  1. Start File Migration and select the source server to migrate fileinformation from the source to the destination.

  2. Select a source volume. You migrate files from one volume at a time.

  3. Select a destination directory including the server, volume anddirectory into which the file system information will be migrated.

  4. Migrate the file system data from the selected source volume to the destination directory.

Repeat Steps 7 through 10 for each volume on the source server.

Step 1. Plan Your NDS Tree

Perhaps the most difficult part of the whole process is laying out your Novell Directory Services tree. However, getting the tree designed right the first time is not as critical now that tools are available for merging subtrees and moving branches. Most companies find that their NDS trees will change over time. So keep in mind that you can always restructure the tree later if you need to.

You don't need to plan out the entire tree at this point. All you really need to decide is what the tree structure will look like above the container into which you will be placing the source server's bindery information. DS Migrate creates a couple of containers for you; you will need to rename them and add more container objects as needed.

For our example, we will have a simple NDS tree with three container objects. The structure of this tree is shown in Figure 1.

Figure 1: Our example tree has three container objects. The source server's bindery information will be placed in the Administration OU.

Step 2. Install NetWare 4.11 on a New Server

Follow the instructions in the NetWare 4.11 documentation to set up the new server. You only need to install the minimum number of objects required by the installation process. You'll fill in the rest of the tree later.

Step 3. Log In to Your Destination and Source Servers

Before you can run DS Migrate and File Migration, you must be attached to the appropriate servers. From a workstation, log in as Admin or Admin equivalent to the new NDS tree that contains your destination server, then set this tree as your preferred tree. You need Admin privileges on the destination to modify NDS and create the file system.

Also log in or attach to the source 3.1x servers as Supervisor or Supervisor equivalent. You need Supervisor privileges on the source to read all file system and bindery information. Because the file system can't filter Supervisor privileges, this is the only privilege that will not be masked off.

Step 4. Start DS Migrate and Run the Discover Option

Start the NWAdmin utility and select DS Migrate from the Tools menu. You are greeted with a splash screen, shown in Figure 2.

Figure 2: The DS Migrate opening screen.

If you would like to read more information about PSI or see a comparison of the features of DS Migrate versus the more full-featured DS Standard, click on the Preferred Systems Inc. or More Features buttons. Otherwise, click on the Continue button. You will see the DS Migrate main screen, shown in Figure 3.

Figure 3: The DS Migrate main screen.

Note: DS Migrate comes with a complete online help system that you should consultfrequently. Don't be concerned if you read about features that are not enabled inDS Migrate. Some of the options mentioned in the online help only work in thefull-fledged DS Standard product. PSI has tried to identify these differenceswhenever they occur.

PSI calls its method of reading the bindery the "discovery" process. To run this option, select File | New View | Bindery View (or click on the second button on the Button Bar). If you are not attached to any bindery servers, you will get a warning as soon as you select this. The utility will request a View Name and Author. These fields are for your convenience and are not used by DS Migrate. Generally you will use the source server name as the View Name. You can use your name as the author, or simply leave the Author field blank. In our example, we are going to discover a NetWare 3.12 server called OS312, so we will name the view OS312.

The next screen, shown in Figure 4, displays a list of bindery servers to which you are already attached.

Figure 4: The Specify Discover Parameters screen.

Select the 3.1x server you want to migrate. By default, all of the boxes under "Select Items to Discover" are checked. If there is information you don't want migrated, remove the check from the appropriate check box. (See the online help if you have questions.) Incidentally, "NNS" refers to NetWare Name Service, the precursor to NDS. If you have NNS you will know it; if you don't, it doesn't matter whether you check the box or not.

When you click OK, the system begins the discovery process. As the discovery proceeds, the information being discovered is displayed on the screen. When the discovery process is complete, the discover log is displayed for your review, as shown in Figure 5.

Figure 5: The PSI Viewer screen displays the discovery log file.

This log file can be helpful in determining if anything was not discovered. This file is saved as binddisc.log in the directory specified at the top of the file. Be aware that the log file may contain more than one set of information. The most pertinent information is always at the bottom of the file, so you may need to scroll to the bottom of the file to see the results from your current session.

If your system is low on resources and your bindery is large, you may not be able to view this file with the PSI Viewer. You can use another viewer, such as WordPerfect, to view the file as a text file. Close the log file viewer by double-clicking on the system menu.

Step 5. Model the Tree Offline

The next step is to manipulate or "model" the discovered tree to match how you want your live tree to look. During this modeling phase you can create new containers, merge containers, merge duplicate objects, delete unneeded objects, set up printing, and so on. The changes only affect the offline model at this stage of the migration process.

The template tree for the bindery server we just discovered is displayed, as shown in Figure 6. This simple template has an organization named Organization, with an OU object whose name is the source server name, OS312. We need to model the tree to match the one we designed in the planning phase (Step 1).

Figure 6: The discovered bindery objects are arranged into a simple template that you can modify to match your desired tree design.

We want our discovered bindery objects to be placed in the container .OU=Administration.OU=Sales.O=Novell. Therefore we need to perform several operations on the model tree.

5a. Add and rename containers to match the planned NDS tree. To match the planned tree, we first need to make a few changes to the container objects:

  • Rename the Organization object to "Novell". Renaming objects in DSMigrate is different from how it is done in NWAdmin. NWAdmin requires you to select the object you want to rename and then right-click the mouse to rename an object. In DS Migrate you rename objects by accessing the Details window and changing the name there.

    Double-click on the Organization object to display the Details window (see Figure 7). Change the name of the container from "Organization" to "Novell" and click OK.

  • Rename the OU container to Sales. Double-click on the OS312 OU objectand change the name to "Sales" in the Details window. Click OK when you're finished.

  • Create a new Administration OU object. Right-click on the Sales object and select "Add an Organizational Unit". Name the new OU "Administration".

  • Move the Administration OU under the Sales OU. Drag and drop the Administration OU onto the Sales OU. Check the "Add to Container" check box to add this new container to the Sales container.

Figure 7: You rename an object in DS Migrate by editing items in the Details window.

Note: Here's a little trick that will save youtime if you want to select multiple objectsand drag and drop them on another object.Mark the objects by clicking on them while holdingdown the Shift or Ctrl keys. As you markthe last item, press and hold down themouse button. You can now drag the entiregroup of objects and drop them on the destinationobject.

5b. Rename Server and Volume objects. If you are moving Print Queues, you need to tell DS Migrate where to store the queue directories. Print Queue objects have a Volume property that points to a Volume object on which the queue directories are to be stored. The Volume object has a Host Server property that points to a Server objecton which the physical volume resides. You must rename both the Volume and Server objects to match the destination server and volume in the NDS tree.

In our example, we need to rename the Bindery Server object OS312 to match the destination NDS Server object in the live NDS tree--in our case, OS411. We also need to rename the Volume objects to match those in the destination NDS tree as follows:

OS312_SYS to OS411_SYS OS312_TEST to OS411_TEST

If you are merging multiple bindery volumes into one NDS volume, combine the two objects by dragging one volume and dropping it onto the other one.

Note: If you don't have print queues stored on these volumes, you may simply delete theVolume and Server objects.

5c. Modify the Print Queue objects. Verify that the Volume property of each Print Queue object is set to the renamed Volume.

5d. Modify the login scripts. Modify the login scripts of each user and container as needed. Remember that the system login script is now stored in the container object.

Step 6. Configure the Live NDS Tree

The final process in the DS Migrate phase of our migration is to configure the objects into the NDS tree. To do this, select "Configure All Objects" from the View menu (there is no button on the button-bar for this option). This takes you through a two-step process of (1) verifying the changes you have made and (2) writing the changes to the live NDS tree.

During the verification phase, DS Migrate does a thorough pre-configuration check to be sure that the objects will configure properly. If there are problems, you will see a list of the warnings and errors before it proceeds. Once the pre-configuration process is complete, you must confirm that you want to configure the live NDS tree. Once you do so, DS Migrate proceeds to update the live NDS tree.

Note: Only one person can be running DS Migrate from the same server at a time. The DSMigrate database is not multi-user.

To prepare for the file system migration, DS Migrate creates a mapping file that maps bindery object names to NDS object names. This file must exist before you can run the File Migration utility to migrate the file system. Without this file, the file and directory trustee information would be lost.

Step 7. Start the File Migration Utility

Now that you have completed the migration of the bindery data to NDS, you are ready to move the file system information. The File Migration utility copies all files, along with their attributes, name space information, trustees, and so on, to the destination server. It does not delete or modify any files on the source server.

Like DS Migrate, the File Migration utility is also integrated into the Tools option of NWAdmin. Before you start the File Migration utility, there are a few preparations you need to make:

  • Files that users have open will not be migrated, so be sure all users are logged out from the source NetWare 3.x server. File Migration disables login automatically so that users can't log back in until the process is finished.

  • As previously mentioned, you must have already run DS Migrate to transfer the bindery information from its bindery format on the source server to the NDS format on the destination server. If you attempt to migrate the file system prior to running DS Migrate, File Migration will display a warning and will not let you proceed. Make sure you run File Migration on the same workstation that you used to run DS Migrate. Also, the drive mapping to the DS Migrate directory must be the same when running File Migration as it was when you ran DS Migrate.

  • You must already be connected to a source NetWare 3.1x server and a destination NetWare 4.11 server. You need Supervisor rights on the source server and Admin rights on the destination server.

  • You must load the appropriate SMS Target Service Agent (TSA) on your source NetWare 3.x server: TSA311.NLM on a 3.11 server, or TSA312.NLM on a 3.12 server. Prior to doing so, you need to copy the NLMs listed below from the NetWare 4.11 CD-ROM (PRODUCTS\NW3Xdirectory) to the source server (SYS:SYSTEM directory).

    NetWare 3.11 Source Server

    NetWare 3.12 Source Server



















  • If any of the volumes you are going to migrate contain non-DOS namespaces (such as MAC.NAM and OS2.NAM), be sure to load these name spaces on the destination volumes if you want to preserve the name space information.

  • If you are migrating volumes with Macintosh name space support and the MAC.NAM file is earlier than version 3.12, dismount the volume, unload MAC.NAM, and then load the 3.12 version of MAC.NAM (which you copied along with the TSA support files listed above). Then run VREPAIR.

Note: An early version of the NetWare MAC.NAM incorrectly permitted 32-characterMacintosh filenames when 31 characters is the true limitation. If you have Macintoshfilenames that are 32 characters long, you should rename them to 31 characters orless. The File Migration utility will chop the names off for you if you don't do so.

To start the file migration process, select "File Migration" from the NWAdmin's Tools menu. An easy-to-use wizard pops up, as shown in Figure 8. This wizard guides you through the steps of doing a file migration. We will highlight these steps and point out some things to watch out for.

Figure 8: The NetWare File Migration wizard guides you through the file system migration.

Note: If you have already run DS Migrate and you get the message that you must run DSMigrate before running File Migration, here is what may be happening. The path tothe DS Migrate directory, including the drive letter, is stored in the [PSI-DS Migrate1.0] section of the WIN.INI file in the Windows directory of the local workstation.You must run File Migration and DS Migrate from the same workstation, with thesame drive mappings. If the File Migration utility can't find the [PSI-DS Migrate 1.0]section in WIN.INI or it can't find the path referenced in the ApplicationPath entry,you will not be able to proceed with File Migration.

Step 8. Select a Source Volume

File Migration allows you to migrate whole volumes, one at a time. After you click the Next> button, File Migration gives you a list of NetWare 3.1x servers that you are connected to, as shown in Figure 9.

Note: If you realize that you are not connected to the right server, exit File Migration andconnect to that server. Then restart File Migration.

Figure 9: In this screen, you select the source server and volume from which you want to migrate files.

Once you have selected the desired source server, choose the volume you want to migrate files from and click on Next>. The next page prompts you for a password. Although you have already entered a password to connect to the server, you need to re-enter the password for security reasons to connect to the SMS TSA on the source server.

Step 9. Select a Destination Directory

After entering the password for the source server, you are requested to select the destination directory for the volume (see Figure 10).

Figure 10: In this screen, you select the destination server and volume to which you want to migrate.

You can select the root of the destination volume or any directory immediately off of the root. This arrangement is designed to help you avoid inadvertently migrating multiple source volumes all into one location. Of course, you might want to migrate two source volumes to the same destination directory. Obviously, this has the potential for filename conflicts. But don't worry; File Migration never overwrites files or directory entries. If you try to migrate a file to a directory where a file of the same name already exists, File Migration automatically renames the second file and writes a message to the log file with the new and old names.

Note: If you want to migrate to a directory that doesn't already exist, you must exit FileMigration, create the directory, and then restart File Migration.

After selecting the destination directory, the wizard prompts you for a password to your destination server. Enter the Admin password.

Before actually migrating the files, the wizard validates your selections. It will make sure that:

  • You are connected to a proper source and destination server.

  • You have the appropriate rights.

  • You have already run DS Migrate. You must be sure that the drive mapping to the DS Migrate directory (located in SYS:SYSTEM/DSMIGRAT on the NetWare 4.11 server) is the same when you run File Migration as it was when you ran DS Migrate.

  • You have rights to open and write to the log file. The log file is stored in the destination directory and is called migrate.log.

  • You have the appropriate name spaces loaded on the destination volume to match the name spaces on the source volume. If you don't care whether you maintain the name space information, you may proceed without correcting this problem.

  • You haven't added users or groups in the bindery since running DSMigrate. If you have updated the bindery since running DS Migrate (for example, deleted or added users or groups), File Migration displays awarning screen. If you have added users or groups after running DSMigrate, those users and groups will have to be migrated manually.

  • You haven't moved or deleted users and groups in NDS prior to after running DS Migrate and before running File Migration. File Migration attempts to find all of the NDS objects associated with each bindery user and group. You should not move users and groups in the NDS tree prior to running File Migration. If you do, you will lose the trustee assignments associated with those users and groups.

Note: Again, be sure you have loaded TSA311.NLM or TSA312.NLM on the sourceserver. (This is a crucial step that is easy to overlook.)

Step 10. Migrate the File System Data

After the validation process is complete, File Migration displays a screen similar to the one in Figure 11. If everything checks out, click on the Migrate button to proceed with the actual file system migration.

Figure 11: The File Migration utility alerts you to possible problems before proceeding with the actual file system migration.

During the file migration, a progress window displays the filenames as they are migrated.

You can cancel file migration at any time by clicking the Cancel button. This brings up a confirmation window. If you confirm that you want to cancel the migration, all the files that have been copied up to that point will remain on the destination server. If you begin the file migration again without deleting the files that were already copied, File Migration will rename the duplicates.

When the File Migration process is finished, a completion screen is displayed (see Figure 12). The message at the top will tell you whether or not the file migration completed successfully.

You should also review the log file, which contains information about any unexpected events that occurred during the migration, such as file renaming or name space incompatibilities. Since only the last 48KB of log information is displayed in the File Migrate viewer, we highly recommended that you open large log files using a separate word processor or text editor.

Note: Certain directories and files are not migrated by the File Migration utility. SeeChapter 3 of the Upgrade Manual for more information.

Figure 12: This screen appears to let you know the file system migration is complete.

After reviewing the log file, you can either return and migrate another volume or exit the File Migration utility.

Other Options of DS Migrate

As mentioned at the outset, we have covered only a small portion of DS Migrate's features, which are in turn only a small part of the larger DS Standard product. We wanted to demonstrate what a relatively easy process it is to convert from NetWare 3.1x to NetWare 4.11. Here's a brief look at some of the other features you can take advantage of:

  • Full object editing capabilities

  • Search and replace features

  • Template objects

  • Object merge

  • Tree merge

  • View merge

  • Configuration options

  • Merge options

See the DS Migrate online help for information about these features.


This AppNote has shown that migrating to NetWare 4.11 can be a relatively simple procedure. If you have been waiting to make the move to NetWare 4.x, hesitate no longer. The DS Migrate and File Migration utilities included with NetWare 4.11 make migration easier and more reliable than ever before. The enhanced features of NetWare 4 and the advantages of NDS await you.

* Originally published in Novell AppNotes


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