Novell is now a part of Micro Focus

Migrating to IntranetWare from LAN Manager, NT Server, and LAN Server

Articles and Tips: article

KYRT NAY
Senior Consulting Engineer
Software Consulting Services

01 Apr 1997


If the prospect of switching from IBM LAN Server or Microsoft LAN Manager/NT Server networks to IntranetWare makes you nervous, relax! Novell Consulting has prepared a migration toolkit that does all the hard stuff for you.

Introduction

This AppNote presents information for system administrators who want to migrate LAN Manager, NT Server and LAN Server (LM/NTS/LS). This AppNote provides information you can use to non-destructively migrate these network operating systems across­the­wire to Novell NetWare 4.x.

System administrators who perform migration procedures are expected to have certain knowledge about NetWare 4.x network system administration and NDS directory tree design. In addition, you should be knowledgeable about the operating system that you will migrate.

Novell Certified NetWare Engineer (CNE) training or the equivalent knowledge is highly recommended before undertaking this migration. Before beginning, you should have any appropriate reference materials at hand. These include (but are not necessarily limited to) the NetWare 4.x documentation set, and any documentation regarding the operating system you plan to migrate.

Planning Your Migration

The first thing you should do is plan your migration. This is the most important task you will complete before actually migrating your operating system. Before beginning either the test migration or the full migration, you might want to consider the following suggestions while doing your pre­migration planning.

If possible, plan to migrate one domain at a time, unless your directory structure is very small. If you migrate domains one­by­one, you will be able to monitor the success of the migration, and if necessary, make revisions to your migration plan. Use the worksheets at the end of this article to help you plan your migration.

Standardize User Names

You will find implementation of E-mail and other services easier if your system uses a standard naming convention. For information, see "Create the Naming Standards for NDS," Section 2. 2 of your NetWare 4.1 Design and Implementation Guide.

  • Design and build your directory tree before migrating.

  • Before migrating take the time to clean up user accounts and groups that may no longer be needed, are invalid, or which are just taking up space.

  • For information about running multiple requesters, or sample CONFIG.SYS, PROTOCOL.INI, and NET.CFG files, see your NetWare Support Connections CD. See the section "Preparing the Migration Workstation."

Planning Your NetWare Directory Services Tree

Before you begin your migration procedure, you should plan your directory tree structure. This makes your job easier when you migrate to NetWare.

Your migration procedure will include a small, preliminary test migration (see "Performing Your Migration" later in this article). If you want, you can reintegrate the test migration data and files into the permanent NDS tree structure later. If you intend to do this, make it part of your planned tree structure before you begin migration.

For information about designing your NetWare Directory Services tree, refer to QuickPath to NetWare 4.1 Networks from Novell Press. The following table lists Novell Research AppNotes that might also be helpful to you.


Novell AppNotes
Part Number

April 1993

164­000032­004

June 1993

164­000032­006

July 1993

164­000032­007

September 1993

164­000032­009

October 1993

164­000032­010

November 1993

164­000032­011

January 1994

164­000036­001

February 1994

164­000036­002

Implement Unique Naming Conventions

Information about unique names is found in "Create the Naming Standards for NDS," Section 2.2 of NetWare 4.1 Design and Implementation Guide.

It is particularly important to rename different users that have the same user name, and an absolute must if those users will ultimately reside in the same NDS container.

Hardware Requirements

The following hardware prerequisites are assumed:

  • At least one NetWare 4.x Server with the NDS tree has been installed. This is the destination server.

  • A current LM/NTS/LS server exists. This is the source server.

Your source server can be any server version on the following list:

  • Lan Manager versions 2.0 or 2.2

  • Lan Server versions 2.x, 3.x, or 4.0

  • NT versions 3.5 or 3.51

Installing the NetWare 4.x Destination Server

