With Novell’s recent announcement that it will no longer sell NetWare 3.x or support certain versions of 4.x and with uncertain prospects for NetWare 5.x, you might want to consider migrating your network from Novell NetWare to Windows NT. You should look even further ahead and plan on upgrading to Windows 2000 eventually. Migrating from a NetWare environment to a Windows environment can be a difficult process. In this Daily Drill Down, I’ll walk you through a real-life upgrade of a mixed Windows NT Server and NetWare environment to a pure Windows NT Server environment.
Due to the critical nature of this migration and due to the fact that Windows 2000 is still very new, I chose to migrate NetWare servers to Windows NT 4 first and only then to upgrade to Windows 2000. This approach gave me the opportunity to work out any glitches that arose in a familiar environment before I installed a brand new operating system.Since Windows 2000 is so new, chances are that you may not be as familiar with it as you are with Windows NT. Therefore, I recommend that you work out the kinks while using Windows NT. Once you feel comfortable with the way that things are working, you can upgrade to Windows 2000. Windows 2000 will keep all of the settings that you’ve worked so hard to configure during the migration.
The existing network
What makes this migration so interesting is the current state of the network that I’m upgrading. There’s only one Windows NT 4 server. Naturally, this server is configured as a domain controller, and user accounts, files, and applications have already been loaded on it. The network also contains two NetWare 3.12 servers. One of these servers contains user accounts and data. The other server contains no user accounts; it controls only the nightly backup. For this example, I plan on migrating all of the user accounts and data from the NetWare server to a Windows NT server.

Planning
With this kind of migration, it’s important to understand that no white paper—no matter how good it may be—can substitute for proper planning. Every network is different, and you may experience side effects that are unique to your network. For example, on my network, there are user accounts that have the same name on both servers. This issue can lead to some very complicated problems. If your network is set up differently, however, you may never encounter those problems. Whatever plans you make, I still recommend that you read the rest of this Drill Down before you attempt to upgrade.

The first step
Begin by installing Windows NT on the new server. I recommend that you create a 2 GB FAT partition on the boot drive and install Windows NT onto it (unless you have a compelling reason not to do so). That way, in case something goes horribly wrong, you’ll be able to access this partition easily. If you’re concerned about security, you can always convert this partition to NTFS later on.

During the installation, you should make the new server a domain controller because you’ll be migrating user accounts to it. Once you’ve finished installing Windows NT, be sure to apply the latest Service Pack for NT.

After you’ve removed the NetWare servers, you should consider the state of your network. In most cases, you won’t need to run IPX/SPX after you’ve removed those servers from your network. You’re probably better off running TCP/IP exclusively on all clients and servers. If you decide to run TCP/IP, you may need a WINS server and/or a DNS server to take care of name resolution. Now would be a good time to set up these servers.

Linking the servers to each other
Before you can begin the migration process, you must link the Windows NT Server to the NetWare server via Gateway Services for NetWare. Open Control Panel and double-click on the Network icon. When you see the Network properties sheet, select the Services tab. Now, click the Add button and select Gateway (and Client) Services for NetWare from the Network Service window. When you click OK, you’ll be prompted for the location of your Windows NT CD-ROM. Supply the location and click OK. Windows NT will copy the necessary files. Click OK when you’re done. You’ll need to reboot the Windows NT Server.

While you’re waiting for the Windows NT Server to come back up, log on to your NetWare server from another machine and create a group called NTGATEWAY. Next, create a user with any name of your choice and place it in the NTGATEWAY group. Normally, this user would have access only to those files and directories that you want people who attach to the server through the gateway to see, but since you’ll be using the gateway strictly for migration purposes, you should give this account access to everything.

After you reboot your Windows NT Server, you’ll see a dialog box that asks for the preferred NetWare server (or tree, if you’re using NetWare 4.0 or above). Enter this information and proceed with the login.

Once you’re logged in, go to Control Panel and double-click on the GSNW icon. You’ll see the Gateway Services for NetWare dialog box, as shown in Figure A. Choose your preferred server (or tree) and select the appropriate options for gateway printing and login scripts. Then, click the Gateway button.

Figure A
The GSNW dialog box allows you to configure Gateway Services for NetWare.

Next, you’ll see the Configure Gateway dialog box. As you might guess, you can enable the gateway by selecting the Enable gateway check box. In the space provided, type the name and password of the gateway account that you created on the NetWare server and click OK. You’ve established a gateway to the NetWare server.

You may be curious about the Add button, which is found in the lower section of the Configure Gateway dialog box, as shown in Figure B. Clicking the Add button allows you to create Windows-accessible shares that link directly to a directory on your NetWare volume. Creating these shares isn’t necessary because we’re using the gateway only for the purpose of migrating the NetWare server.

Figure B
Clicking the Add button allows you to create Windows-accessible shares that link directly to a directory on your NetWare volume.

The migration tool
Now, you’re ready to begin the actual migration. Log out of the Windows NT Server and log back in as Administrator. Doing so will finalize the changes that you’ve made to the gateway. Then, select the Migration Tool For NetWare command from the Start | Programs | Administrative Tools menu. The Migration Tool For NetWare was placed on the Administrative Tools menu automatically when you installed the Gateway Services for NetWare.

After you load the Migration Tool For NetWare, the first thing that you’ll see is a dialog box. It asks for the name of the NetWare server and the name of the Windows NT server. Fill in the appropriate information and click OK. Next, you’ll see the Migration Tool For NetWare’s main screen, as shown in Figure C. Notice that the column to the left allows you to perform multiple migrations by adding the servers to the list with the Add button.

Figure C
The Migration Tool for NetWare makes migration a mostly automated process.

The User and Group Options properties sheet
Once you’ve set up the appropriate servers for migration, select the first set of servers from the list and click the User Options button. Next, you’ll see the User and Group Options properties sheet. The first tab is the Passwords tab. Since the Migration Tool for NetWare can’t migrate passwords, you must tell it how to handle the passwords. You can set no password, make the password the same as the username, or enter a custom password. You also can force the user to change the password at login by selecting the User Must Change Password check box.

On this tab, it’s easy to overlook the two checkboxes at the top. The first check box allows you to transfer users and groups. If you don’t check this check box, only files will be migrated. The other check box allows you to use a mapping file. A mapping file allows you to migrate only selected users. It can be handy when you’re performing a gradual migration.

The Usernames tab allows you to decide how the Migration Tool for NetWare will handle duplicate login names. You can choose either to ignore them (duplicate names won’t be migrated) or to log them. If you choose to log duplicate names, the names won’t be migrated, but you’ll have a list of which users weren’t migrated. You can overwrite the existing login name with the information from the NetWare server, or you can add a prefix to the login name. For example, if you had a user named Brien on both servers, you could add the prefix NW_ to create an account called NW_Brien. This method will help you determine which account came from the NetWare server.

The Group Names tab has similar options to the Usernames tab. You can either log or ignore errors, and you can add a prefix to the group names.

The Defaults tab needs more explanation. The Use Supervisor Defaults check box takes all of the account policies that were originally created by the supervisor and migrates them to the Windows NT Server, including such policies as minimum password length and how frequently users must change their passwords. As its name suggests, the next check box allows you to add the Supervisor account to the Administrators group.

You might have noticed that the User and Group Options dialog box contains an Advanced button. The Advanced button allows you to migrate the NetWare server to a Windows NT Server in a trusted domain.

Making selections for migration
Once you’ve set the user and group policies, click OK to return to the main Migration Tool for NetWare screen. Now, click the File Options button. You can decide whether or not to migrate files from the NetWare server by selecting the Transfer Files checkbox, as shown in Figure D. As you can see in the figure, the files must be migrated from a NetWare volume to a Windows NT share point. If no share point exists, you can create one by clicking the Modify button and then the Modify Destination dialog box’s New Share button. If you want to migrate the contents of your NetWare server to the root directory of a given partition, remember that every partition is already associated with a hidden share. For example, the E partition has a hidden share called E$. I selected it by clicking the New Share button and specifying E$ as the share name and \\SERVERNAME\E$ as the share path.

Figure D
You can decide whether or not to migrate files from the NetWare server by selecting the Transfer Files checkbox.

Just because you can migrate to a partition’s root directory doesn’t necessarily mean that you should. For starters, some users may have trouble connecting to such a share. Also, it’s much easier from a client configuration standpoint to create a share called SYS. It greatly simplifies the migration process. For example, how many batch files do you have that contain a command like the following?
MAP G:= \\NETWARE\SYS:USERS

Sure, Windows NT doesn’t use the MAP command, but if you call your new server the same name as the server that it replaced and name the share SYS, you won’t have to redirect all of your mappings. It’s also an effective technique for attaching to network printers. If Windows 98 is set to attach to a printer at \\NETWARE\HP, it doesn’t care if that location is a NetWare print queue or a Windows NT share point. Keeping the server name the same often avoids the trouble of having to reconnect everyone’s printers manually.