Before performing your test migration, make sure your NetWare 4.x destination server is installed and configured correctly. (See Installation and Upgrade manual #100­001414 for specific installation instructions.) When planning and configuring your destination server:

  • Add configuration information that might not be included in the M/NTS/LS migration, such as additional Admin level users.

  • Determine the storage system requirements for the completed migration. If this migration is to combine multiple LM/NTS/LS servers into one NetWare 4.x server, make sure the disk space is sufficient to handle all of the storage system needs for all of the servers.

  • Consider the custom or operating system­specific applications that you will replace with NetWare versions, such as database and backup programs. Install and test the new versions before performing the migration.

  • Determine the backup software you will use.

  • Install any patches required.

Configuring the Destination Server

Consider the following as you configure your destination server:

  • If you merge two or more LM/NTS/LS servers to the same NetWare 4 server, plan for sufficient free disk space. You will require a minimum of:

    80 MB (for Volume SYS:)

    15 MB DOS partition

    8 MB RAM

  • Create the volumes that you want to migrate data to. You cannot create volumes from within the Migration utility.

  • Make sure the destination server has a unique name.

  • Ensure that the latest versions of the NetWare 4.1 NLMs have been loaded (e.g., DS.NLM, DSAPI.NLM, CLIB.NLM).

Preparing the Source Server

Before performing your test migration or your full migration, you must do some work on your existing source server. Complete all the steps below before beginning any migration process.

  1. Use your backup utility to back up your current LM/NTS/LS server. To ensure a good backup, make at least two copies. Because server migration is non-destructive the source server will be left intact providing another level of disaster recovery.

  2. Log out all users except one. This one must have Admin rights.

  3. Make sure all files are closed before migration. (Any files open during a migration are not migrated. However, since the files are not destroyed during the migration, if necessary, you can copy them after the migration is complete.)

  4. Clean-up and delete any unused or unnecessary files and directories. Consolidate files and directories as appropriate. This will allow for shorter data migration times and use less disk space.

  5. Decide if you want to migrate .BAK, .TMP, or .LST files, or any other temporary files. Delete any of these files that you do not wish to migrate.

  6. NetWare 4 sets the default for subdirectory depth to 25 levels. If the source server has subdirectories deeper than 25 levels, you must change the SET parameter "Maximum Subdirectory Tree Depth" in the STARTUP.NCF file on the NetWare 4.x server so that the setting will accommodate the subdirectory depth being migrated (see the SET command in NetWare Utilities Reference. #100­001416­001).

  7. Remove any unneeded user accounts and groups.


Note: If the source server is an NT Server make sure that the server is enabled to receive LanManager type requests. Go into Control Panel, click on Network,then click on Server. On the bottom of the dialog box is a checkbox which enables the NT Server to receive LAN Manager requests.

Preparing the Migration Workstation

The workstation where you will run the LMIGRATE.EXE migration utility must be an OS/2 Warp workstation with the latest requesters loaded (LS 4.0 and NetWare Requeste for OS/2 2.11). Make sure the following requirements are met:

  • Make sure you have 20 MB free space.

  • The migration utility needs concurrent access to both the source and destination servers. Dual requesters must be loaded; the native requester provided with the source server's operating system, and the corresponding OS/2 Novell NetWare requester. The OS2MIG.EXE utility may be used to add OS/2 NetWare requester support to the workstation.

  • With both requesters loaded, login to both the source and destination servers that will be included in the migration. Ensure that you login to the correct domain and correct NDS tree and that the servers used in the migration are the only servers you are logged into.


Tip: To increase data copying speed, consider installing high­performance NIC cards.

he migration toolkit utilities will not load if you are running a version of OS/2 lower than 3.0 (Warp).

Software Requirements

Before beginning your migration procedure, you should have certain software on hand. The following utilities packages are found in the Novell Migration Toolkit CD:

  • LMIGRATE.EXE

  • WINMIG.EXE

  • WINCFG.EXE

  • LANMAP.EXE for Windows

  • OS2MIG.EXE

  • OS2CFG.EXE

  • LANMAP.EXE for OS/2

  • SAMBA.NLM

  • NTAGENT.EXE

  • OS/2 Requester

  • NT Client Requester

  • Client 32 Requester for DOS/Windows

What the Toolkit Utilities Do

Depending on the operating system you intend to migrate, you will use different utilities found on the toolkit CD. The following sections describe each of these utilities and what they are used for.

LMIGRATE.EXE is used to migrate:

  • Existing domain objects such as users and groups to a NetWare server. You will run this utility once for each domain to migrate domain objects from the Primary Domain Controller (PDC).

  • Existing file system data to a NetWare server.

  • The access rights of users and groups to their data.

WINMIG.EXE, OS2MIG.EXE. Both of these operating system­specific utilities aid migration of the respective client workstation. The appropriate utility is run at individual workstations to install NetWare client software on the workstation, and can replace or coexist with the existing network client software. Utilities for creating different configuration files for various network interface cards are also included. These utilities are discussed in detail in the client migration section. Planning should include distributing the new NetWare client software to the LM/NTS/LS clients.

SAMBA.NLM. SAMBA.NLM is optional. Run SAMBA.NLM and support NLMs on the NetWare 4.x server to enable LM/NTS/LS clients to receive file and print services from NetWare. The SAMBA.NLM functions as a share emulation server on the NetWare 4.x server to process file system and printing requests from LM/NTS/LS clients. This is after users, groups, and data have been migrated from the source server, but before the workstation's networking software has been migrated to the NetWare client. This share emulator supports the NetBEUI, TCP/IP and IPX protocols.

NTAGENT.EXE. When migrating from NT Server, in order to obtain local groups and the access rights associated with directories and files, this server agent must be loaded on the NT server. Without this agent the LMIGRATE.EXE utility will run normally but will not be able to obtain either local groups nor user access rights associated with directories and files.


Note: HPFS and FAT file systems on NT servers do not support access control permissions at the file and directory level. Therefore access control for NT server migration is only done for NTFS volumes.

NetWare OS/2 Requester. The NetWare OS/2 Requester is included as part of the OS2MIG.EXE utility to provide OS/2 workstations with NetWare client support.


Tip: The OS/2 Requester can be installed by the OS2MIG.EXE utility on OS/2 client workstations.

NetWare NT Client Requester. The NT Client Requester adds NetWare client support can be added for NT workstations.

NetWare Client 32 for DOS/Windows. This is the client software that is installed on DOS/Windows workstations by the WINMIG.EXE utility. There might be some clients you will need to update by hand. Sometimes, these are clients that do not have standard or well­known network interface cards (NICs). Sometimes the CONFIG.SYS and/or AUTOEXEC.BAT files have been modified in such a way that the upgrade utilities cannot make the correct modifications.

Test one copy of each client configuration prior to beginning the migration process. This will help you learn to correct problems should they arise during the migration procedure.

Additional Software Considerations

In addition to the files included with the migration toolkit, you should have on hand the NetWare versions and/or NetWare drivers for such software products as:

  • Backup utilities

  • Database applications

  • LAN Security programs

  • E-mail-Migration--planning should include a provision to maintain connectivity for your E-mail system and ensure uninterrupted E-mail delivery for your users during migration

  • In­house software applications-When you migrate to NetWare, your current versions of custom client/server applications might not work. Check with your in­house developers to make sure that your applications will run on NetWare

  • LAN Adapters

Installing the Migration Utilities

All the tools needed for the migration process should have been completed previously by following the instructions in the README.TXT file. If you plan on using the share emulator there is one more step that needs to be completed. Copy all the *.NLM and *.NCF files in the SAMBAand LMIGRATE sub-directories in the MIGTOOLSdirectory to the SYS:SYSTEM directory on the destination server. Create a SYS:SAMBA directory and copy all other files from the MIGTOOLS\SAMBA directory to the SYS:SAMBA directory. Once this is completed the instructions in the following chapters will explain how these are to be used.

Migration Using the Across-the-Wire Method

Migration is performed using the across­the­wire method. Across­the­wire migration means that the data files are migrated directly across the network from the source server to the destination server. This method is non-destructive and preserves your users, permissions, account information, and file system data on the source server.

The Migration Process

The migration process includes the following steps (Share Emulation Server Support is optional):

  1. Domain Object Migration (Users and Groups)

  2. File System Migration (including access rights)

  3. Share Emulation Server Support

  4. Client Migration

Domain Object Migration. Once the source server, destination server and the migration workstation are prepared the first step in the actual migration process is to run the LMIGRATE.EXE utility and migrate the domain users and groups. This step only needs to be done once per domain and migrates the domain object types (e.g., users and groups) to a NetWare 4.x NDS context.

There are at least two possible methods of doing this:

  1. Create a one­to­one relationship between a domain on LM/NTS/LS and an NDS context. By doing this each domain would be migrated to a specific NDS context thereby maintaining a functional tree structure.

  2. If your users have the same user name on multiple servers you may want to migrate all the domains into one NDS context. This will consolidate and integrate all the user accounts and groups together so that every user only has one unique user id on NetWare.

Regardless of which method you choose, you will only need to migrate each domain's information once. This is because all of the objects for each domain can be read from the Primary Domain Controller (PDC). All other servers in the domain are not PDCs, so you will only have to migrate the file system information from each of those servers.

If your PDC is unavailable or corrupted, you can use a Backup Domain Controller to migrate the domain objects.

Since there are many additional fields supported in the NetWare Directory Services objects you may desire to use the USER_TEMPLATE and USER_OVERRIDE when performing the domain object migration. These two templates help to fill in additional fields as the migration is performed.

The USER_TEMPLATE is a standard supported template used when creating users by all NetWare utilities. However, the USER_OVERRIDE is supported only by the LMIGRATE.EXE utility. The purpose of the USER_TEMPLATE is to allow information not found in the user object on the source server to be added to the user being created on the NetWare server.

The USER_OVERRIDE template is specific to the LMIGRATE.EXE utility and is used to force a value into a user object field regardless of whether or not that value is found in the user object on the source server. For example, you could specify the minimum number of characters for a password. For information on creating these templates refer to chapter 1 in the manual Supervising the Network.


Tip: When migrating NT servers, the NTAGENT.EXE is required to migrate local groups.

Note: It can take several hours to migrate objects from a large domain to NetWare Directory Services. In an average size domain of 1,000 user objects, using a 486/66 as a NetWare server, migration will take approximately twelveseconds per object, or about 3 2 hours to complete object migration. To increase the speed of migration faster hardware may be used.

File System Migration. The second step uses LMIGRATE.EXE to migrate all the file system data (which includes directories, files and their access rights) from the source server's file system to the NetWare file system. File system directory shares (aliases) on the source server are matched with file system directories on NetWare. This is a one-to-one relationship and splitting shares to two different destination servers is not allowed. You cannot migrate two shares from the same source server to directories on two different destination servers. LMIGRATE.EXE copies the file system information to the destination server, leaving the source server intact.

For file systems that support and use long names (NTFS, HPFS and Macintosh), NetWare name space support must be loaded on the NetWare server prior to data migration. NTFS and HPFS are supported through the use of the OS/2 name space on NetWare.


Note: Depending on how much data will be migrated, this process can take a considerableamount of time. Estimate that typically on a 10Mbs Ethernet networkdata transfer rates are at about 500 MB/hour. This will also dependon how much other traffic there is on the network.

It may be desirable to start several data migration sessions on several different migration workstations. This can be accomplished by copying all files in the LMIGRATE directory into other directories and running the LMIGRATE.EXE utility from those directories. Or, you may use another copy utility such as XCOPY.EXE, NCOPY.EXE or the copy facility in a file manager utility, then use the Access Rights migration portion of the LMIGRATE.EXE utility to assign rights to the directories.

Share Emulation Server. The share emulation server enables workstations running LM/NTS/LS client software and workstations running NetWare client software to have concurrent access to shared files on a NetWare server while the migration plan is being executed. If clients at multiple sites need access to data on such servers, you may desire to use the Share Emulation server.

As part of your migration plan, determine whether the share emulation server will be needed, how it will be accessed, and how long it will be used. The share emulator is not intended to be used for extended periods of time but is appropriate in certain cases to provide concurrent access during the migration process.

Enterprise-wide applications and data which need to be accessed continually from both client platforms during the migration process should be taken into consideration. E-mail, databases, spreadsheets and printing are examples of applications that may be used across both platforms.

Be sure to test these applications and others specific to your needs on both NetWare and LM/NTS/LS clients to determine the best methodology for your migration strategy.

Full NetWare functionality is not available through the share emulation server. Use WINMIG.EXE or OS2MIG.EXE to migrate clients so that full NetWare functionality is available to clients (see "Client Migration" below).

Client Migration. This is the last of the main steps in migration. Workstation clients cannot benefit fully from NetWare 4.x until they are migrated because full NetWare functionality is not available through the Share Emulation Server. Use the appropriate utility WINMIG.EXE or OS2MIG.EXE to migrate your workstation clients to the NetWare client as soon as possible.

You (or the user) can run these upgrade utility files directly from the workstation. The utility verifies the workstation's configuration and attempts to install the NetWare client software. If the client software cannot be installed, an error message is written to the screen and to an error log, and the workstation is not changed.

Each client should take approximately ten minutes to migrate.


Note: The client migration software may be run by the user as it can run totally unattended.

What Kind of Information is Migrated

LMIGRATE.EXE will migrate the following NetWare NDS User, Group, and File information from their respective LAN Manager/NT Server/LAN Server counterparts (where available):

  • User Login Name

  • User description

  • Login Restriction, such as account expiration restrictions, password restrictions, and time restrictions

  • Network Address Restrictions

  • USER_TEMPLATE and USER_OVERRIDE are used to set default values for fields not supported by LM/NTS/LS. User information via USER_TEMPLATE

    • Phone Number

    • Fax Number

    • Title

    • Department

    • Grace Login Information-If grace logins are not set using the USER_TEMPLATE then a default of three is used

    • Home directories-In order to preserve home directories either the USER_TEMPLATE or the USER_OVERRIDE template must be used. The operation of each is a little bit different from the other.

      If you use the USER_TEMPLATE the full path of the home directory specified on the source server is appended to the value entered into the home directory field in the USER_TEMPLATE. This whole value is used to define the home directory for the user. If you use the USER_OVERRIDE template only the user's name is appended to the value in the home directory field of the USER_OVERRIDE template. Therefore, this value is used to define the home directory for the user.

    Note: If a user already exists in a NDS container, allthe user information in both the domain account and the NDS accountis combined, with the exception of user account restrictions,which, if different, are left untouched. (If account restrictionsfor duplicate users are the same, all the user information ismerged into a single user account. If a user name has periods in it, the periods are converted to underlines. To ensure that login time restrictions are correctly migrated, make sure the environment variable TZ is set on the workstation that is doing the migration. Double check that time zones are also set on both the source and destinationservers.

LMIGRATE.EXE will also migrate the following Group information:

  • Group Name

  • Group Description

  • Group Membership-All users which belong to the group


Note: On NetWare group membership cannot contain other group names, thereforeduring the migration process from NT any groups which containother groups are combined into one group. Therefore, all theuser members in the nested group are added to the parent group.

LMIGRATE will migrate the following File and Directory information:

  • Directory structure - including any long name support

  • File data

  • Extended attributes

  • Directory and File access rights

It is assumed that file and directory information is being migratedinto a new file system. Therefore, all files are copied fromthe source server to the destination server with no checking onthe destination server for existing files or directory systems.All existing files with names that are the same will be overwritten.

What the Migrate Utility Does Not Migrate

The following items cannot be migrated to NetWare NDS:

  • User Profiles

  • Print Services-typically, many source servers are migrated into one NetWare server and printing is redesigned

  • Mail Services

  • Passwords


Note: Novell has mail migration toolkits available to help you migrate other mail systems to Novell's GroupWise mail system. (For more information about mail migration toolkits, contact your Novell sales office.)

Even though passwords are not migrated, the Migration utility enables you to select from the following options:

  • Assign passwords that are generated randomly for all users migrated in the current session. Randomly generated passwords are stored in a file called NEWPWD.xxx in the working directory on the NetWare 4.x destination server (this is the default option)

  • Allow users to log in to the new system without a password

  • Select one password for all users

Any of these options enables migrated users to log in after they have been migrated. However, their passwords have been expired and during their initial login, users are required to set a new, private password of their choice.

If a default length for passwords has not been specified a minimum of five is used.

Passwords cannot be randomly generated if a User Account is disabled orif the user and password already exist on the NetWare server.

Performing Your Migration

But before you even perform your test, make sure you have read and followed the foregoing instructions in this article. Before performing the migration on all your domains, you should perform a small test migration, as follows:

  1. Plan you new directory tree structure

  2. Understand how to use the utilities in the toolkit

  3. Configure your hardware

  4. Install NetWare 4.x destination server

  5. Install Novell OS/2 Requester on the workstation where the migration will be performed

  6. Have related documentation on hand

  7. Obtain any NetWare­specific software you need

  8. Create the USER_TEMPLATE and/or USER_OVERRIDE templates as desired

  9. Add OS/2 and/or MacIntosh name space support as needed

  10. Ensure that you are only logged into the source domain/server and destination server that will be used in the migration. LMIGRATE.EXE cannot be used to migrate servers not in the current domain.


Note: If you plan the timing of your full migration so that it immediately follows your test migration, you will not have to perform some steps twice; once each for the test and the full migration.

Performing a Test Migration

To make your migration procedure as smooth and error­free as possible, you should perform a small test migration first. This accomplishes two purposes: gives you familiarity and confidence in using the migration utilities, and enables you to modify your plan to avoid any large­scale problems.

Perform your test migration just as you would an actual migration. If you experience any problems, or realize that you overlooked something in your planning process, make appropriate revisions to your plan so that your full migration will be as easy and error­free as possible.

Identify a Test Population

Your test population should consist of one domain of users who have rights to their own applications and data files. The users in your test domain should have all possible rights and attributes configurations used on your current system, as well as any you anticipate using in the future.

You can create a realistic test population in several ways:

  • Use a backup product to copy existing domain objects, user applications, files, rights, etc. to create a duplicate Primary Domain Controller (recommended)

  • Create fictitious users for your domain

  • Modify existing user information

Remember, you can integrate your test data into the migrated directory structure when you have finished migrating all domains.

If your system includes an existing domain that includes all rights and attributes, you can simply use it as your test domain. Migration of users, groups, data, and access rights is non­destructive to the server. You should have made at least two complete backups, so it is safe to use the actual source information as your test domain if it is more convenient for you to do so.

Migrate a Test Domain with LMIGRATE.EXE

From the migration workstation, start the migration utility by moving to the directory that contains the migration utility files (default is C:\MIGTOOLS\LMIGRATE).

  1. Type:

    LMIGRATE


    Note: If you are not logged in or the requester isn't loaded, you will see an error message at this point. Login and try again.

  2. Press Enter. The NC Migration Utility screen appears. The program reads the current domain and displays it in the Source Domain field (you cannot edit this field).

    Figure 1: NC Migration Utility Screen. This is the domain from which the users and groups will be migrated. Ensure that this is the domain you wish to migrate from. If not, exit the utility and log into the domain you wish to migrate.

  3. The Destination Context field allows you to specify which NDS context the domain objects (users and groups) will be migrated into. If you know your Destination Context, type it in, then click on Proceed. Skip steps 4-6.

    If you are not sure what Destination Context you want, click on Browse and go to step 5.

  4. The Context Selection screen appears. You can double­click on a Context to display the next context level. Continue to double­click until you see the Destination Context you want to select. You will notice that each context you select is added to the path being built in the Destination Context field.

  5. Double­click on your desired Destination Context, then click on Select.

  6. The NC Migration Utility Screen appears again with your desired Destination Context in the field. Click Proceed.

    Figure 2: Source and Destination Information Screen.

    The Source to Destination Information screen appears. In the upper left part of the screen you can select the following types of objects to migrate:

    • Users and Groups: If you select Users and Groups, you can choose from the Password Options that allow you to set No Password, Random Password: (Default), Password for Session.

    • Data: If you select Data, the Server Data Paths/Access Rights to Migrate field and the ADD button to the right are enabled.

    • Access Rights: If you select Access Rights, the Server Data Paths/Access Rights to Migrate field and the Add button to the right are enabled.

    • Share Emulation: This check box defaults to off. By checking this box on, the shares/alias' which are migrated will be shared on the NetWare server. This will allow users that are still running the LM/NTS/LS client software to be able to use the directory share names on NetWare they have always been using. Print shares must be setup through NDS. This is discussed later.

  7. Select the type of objects you want to migrate.

  8. Set password options. (Enter the session password if you selected this option.)


    Note: In the Source and Destination Data Server Browsers the left­handcolumn displays domain (source) servers. The right­hand columndisplays the names of destination NetWare servers/volumes..

    Figure 3: Source and Destination Data Server Browser.

  9. Double­click on the source server name you want to migrate. Your selected domain server name appears in the Source Path field and the shares on that server are displayed. Only shares can be selected at this point; you cannot select sub­directories.

  10. Double­click on the destination server/volume you want the data to be migrated to. Your selection is added to the server name displayed in the Source Path field.

  11. Double­click on the NetWare server name you want these objects migrated to. The server name appears in the Destination Path field, and the right­hand column displays the shares on that server. If desired, you can select subdirectories to add to your destination path.

  12. Click Add. Your selected data is moved to the target server, share, and subdirectory (if any) that you selected. The Delete button becomes active.

  13. Continue to add source and destination paths until you have selected all the information applicable to this migration.

    Each time you click ADD your new selection is displayed in the Source to Destination Information window.


    Note: If you have checked share emulation the migration tool will take the LM/NTS/LS server\share, NetWare server\directory pairs you have selected and create shareemulation links on the NetWare server. This will allow for LM/NTS/LS clients to continue to attach to the server they always have and work as they have done previously.

  14. When you are ready to proceed with the migration, click OK. The Progress of Migration screen appears. Some header information, such as the time, is displayed in the field.

    When the Progress of Migration screen first appears, the migration is in a "paused" state. You can select various types of messages (via the check-boxes on the right­hand side of the screen) that will cause the migration to stop. These are:

    • Information: (Default: Off) a general information message; usually doesn't require any action.

    • Progress: (Default: Off) indicates the state of progress of particular parts of the migration. This type of message usually doesn't require any action.

    • Warnings: (Default: On) indicates a condition that might or might not present a problem. You should check the migration log after the migration has finished to determine whether any action is required.

    • Errors: (Default: On) indicates a potentially serious error, e.g. a server is down, network connection lost, out of memory, etc. Evaluate the error and take appropriate action.

      Under certain circumstances, you can resolve an Error state, then click on MIGRATE to continue the migration.


    Tip: By default, Warning or Error messages will stop the progress of the migration, therefore, to enable unattended migration mode turn these options off so the migration will continue without interruption. When using the unattended mode be sure to review the log file once the migration is completed for any warnings or errors which may have occured.

    In addition, you can specify which types of messages (described above) you want written to the MIGx.LOG file. (Default: All)

  15. Click Migrate. The migration begins, and information begins to be displayed in the field. (The Migrate button changes to a Pause button. while the migration is running, click on this button to temporarily suspend the procedure.


Tip: For optimum speed, you can run your OS/2 migration concurrently on multiple machines; oneto migrate objects, others to migrate data. If multiple machines are not available, some increase in speed can be gained by running multiple concurrent sessions on the same machine. However each session whether on the same machine or multiple machines must be run out of its own directory.

If you choose to run migration concurrently on multiple boxes, be aware that the warning and requirements detailed in step 5 apply for all machines.

Viewing a Migration Report. When the migration has finished, you are prompted whether to view the log file. By selecting yes you will be allowed to view the MIGx.LOG file.

The reports reside in the current working directory that you specified earlier. Use the report to help you complete and customize definitions, attributes, and access privileges on the NetWare 4 server. If you find errors on your destination server after the migration, locate them in the migration report file and determine what actions you should take to correct the errors.

Migrate Test User Information

Use LMIGRATE.EXE to migrate the domain object information associated with the test domain. This step should only include the test domain's object type information.


Note: If it is more convenient, you can use actual domain information for your test migration (see"Identify a Test Population").

Verify Test User Information. Use NWAdmin (or NetAdmin in DOS) to check the NetWare NDS structure to be sure that the test domain information has been migrated correctly and completely.

Ensure that all desired properties have been migrated properly. Pay particular attention to such things as extended user information, addresses, descriptions etc. If some properties have not been migrated, make a note that you will need to add them manually. UIMPORT.EXE can aid in this manual process.

Migrate Test User Applications and Data Files

Use LMIGRATE.EXE to migrate the test server's applications and user data files.

Verify Test User Applications, Data Files, and Access Rights. Check the NetWare server file system structure to be sure that the test server's applications and data files have been migrated correctly and completely. Be sure users have their expected rights to files, etc.

Make sure expected properties, such as user directory rights, have been migrated. If some properties have not been migrated, make a note that you might need to add them manually after the full migration.

Migrate Clients

To complete the migration process all client workstations that are currently running the LM/NTS/LS networking software will need to be migrated to run the NetWare client networking software. For OS/2 this is the NetWare Requester for OS/2 and for DOS/Windows it is the NetWare Client 32 Requester. There are two sets of easy-to-use utilities provided for each of these platforms to minimize the amount of time required to migrate each client.

OS/2 Workstations. The client migration utility allows for OS/2 workstations to retain their current client requester and add the NetWare OS/2 client requester to run in a dual requester mode. Or, the utility can be configured to de-install the current client requester and install the NetWare requester for OS/2 only. This and other parameters are specified by using a workstation configuration program called MIGCFG.EXE. This program is used by the network administrator to specify a response file for various types of network interface cards. Users with those cards would be migrated using that configuration. From the OS2MIG migration directory run the program by typing:

MIGCFG

The NetWare Requester Configuration screen appears. The destination directory is where the NetWare OS/2 requester will be installed. Typically you would leave the default unchanged.

Click the Next button to continue and the Directory Services Information Screen. This screen allows you to specify the preferred tree the user will attach to, the default name context where the user's login ID is found and the Preferred Server the workstation will attach to. Once this information is entered push the Next button to continue. The following screen is now shown (see Figure 4).

Figure 4: NetWare Support for DOS and Windows Screen [missing?]. Determine if IPX support for DOS and Windows is needed and whether the users will need Global or Private NetWare shell support. Typically the default will be just fine.

Click the Next button to continue with the final screen that will need to be filled out. This is the Driver Configuration Screen.

Determine whether the user will be running dual requesters. If they will not, leave No checked on Replace NDIS driver. However, if the user needs to run both the LM/NTS/LS requester and the NetWare requester for OS/2 then select the Yes button. Select the LAN topology and the appropriate frame type to be used as default. Now press Finish to end the dialogue.

If you have a NIC card which is not currently supported by the client migration utility the card can be added to the database by running the LANMAP.EXE program. The program is very simple and maps the NDIS driver to the ODI driver so the migration utility will run properly.

When the LANMAP.EXE screen appears, pick the NDIS driver from the pull down list and then type in the equivalent ODI driver. This will add this configuration to the LANMAP.DAT database.

DOS/Windows Workstations

The DOS/Windows workstation migration utility is a MS Windows Utility that installs the NetWare Client 32 software on a MS Windows 3.1 workstation. The previous requester is removed and only the NetWare client requester software is left running. A response file called C32.RSP for the Windows migration tool is also needed. This file is generated by running the WINCFG.EXE program for Windows and answering the questions. The utility is like the OS/2 configuration program. Refer to the OS/2CFG.EXE section for a full explanation of all the prompts.

There is also a LANMAP.EXE program for Windows as well which works just like the OS/2 version.


Note: There is no option for creating a dual requester DOS/Windows workstation.

The Client Migration Process. To migrate a client workstation, go to the workstation and log into the domain and net use a drive to the alias/share where the client migration utilities were installed. This will be on the LM/NTS/LS server machine and typically in the C:\MIGTOOLS directory. Now follow these steps:

  1. Change directories to the client migration directory for the workstation you are migrating. For example, change directories to the OS2MIG directory to migrate an OS/2 workstation. This is the same directory where the configuration program was run.

  2. Create a program item for either OS/2 or Windows for the appropriate program (ie., OS2MIG.EXE or WINMIG.EXE). For the WINMIG.EXE utility include the full path name of the response file as a parameter with the /R switch to the utility. For example:

    /R:F:\MIGTOOLS\CLIENT\DOSWIN\C32.RSP

    Click on the program item to install the NetWare OS/2 requester or the NetWare Client 32 requestor for DOS/Windows. The client migration screen appears as shown in Figure 5.


    Tip: Create share/alias' to the client migration areas for easy access to the client utilities.For example a share called OS2MIG could be created for the OS/2 migration utilities and aWINMIG share for the DOS/Windows migration utilities. Example: net use f: \\NTSRV1\WINMIG to create a drive to the Windows migration utilities.

    Note: If you fail to include the response file parameter for the Windows client migration utility,the installation will fail and your workstation will be left in an undetermined state.

    Figure 5: NetWare Client Migration Screen.

  3. Click on Continue and the client installation begins. Figure 6 shows what the migration screen looks like as the installation is taking place.

    Figure 6: NetWare Client Migration Progress Screen.

  4. Once the migration has completely installed the NetWare requester you will be asked to reboot the workstation to make the changes effective. Once the workstation has re-booted you will be able to login to the NetWare server.

  5. Finalize the client migration by performing the following tasks:

    1. Migrate at least one client of each type installed on your network to the appropriate NetWare client software. These include DOS/Windows, OS/2, and NT Clients.

    2. Run all third­party applications used on these clients to make sure they function correctly.

    3. Log on as a regular user to make sure that the applications are accessible and that all directory and file rights are correct.

Note: If you log on as Admin, you have rights that might allow you to access files that ordinaryusers cannot acess.

Share Emulation Server

If you clicked the Share Emulation on during the data migration and plan to use the Share Emulation Server, you will need to load the emulator on the NetWare 4.x server and test applications from the LM/NTS/LS type clients that you want to use. If you did not click the Share Emulation on during the data migration, re-run the LMIGRATE.EXE utility and click it on and click off the Data and Access Rights boxes. You can then select the shares to be emulated and their corresponding destination directories.

To share printers the print queues must be setup through the NetWare utility PCONSOLE.EXE and NDS print queue alias' defined in the server context of NDS. When SAMBA.NLM is loaded it reads the print queue alias and lists them as print shares.

To load the share emulator do the following:

  1. Install the share emulator by copying all the *.NLM and *.NCF files in the SAMBA directory to the SYS:SYSTEM directory on the NetWare 4.1 destination server. Ensure that the "locks" sub-directory exists in the SAMBA directory. Also, copy the NWGLUE.NLM in the LMIGRATE directory to the SYS:SYSTEMdirectory.

  2. Make sure that the server's context is the first entry in the bindery context list on the server. This can be seen by typing CONFIGon the server console. The last entry that is shown is the bindery context(s) for the server.

  3. Load the network protocol that is to be used (ie., TCP/IP or NetBEUI, if IPX is to be used nothing needs to be done since IPX is the default protocol on NetWare). The TCP/IP protocol is installed and loaded by using the standard NetWare utilities for TCP/IP.

    The NetBEUI protocol stack is loaded by typing on the NetWare server console screen: LOAD NETBEUI.

  4. Using NWADMIN.EXE create additional directory shares/aliases create NDS directory map objects in the server context. The share emulator will allow these "shares" to be shared by the client workstations.

  5. To emulate additional LM/NTS/LS servers through the Share emulator use NWADMIN.EXE to create NDS server alias objects in the NetWare server context.


    Note: Remember that duplicate server names are not valid on the network and will not allow the emulation server to run.

  6. Load the name service at the NetWare console by typing:

    LOAD NBNS [-G <domain name<]

    where: domain name is the domain that the share emulation server will be joining.


    Note: The domain name is optional. If the domain name parameter is omitted then the NDS container name where the NetWare server is located, is used as the domain name.

  7. If TCP/IP is to be used, load NBIPIO.NLM by typing LOAD NBIPIO at the NetWare console.

  8. On the NetWare 4.1 server console load the share emulator by typing: LOAD SAMBA [-T] [-I] [-N]

    where:

    -T is used when TCP/IP multi-protocol is to be used

    -I when IPX support is needed.

    -N when NetBEUI support is needed

    If none of these protocol parameters are specified the only protocol that will be used is TCP/IP sockets.

    Once this command is executed the share emulator will be loaded. You will now be able to do a net use from a client workstation that is running the LM/NTS/LS client software.

  9. Once you have successfully executed a net use command and have a drive to the share emulator server, make sure that LM/NTS/LS users can still access all the applications on the NetWare 4.x server (through the Share Emulation server) that they could access before you migrated their user IDs, applications, and data.

Note:

Note: In order to do a NET USE command you must already be logged in and authenticated to a domain. Also, the user name and password used to authenticate to the domain must exist on the NetWare server. Since shares/aliases are global to the NetWare server all share names are available when multiple LM/NTS/LS servers are consolidated into one NetWare server.

Since NetBIOS does not allow for the same name to exist on the network one of the followingwill need to be done:

Turn off or change the name of the source server because the server's name will be used by the LM/NTS/LS clients for authentication.

Change the name of the server alias in the NetWare destination server's context. The source server's name was created as a NetWare server alias in the destination server's context. Using NETADMIN or NWADMIN go to the NDS context the destination server is in and change the source server's alias name. This new name will be the name the client workstations must use to NET USE a drive to.

A Successful Test Migration!

When you have successfully migrated all test information, applications, files, and clients to your test domain, evaluate your original migration plan. If you have noted oversights or experienced problems during your test migration, revise your migration plan to avoid them when you perform the full migration

Performing the Full Migration

You will migrate the individual domains in If you have migrated actual source data and information, you can retain your current configuration.

  1. Migrate the next domain specified on your plan

  2. Migrate the User object information for the domain

  3. Verify the User object information for the migrated domain

  4. Migrate application files and data files for thedomain

  5. Verify application files and data files for the migrated domain

  6. Migrate clients

  7. Verify client applications

Repeat steps 1 through 7 above until you have migrated all domains.

Tying Up Loose Ends

Once the bulk of your files and data has been migrated, you still have a few things left to do:

  1. Review the MIGx.LOG files to see what you will have to migrate manually

  2. If desired, reintegrate your test migration files and data into the main tree structure

  3. Examine the files in merged directories and reorganize them if necessary

  4. Set any new directory and file attributes

  5. Add any items by hand that were not migrated

  6. Load any custom applications

  7. Install any NetWare­specific software that is required

  8. Set up user login scripts

  9. Set up print queues and print servers

  10. Check user restrictions and accounting charge rates to make sure your system is configured the way you want it

  11. If you chose to assign random passwords, you may want to print the NEWPWD.xxx file and distribute the password information to your users. After their initial login on the new system, users should change their passwords


Note: Each time the program is run, a new version of the new password file is created. These filesare numbered incrementally, e.g. NEWPWD.001, NEWPWD.002, NEWPWD.003, etc. You should keep these files rather than delete them.

Summary

System administrators with a firm understanding of NetWare 4.x network management (especially how the NDS directory tree is designed) should have no problem following the steps in this article to help them migrate LAN Manager, NT Server, and LAN Server to IntranetWare. Proper planning and performing test migrations will help make the migration process as painless as possible. If possible, a Certified NetWare Engineer should perform the migration procedures.

* 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