The File Options dialog box’s Files button allows you to select which files and directories you want to migrate (in traditional Windows Explorer form). Although your first instinct may be to migrate everything, you don’t have to do so. The following directories are specific to NetWare and don’t have to be migrated:

  • SYS\ETC
  • SYS\LOGIN
  • SYS\MAIL
  • SYS\PUBLIC
  • SYS\SYSTEM

When you’ve selected the files that you want to migrate, click OK. At this point, I recommend that you perform a trial migration. A trial migration rarely takes much time, and it can catch potentially devastating errors. Therefore, you should always perform a trial migration before an actual migration.

One of the first things that you may notice when you’re running the trial (or actual) migration is a message that indicates there isn’t enough disk space. In many cases, this is a false error. If the partition to which you’re migrating is larger than 4 GB, a bug in Windows NT causes a portion of the program to keep subtracting 4 GB increments and telling you that whatever is left is your free disk space. For example, if the partition were 6 GB, the program would subtract 4 GB and indicate 2 GB free. On the other hand, if you were migrating to a 37 GB partition, the calculation would look something like this:
37 GB – 4 GB = 33 GB
33 BG – 4 GB = 29 GB
29 GB – 4 GB = 25 GB
25 GB – 4 GB = 21 GB
21 GB – 4 GB = 17 GB
17 GB – 4 GB = 13 GB
13 GB – 4 GB = 9 GB
9 GB – 4 GB = 5 GB
5 GB – 4 GB = 1 GB Free Disk Space

You also can see this error if the size of the NetWare volume that you’re trying to migrate is larger than 4 GB. If you ignore the error, the migration will occur correctly (assuming that you actually have enough free disk space).

Performing the migration
At this point, you should perform the actual migration. It will start by migrating user accounts, as shown in Figure E, and it will go on to migrate files. This process can become time consuming. During my migration, 2 GB (21,750 files) took about 3 hours to migrate. Of course, times will vary widely based on such factors as server speeds, network speed, and file sizes.

Figure E
The migration process will begin with user accounts.

After the migration completes, there are several things that you should check, including error logs, login scripts, print queues, and passwords.

Login scripts
Login scripts make up one major issue with which you need to deal. In heterogeneous environments, NetWare and Windows NT maintain separate login scripts. First, one login script executes, and then the other one does. If you already have Windows NT Servers in place, login scripts can behave unpredictably. After migrating the server, you’ll need to see if the NetWare login scripts migrated and if they replaced the Windows NT login scripts. In mixed environments, it’s almost always necessary to recompose the login scripts manually and link them to the user accounts.

Passwords
If your users possess any level of sophistication, it shouldn’t be difficult for them to reset their own passwords. As most administrators know, however, users tend to be computer illiterate. You may have to set everyone’s passwords manually. If you suspect that you’ll have to perform this task, it isn’t a bad idea to compile a list of everyone’s passwords. There are always unforeseen things that go wrong after a migration. You really don’t want the added headache of hundreds of users calling you because they can’t figure out their passwords.

Printers
Perhaps the most overlooked aspects of the migration process are the print queues. In most cases, if your users are on Windows 9x or above and you’ve taken my advice about keeping the server name and the print queue names the same, you won’t have to do anything. However, I did run into a couple of stubborn workstations that required me to attach to the printers manually.

Just to give you an idea of the technique that I used: All of my printers are attached to Jet Direct boxes. These boxes were linked to NetWare print queues. I created shared printers on my new Windows NT Server, with names that matched the NetWare print queues.

Permissions
You also need to check the permissions on the various directories that you’ve migrated. The migration tool has a nasty tendency of allowing everyone full control of every directory. Many times, the migration tool assigns the correct permissions but also adds full control rights to those permissions.

The clients
After the migration has been completed, pull the plug on the NetWare server. Reconfigure one client machine and make sure that everything works. You’ll need to use the Network icon within the Control Panel to remove any references to the NetWare servers. Then, reboot the PC and make sure that you can access all of the appropriate files and printers and that all of your programs still run.

Try to resist the temptation to reconfigure all of the clients while the migration is running. If the migration were to go wrong, you’d have lots of clients that would have to be redone before they could reattach to the NetWare Server. Another advantage to waiting is that you can note everything that will have to be changed on the first machine. Then, you can make all of the changes on all of the other computers at once, instead of having to learn from trial and error on each of the machines.

Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it’s impossible for him to respond to every message. However, he does read them all.)

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.