Of course, Microsoft Windows NT Server is a great server and can handle all the file, print, and application server requirements for a small company or a large corporation. But still, other network operating systems also exist in the marketplace.
When the first version of Microsoft Windows NT Server was released, Novell NetWare held the greatest market share for network operating systems. At the time of this writing, NetWare still does, with Microsoft Windows NT Server catching up quickly.
Because of the huge installed base of NetWare servers, Microsoft decided, beginning with Microsoft Windows NT Server 3.5, to incorporate some features that would enable Microsoft Windows NT Server to coexist with NetWare. Microsoft also offered tools that enable an easy migration from NetWare to Microsoft Windows NT Server.
This chapter discusses some of the built-in functions Microsoft Windows NT Server offers that give Microsoft Windows NT Server the capability to coexist with NetWare, and to replace NetWare. Ill also discuss a utility available from Microsoft that can actually make an NT server appear as a NetWare server.
Microsoft And Novell
When Microsoft Windows NT Server was first released in 1993, it seemed as though there would never be connectivity between NT and NetWare. Microsoft didnt care to include their version of a NetWare client, and Novell seemed to have even less of an interest to allow NT PCs see NetWare servers.
Perhaps this was because of the differences that Novell and Microsoft encountered with the release of Windows For Workgroups. If youre unfamiliar with this issue, Microsoft had included Novells NetWare client for Windows in the first release of Windows For Workgroups. According to Novell, Microsoft had not asked permission to include this client software, and demanded that their software be removed from the product. This was the start of a feud that would be short lived, but would result in a lack of a NetWare client for NT being produced in time for the release of NT.
As a user in a NetWare environment at the time, it was very frustrating having to live without network connectivity when running NT as my desktop operating system.
Due to customer demand, Microsoft decided to create their own NetWare client for NT. Apparantly not wanting to be outdone by Microsoft, Novell released their own NetWare client for NT, albeit in beta form. Both of these clients offered nothing more than basic connectivity, and in my own opinion, the Microsoft client was more solid than the Novell client, which appeared to be a rush job. Both products had no support for login scripts, and no GUI tools.
Both companies were then releasing their respective beta versions of the NetWare client for NT, each time adding a little bit more functionality.
Not until the release of Microsoft Windows NT Server 3.5 was there a client for NetWare built into the NT product. Microsofts client depended on a NetWare bindery to gain access to a NetWare server. With the release of NetWare 4.x, with its new NDS tree, Microsofts NetWare client for NT required NetWare 4.x servers to run in "Bindery Emulation Mode." Novell and Microsoft soon released their NDS client for NT, but this was only usable on a Windows NT Workstation. Not until Microsoft Windows NT Server 4.0, has Microsoft finally included the ability for an NT server to login to a NetWare NDS tree (although this functionality has been available for Windows NT Workstation, from both Microsoft and Novell).
The next section of this chapter discusses the feature built into NT Server, called Gateway Service For NetWare, which has been revised for this new version of Microsoft Windows NT Server to allow for NDS logins.
Gateway Service for NetWare
Gateway Service for NetWare is an installable service that enables access to a NetWare server through the NT Server. This enables a client to run only the client software for an NT network and still have access to NetWare resources.
There are a few guidelines for using this service. First, this is not a way to bypass NetWare security. A client that uses the gateway must have an account on the NetWare server and must have permission to access whatever resources they try to attach to. Second, Gateway Service for NetWare is not a replacement for making a direct connection to a NetWare server. Gateway Service for NetWare uses only one connection to NetWare and cannot achieve the same performance as a direct connection. In fact, if more than one user is utilizing Gateway Service for NetWare, the performance degrades even more. That is why it is strongly advised to use Gateway Service for NetWare only if the resources on the NetWare server are seldom used.
For instance, if a NetWare client decides to migrate to an NT domain and run only the client software for NT to avoid unnecessary overhead, there is a chance that there is a shared directory on the NetWare server that the user still wants access to. To retrieve an occasional document, or to print to a NetWare print queue, Gateway Service for NetWare is the perfect tool. It should not be used for running applications. Yes, you can run an application, but again, there is a good chance that there will be a performance issue. Users who do want access to applications residing on a NetWare server should run native NetWare client software and make a direct connection.
Installing Gateway Service for NetWare
Before you install Gateway Service for NetWare, you need to do some setting up to enable it to install properly.
In this example I use a NetWare 4.1 server. I am logged into the NetWare NDS tree, which enables me to run the NWADMIN.EXE administration program from Windows 95. I am using Microsoft's Client For NDS to get access to the NetWare server.
For a NetWare 3.x server, you use SYSCON to perform the same activities I describe here. With the earlier versions of NetWare you need to repeat the steps for each NetWare 3.x server you want to give your NT clients access to. NDS enables you to go through this routine only once.
One account used on NetWare functions as the service account for Gateway Service for NetWare. Using NWADMIN, you choose to create a new user object. The name of the user can be anything, but the same ID must exist in both NetWare and NT. For this example I use the name NTSERVER (see Figure 22.1).
As with all networks, having a password defined is highly advised. Chances are that you already have a default user profile set up that dictates the password standards for your organization. However, in the case of this service account, you don't want the user to be able to change the password, and you don't want the account or the password to expire.
Click the Change Password button to set the password (see Figure 22.4).
Click the OK button and you have finished configuring the Gateway Service for NetWare service account in NetWare. You still need to create this account in the NT domain.
On the NT Server, create a user account as shown in Chapter 18, Administering the Server. The Gateway Service for NetWare service account on NT must have permission to create shares, and it should have a password that never expires.
The next task you need to do on the NetWare side is to create a new group (see Figure 22.5). Call the group NTGATEWAY and click the Define Additional Properties checkbox for this group (see Figure 22.6).
In the Identification page shown in Figure 22.7, you should type in a description for this group so that no one accidentally deletes the group. Without this group, Gateway Service for NetWare does not function at all.
The Rights to Files and Directories page in NWADMIN.
You can configure the NTGATEWAY group to have as much or as little access to NetWare as you like. Because the users still have access only to the files and directories that their own NetWare account has access to, you might want to give Supervisor rights to all the NetWare volumes. You also have the option to assign lesser rights to limit the usage of the Gateway Service for NetWare service account.
Click the Add button to find the volumes that are available in the NDS tree. Navigate through the tree, and when you see a volume you want to enable the Gateway Service for NetWare service account to access, highlight it, as shown in Figure 22.10, and click the OK button. Continue this until you have identified all of these volumes.
After you have added the last volume you want to make available, highlight each volume and assign the appropriate rights for that volume. To assign Supervisor rights for all the volumes, select all the volumes and click the Supervisor checkbox (see Figure 22.11).
If you already have another NetWare redirector installed, such as Novell's NetWare Services For NT, you must remove the existing redirector before installing Microsoft's Gateway Service for NetWare.
To install Gateway Service for NetWare on your NT Server, click the Start button, choose Settings, and click Control Panel. Double-click the Network icon. In the Network dialog, click the Services tab. A list of services that have already been installed appears. Click the Add button, and a list of installable services is displayed. This is the Select Network Services dialog.
From the Select Network Services listing, highlight Gateway (and Client) Service For NetWare (see Figure 22.13), and click the OK button.
You are prompted for the location of the Microsoft Windows NT Server CD-ROM, and the appropriate files are copied to the Microsoft Windows NT Server directory. When the copy has completed, Gateway Service for NetWare appears on the installed services list (see Figure 22.14). Click the Close button, and you are prompted to restart the server (see Figure 22.15).
Microsoft Windows NT Server must be restarted to start the new service.
If you did not already have the NWLink IPX/SPX Compatible protocol installed, Gateway Service for NetWare will automatically install this protocol. If the NWLink IPX/SPX Compatible protocol is installed for you, you are prompted for configuration settings for the protocol before you are prompted to restart the server.
After the server has restarted, the user name used in the local logon must be a valid user on both the NT Server and the NetWare server where Gateway Service for NetWare is used. The user name must also have permission to create shares on the NT Server.
After logging on, the Select Preferred Server For NetWare dialog box, shown in Figure 22.16, prompts for either a server name, if you are connecting to a NetWare 3.x server or a NetWare 4.1 server in bindery emulation mode, or a Tree and Context for attaching to an NDS tree on a NetWare 4.x server. In this example I have chosen to use the NDS tree for the login.
You have the option of choosing to execute a login script when logging on locally; however, there really shouldn't be any reason to do that if your only intent is to create a gateway.
Select your Preferred Server quickly. After around 60 seconds, this dialog times out and logs you onto the NT domain and then attempts to log in to the first NetWare server found.
Once you have been logged on, you can proceed in configuring Gateway Service for NetWare.
After you install Gateway Service for NetWare, a new icon appears in the Control Panel (see Figure 22.17). Double-click the red GSNW icon, and the Gateway Service for NetWare applet appears (see Figure 22.18). You can change your preferred server choice here. You can also make printing configuration choices for NetWare when logging on locally in this applet. This configuration information applies only to the user name that appears at the top of the dialog.
By pressing the Gateway button, you enter the Configure Gateway dialog (see Figure 22.19). The first thing you need to do in this dialog is check the box that says Enable Gateway. That enables you to specify the Gateway Service for NetWare service account and password defined in NetWare. In Figure 22.19 you see that there are no shares defined. These shares are the same type of share you might already be used to as an NT Server administrator. The main difference is that the shares defined here point to volumes located on a NetWare server.
Share Name: Like the normal type of NT Server share, you should enter a name that is displayed to clients in a browse list. Names longer than eight characters are not accessible from MS-DOS workstations. If this is the case, you receive a warning, as shown in Figure 22.21. The share name can be no more than 15 characters long.
Network Path: Specify the volume to be used for this share using UNC (Universal Naming Conventions). In this example I am pointing to the server named NW41_SERVER and the volume SYS.
Comment: This is a description that appears in the resulting list of gateway shares.
Use Drive: An unused drive letter on the server is chosen for this share. Even though the gateway is active without a local logon, a currently available drive letter must be used to establish the gateway share originally.
User Limit: Enter the maximum number of concurrent connections that are allowed to access this share. Choose Unlimited to allow unlimited connections.
Click the OK button, and the share should be established.
You might receive an error message like the one shown in Figure 22.22. This is an interesting error message because it does not always mean what it says. You can get this error message if you have incorrectly specified a service account that was not set up properly under NetWare, or if you made a typo while entering an account name. In this case, I created this error message by attempting to exceed the number of licensed connections available on the NetWare server. Incidentally, an incorrect or mistyped password results in an Incorrect Password message, and an incorrect or mistyped network path gets a Server Not Found or Network Path Not Found message.
Now you can work on setting the permissions for this share. This is an interesting piece of configuring the gateway, because even if a user has full permissions on a NetWare volume, the permissions set on this share can lessen the user's actual permissions. For instance, if I have READ and WRITE permission on the \\NW41_SERVER\SYS volume, and the permission for the NW_SYS share gives Full Control to the Everyone group, I am still limited to READ and WRITE permissions, as set in NetWare. But if I alter the Gateway Configuration permissions to give the Everyone group only READ permission (see Figure 22.24), my access to that volume is now limited to READ only. Furthermore, if I have limited permissions set on the NetWare NTGATEWAY group, the user's permissions cannot exceed the permissions set for that group.
Click the OK button in the Configure Gateway dialog, and the share is available to the network. As shown in Figure 22.25, the share list for SERVER shows NW_SYS as one of the shares on that NT Server. Opening up the NW_SYS folder shows your standard NetWare SYS volume.
Although Gateway Service for NetWare enables the integration of Microsoft Windows NT Server and Novell NetWare, the Migration Tool for NetWare enables you to upgrade from NetWare to NT. This is done by having both servers on the same network and performing an over-the-wire transfer of administrative information and data.
The Migration tool for NetWare relies on the existence of a NetWare bindery. The bindery is the database of administrative information used in NetWare 3.x. NetWare 4.x uses NDS to hold its data, but there is a bindery emulation mode for NetWare 4.x, and this emulation mode is required if you want to migrate from NetWare 4.x to NT using the Migration Tool for NetWare.
Another requirement is that your NT Server's system partition must be formatted as NTFS. This enables NT to take in the security information contained on the NetWare server.
Of course, you must match hard drive capacity on the NT Server or have more available, so you have enough space to bring over the information you want to migrate.
Usually, a NetWare server will be running not only the NetWare network operating system but also some utilities, such as backup software, anti-virus tools, or communications software. In most cases, the executable program for this software is a NetWare Loadable Module (NLM). NLMs are useless for a Windows NT server and cannot be migrated. Before you fully migrate from NetWare to NT, be sure to purchase NT-compatible replacements for these programs.
With backup software, the backup tapes created from a NLM backup program may not be compatible with an NT backup program. You might want to keep your orignal NetWare server and backup software available until you are sure that you no longer require it. Once you have migrated to NT, be sure to create a full backup. There is cross-platform backup software. (Cheyenne Softwares ArcServe comes to mind.)
What is not transferred to the NT domain are any login scripts and User Account passwords. There is a way to configure the Migration Tool for NetWare to set passwords, but the only way to migrate login scripts is to translate them manually into NT Logon scripts.
See the section later in this chapter titled "File And Print Services For NetWare" to learn about an alternate strategy for migrating from a NetWare environment to an NT domain.
Preparing for the Migration
When you migrate NetWare servers to an NT domain, you have many choices to make. If you are migrating a single NetWare server to an NT domain, you will have a relatively easy time. If you are migrating multiple NetWare servers to a single NT domain, you run the risk of duplicate user accounts, groups, and data.
Along the path of setting up the migration, you are given options on how to handle potential problems.
Now might be the time to go through your NetWare servers and weed out unused groups, user accounts, and files. Why deal with these during the migration if you don't really need them?
Before you can run the migration utility, you must be logged on to your NT Server as a member of the Administrators group. You are also required to use a NetWare user account that has supervisory permissions.
Let's start preparing for the migration by starting the NWCONV.EXE program found in the SYSTEM32 subdirectory under your Windows NT directory.
The Migration Tool for NetWare starts out by displaying the Select Servers For Migration dialog (see Figure 22.26). Click the button next to the From NetWare Server entry field, and the Select NetWare Server dialog is displayed (see Figure 22.27). Highlight the first NetWare server you want to migrate, and click the OK button.
Next, click the button to the right of the To Windows NT Server entry field to bring up the Select Windows NT Server dialog (see Figure 27.28). After you have selected the destination server, click the OK button to be returned to the Select Servers For Migration dialog (see Figure 22.29).
The Select Servers For Migration dialog with selection results.
Click OK to add this set of servers to the main Migration Tool window. If your current NT logon name and password are not usable by NetWare, you are prompted for the user account on the NetWare server that gives you full access to the bindery and the volumes (see Figure 22.30). Once the appropriate information has been entered, click the OK button, and the pair of servers appears on the Servers For Migration list (see Figure 22.31).
If you want to migrate more NetWare servers, repeat this process until you have identified all the servers you want to migrate to NT.
Even if you want to migrate more than one server from NetWare, you might want to handle them one at a time so that you don't have to handle several possible conflicts in one shot. A slow migration is sometimes best, although some people opt to perform the entire migration in one swoop, just to get it done quickly. Luckily, there is a trial migration mode that can identify these conflicts in advance.
After all the servers have been selected for migration, you can start configuring the different options.
Before you proceed with configuring your migration, you should be aware of some options that are available to you during the configuration process.
The File menu in the Migration Tool for NetWare main dialog enables you to save the currently configured migration. By default, when you exit the Migration Tool for NetWare dialog, all the configuration options you set during the last time you ran the program are saved and brought into the current session. You can also click the File menu and choose Save Configuration to save all the current options to a file with a file extension of .CNF. You can also restore previously saved settings by choosing Restore Configuration from the File menu. To start the Migration Tool for NetWare with a clean slate, just choose Restore Default Config from the File menu.
Now, back to configuring your migration.
First, the user and group options are configured by clicking the User Options button.
The User and Group Options dialog, shown in Figure 22.32, enables you to specify whether user accounts and groups will be transferred to the NT domain. If they will be transferred, you can configure how this transfer will be handled.
First, you can specify whether the passwords for all the migrated users should be blank, set to their user name, or set to a password you specify to be used for all user accounts. You can also specify whether the user is forced to change their password the first time they log onto the NT domain.
You can also specify how duplicate user names are handled during the migration. A duplicate user name can occur if an NT account has the same name as a NetWare account, or if you are migrating more than one NetWare server to the same NT domain.
The options available are to skip the duplicate user name and log an error, skip the duplicate user name and ignore the error, add information from the duplicate user to the existing user account, or add a prefix to the duplicate user name.
The same options are available for groups; however, you cannot add information from the duplicate group to the existing group.
You can also choose to add NetWare users that have Supervisor equivalency to the NT domain's Administrators group.
You also have the choice of overriding all the preceding settings by creating a mapping file. A mapping file is a text file with the file extension .MAP that tells the Migration Tool exactly how to handle each user name and group.
To create a mapping file, click the checkbox in the User and Group Options dialog labeled Use Mappings in File. Then, enter the name of the file you would like to create. Do not type in the file extension. In my example, shown in Figure 22.33, I used the name NW2NT for the mapping file. Click the Create button, and the Create Mapping File dialog appears (see Figure 22.34).
This dialog enables you to choose whether user names and group names appear in the mapping file. If user names appear in the mapping file, you can specify if you want a default password put into the mapping file. In this example I opted to include both user names and groups. I chose to leave the password blank, because I want to fill in my own passwords for the users I want to migrate.
When these options have been completed, click the OK button. A file creation confirmation box asks whether you want to edit the mapping file (see Figure 22.35). Click Yes to bring your newly created mapping file into Notepad for editing.
In Figure 22.36, you see that the options you chose (in this case, both users and groups) have been brought into this file, along with whatever password you have chosen (none in this case). The syntax for the mappings is OldName, NewName, and Password.
In Figure 22.37, I changed the NetWare user name JUSTIN to JUSTINR for the NT domain account. I also set that account's password to HOME. I also altered the NetWare KEVIN account and set a password for it. I left the other accounts alone because those accounts already exist in the NT domain and are flagged as duplicated. I decided to leave the group name alone as well. Exit Notepad normally to save the mapping file.
This text file is read by the Migration Tool when either the trial migration or actual migration is run. It can be altered at any time, even outside the User and Group Options dialog.
Now you are back to the User and Group Options dialog. If your settings here are completed, click the OK button to return to the Migration Tool for NetWare main dialog.
The next area of configuration is the File Options. By clicking the File Options button, you can specify what volumes and files are migrated, and what their destinations are.
By default, if you choose to migrate the NetWare volumes, they are copied to the first NTFS partition found in drive letter order. A directory is created with the same name as the volume name, and the default share name is also the volume name. In the example, there are two volumes on the NetWare server: SYS and VOL1.
In the User and Group Options dialog, click the File Options button. The File Options dialog is displayed (see Figure 22.38), listing the volumes from the selected NetWare server. The first choice you are given is whether to copy these volumes to the NT Server. Because I have left the default, which is to migrate the volume, the NetWare volumes are listed and I can now specify the specific configuration options.
As shown in the Destination column, the shares that are created are the same name as the volumes. This is the default option, which can be overridden. You can also choose to remove one or both volumes from the list by highlighting the volume and clicking the Delete button. I wanted to change the destination of the SYS volume, so I highlighted the SYS volume and clicked the Modify button.
The Modify Destination dialog, shown in Figure 22.39, gives you the option to change the share name and/or the destination directory for the selected volume. I want to change both of these, so I click the New Share button.
The resulting dialog, shown in Figure 22.40, enabled me to type in the share name I want to use, which is NW_SYS. I also changed the default migration directory, which was D:\SYS because my C drive is formatted as FAT, to a directory of my choosing on the E drive, named Old NetWare SYS Volume.
File Options after changing the destination share.
By clicking the Files button, you can choose individual files and directories contained on that volume that you want to migrate. As shown in Figure 22.42, by default the Files To Transfer dialog selects most of the non-NetWare-specific files and directories to be migrated. It is up to you to check the unchecked boxes next to the items the Migration Tool has automatically chosen to omit, or to uncheck the boxes of the files or directories you don't want to migrate. Because this migration is going to an NTFS partition, most of the file attributes travel along with it.
Hidden and system files are not migrated by default. In the Files To Transfer dialog (see Figure 22.42), click the Transfer menu and choose Hidden Files to transfer all hidden files in the directories selected for transfer. To migrate system files, click the Transfer menu and choose System Files to transfer all system files in the directories selected for transfer.
The actual translation methods of file and directory attributes are shown in Tables 22.1, 22.2, and 22.3.
The effective rights for a directory are translated to the NTFS permissions shown in Table 22.1.
Table 26.1. Directory rights.
NetWare Directory Rights
NTFS Directory Permissions>
Full Control (All) (All)
Read (RX) (RX)
Change (RWXD) (RWXD)
Add (WX) (not specified)
Change (RWXD) (RWXD)
Change (RWXD) (RWXD)
File Scan (F)
List (RX) (not specified)
Access Control (A)
Change Permissions (P)
The effective rights for a file are translated to the NTFS permissions shown in Table 22.2.
Table 22.2. File access rights.
NetWare File Rights
NTFS File Permissions
Full Control (All)
Access Control (A)
Change Permissions (P)
The Create and File Scan rights are ignored when files are transferred.
NetWare file attributes are translated to the NTFS file attributes shown in Table 22.3.
Table 22.3. File attributes.
NetWare File Attributes
NTFS File Attributes
Read Only (Ro)
Read Only (R)
Delete Inhibit (D)
Read Only (R)
Rename Inhibit (R)
Read Only (R)
Archive Needed (A)
Read Write (Rw)
None, because files without the R attribute can be read and written to
The following NetWare file attributes are not supported by NTFS and are therefore ignored:
Copy Inhibit (C), Execute Only (X), Indexed (I), Purge (P), Read Audit (Ra), Shareable(SH), Transactional (T), and Write Audit (Wa).
After you have set the options for the first volume, repeat the procedure for all the other volumes from the NetWare server you are migrating.
When all the file and directories options have been completed, click the OK button to return to the Migration Tool for NetWare main dialog.
You can now choose the logging options for your migration. Click the Logging button to display the Logging dialog (see Figure 22.43), which enables you to turn on or off three options.
The first option, Popup on Errors, is whether you want to have a message displayed whenever an error situation has been encountered. If you are running a trial migration, which simply creates a log and does not actually perform the migration, you might want to turn this option off. The intent is to run a trial migration and then make changes based on the error log.
The second option, Verbose User/Group Logging, gives you the option to have explicit logging of every translation performed on users and groups. If you require a complete record of the migration, turn on this option by checking the box.
The third option, Verbose File Logging, gives you a list of each file and directory that has been transferred from the NetWare volume to the NT Server. Again, if you require a complete log of your migration, turn this on by checking the box.
Regardless, all errors are placed in an error log.
Starting the Migration
You are now ready to perform your migration; however, you have the option of performing a trial migration first. This puts the Migration Tool for NetWare through the motions of an actual migration, using the options you have specified, without actually migrating users, groups, or volumes.
Kick off the trial migration by clicking the Trial Migration button. As shown in Figure 22.44, the migration is performed just as if it were the real migration. Users, files, and directories are examined. If any contentions are found, the Migration Tool reacts however the options have been configured. Figure 22.45 shows one such error, where a duplicate user name has been encountered. Here you are given the choice to manually give that user a new name (and then click the OK button to continue), Abort the entire procedure, or Cancel the migration of this particular user.
When the trial migration is complete, you are notified in exactly the same way you would be if this were the real migration. A summary of the migration gives you the vital statistics (see Figure 22.46). You can also choose to view the three log files in an application called LogView (see Figure 22.47).
The Logfile.Log (see Figure 22.48) is where you would find detailed information about the actual conversions that have occurred. If you have chosen Verbose File Logging, this is where you will find it.
Before you proceed with the actual migration, you should review these logs and make sure that what you are about to do is the right thing. The migration cannot be reversedat least, not automatically.
After you have made changes to your mapping file, or changed some of the logging options, you might feel comfortable with proceeding with the real migration. When you are ready, click the Start Migration button, and you will see exactly what you saw when you tried the trial migration. This time though, it's for real.
As you can see in Figure 22.51, the NetWare user JUSTIN has been transferred to the NT domain as JUSTINR. As you might recall, this transformation was dictated by the mapping file NW2NT.MAP. In the group listing, you can see the NTGATEWAY group that had been set up on the NetWare server to enable Gateway Service for NetWare to function. Figure 22.52 shows the NetWare to NT translated NTGATEWAY group, which has retained its only member: NTSERVER.
A mapping file is a very powerful way to have a NetWare migration run without errors and have the result look exactly as you would want. When you migrate multiple NetWare servers over to one NT domain, you will probably run into a lot of naming conflicts. Unless you are dealing with hundreds or thousands of users, which might make editing a mapping file too time-consuming, you can resolve most conflicts without having to deal with user intervention during the actual migration process.
File And Print Services For NetWare
Microsoft produces a tool that can be very helpful for easing NetWare to NT migrations: File And Print Services For NetWare. This exceptional product is sold separate from the Microsoft Windows NT Server 4.0 product.
The basic premise of File And Print Services For NetWare is allowing an NT server appear to the network as a NetWare 3.x server. This is achieved by adding a service to an NT server that emulates a NetWare bindery.
Two major uses for this product come to mind.
One is allowing an NT server coexist on a predominantly NetWare network, giving workstations running NetWare client software access to NT resources without having to run a Microsoft networking client.
Another reason would to ease a migration from NetWare to NT, by making the NT server emulate an existing NetWare server, making a switch from NetWare to NT transparent to the end user.
I will discuss scenarios for both of these reasons, but first I will tell you about installing the service.
Installing File And Print Services For NetWare
Installing File And Print Services For NetWare is the same as adding any other network service to Windows NT Server. Open the network applet in the Control Panel, and click once on the Services tab. Click on the Add button in the Services dialogue, as seen in . A list of installable services is shown in the resulting dialogue , however since File And Print Services For NetWare is not supplied with the Microsoft Windows NT Server product, click on the Have Disk button. As shown in , you will be prompted for the location of File And Print Services For NetWare installation files. Enter the proper path and click on the OK button.
Windows NT Control Panel Services Dialogue
Installable Services For Microsoft Windows NT Server
Selecting a Source Path
You now have the option to install the File And Print Services For NetWare service and administrative tools, or only the administrative tools. In I have chosen to install the File And Print Services For NetWare service and administrative tools. You would install only the administrative tools if you already have this service running on another server in the same domain, and wish to add the File And Print Services For NetWare extensions to User Manager and Server Manager.
File And Print Services For NetWare Install Options
After files are copied, the installation dialogue for File And Print Services For NetWare is displayed. It is here that you can give your pseudo-NetWare server a name, and you need to define a path for your SYS volume. The SYS volume on a File And Print Services For NetWare server will resemble the SYS volume on an actual NetWare 3.x server.
Install For File And Print Services For NetWare
If you do not create your SYS volume on an NTFS partition, you will be given a message. In order for you to be able to place permissions on the SYS volume in the same manner that you would on an actual NetWare server, the NTFS file attributes are absolutely necessary. If you do create the SYS volume on a FAT partition, you will be limited to only assigning Read or Read/Write permissions.
The directory structure for the SYS volume, as the directory SYSVOL, contains the LOGIN, SYSTEM, MAIL and PUBLIC directories that NetWare administrators are used to seeing on the SYS volume. The commands in the PUBLIC directory are Microsoft versions of the familiar NetWare commands. These commands are 100% compatible with their NetWare counterparts.
File And print services for NetWare SYS volume structure.
When the File And Print Services For NetWare service was installed, a SUPERVISOR account was created for the NT domain. This account is automatically added to the Administrators group. In this configuration dialogue, you define the password for the SUPERVISOR user account. You can also fine-tune the service by choosing the amount of resources to be used to handle this service.
After you have finished the installation for File And Print Services For NetWare you are prompted to enter a password for the service account that will be created and used for File And Print Services For NetWare . Enter the password twice, and click on the OK button to finalize the installation of File And Print Services For NetWare. The newly installed service will now appear in the list of installed services . Click on the Close button and you will be prompted to restart the NT server. Click on the Yes button, and your server will shutdown and restart. When the server reboots, the File And Print Services For NetWare service will be active.
Password for file and print services for NetWare service account.
Installed services in Control Panel.
You can test the service by running the NetWare SLIST command from any NetWare client workstation. The Windows NT server will appear on the list of NetWare servers, using the server name that you had specified in the installation dialogue.
File And Print Services For NetWare Extensions
Both User Manager and Server Manager will have new menu items that can help you administrate the NetWare-compatible facilities that File And Print Services For NetWare has given your NT server. These extensions allow you to perform tasks that are available through User Manager and Server Manager, however these extensions allow you to treat NetWare-compatible users as if they are logging into a separate NetWare server. I will go into detail on this in the next section, "Configuring File And Print Services For NetWare."
Configuring File And Print Services For NetWare
A new icon will appear in the Windows NT Control Panel. Double-click on the File And Print Services For NetWare icon to bring up the File And Print Services For NetWare applet. This applet allows you to change the server name, define the server as an "open system", and define whether or not you want clients who have not specified a preferred server in their NET.CFG file to be allowed to login to the pseudo-NetWare server. You can also gain access to the User Manager and Server Manager extensions that are also available through those administrative tools.
FPNW Icon in Control Panel.
File and print services for NetWare applet.
The User Manager extensions, shown in , adds a checkbox that allows you to specify if a user account will maintain a NetWare-compatible login. If this box is checked, you have access to the NW Compat button. Clicking on the NW Compat button brings up the NetWare Compatible Properties dialogue . Here you can set attributes for a user account that are not available for native NT clients, but are found on genuine NetWare administration tools. This includes limiting the number of concurrent connections for a user, and editing a login script. The login script for a NetWare-compatible user uses the same syntax that is used on NetWare servers for login scripts.
User Manager with FPNW extensions.
NetWare Compatible Properties dialog.
The Server Manager extensions gives you a new menu item. As shown in, a FPNW drop down menu gives you the ability to access the FPNW Control Panel applet, manage NetWare compatible volumes, and define NetWare-compatible print servers. You can also send NetWare compatible messages to NetWare-compatible users.
Server Manager FPNW extensions.
When I mention NetWare-compatible, I mean that these are resources for which the NetWare-compatible commands can be used on, such as CAPTURE and MAP. These are also the commands that can be used to create NetWare-compatible login scripts.
Creating and Maintaining NetWare Compatible Volumes
Using the FPNW menu in Server Manager, you can create, delete, or alter NetWare compatible volumes that you create using File And Print Services For NetWare. shows the Volumes dialogue that appears after selecting Shared Volumes from the FPNW menu. The volume that is listed is the SYS volume that was created when installing File And Print Services For NetWare. To create an additional volume, click on the Add button. The Create Volume dialogue prompts you for a volume name, and an existing directory to use for the new volume. Permissions and user connection limits can also be configured here. An upcoming section in this chapter "Migrating From NetWare To NT Using File And Print Services For NetWare" will show you how to use this dialogue for a smooth NetWare to NT migration.
NetWare-compatible volumes dialog.
The Create Volume Dialogue
Click on the OK button to complete the creation of the new volume, and the resulting list of volumes will show both the original and the new volume.
After The Creation Of A New Volume
Migrating From NetWare To NT Using File And Print Services For NetWare
One of the greatest benefits of using File And Print Services For NetWare can be realized when you are planning a NetWare to NT migration.
If you are in a NetWare environment, the workstations accessing NetWare are probably running different versions of the NetWare client, such as NETX, VLM, and running on different platforms, such as DOS, DOS/Windows, OS/2, Windows 95, and Windows NT. These workstation probably are running login scripts that are handling their connections to printers and volumes. Changing from a NetWare environment to a native NT client workstation involves a lot of work and planning, especially when you are dealing with dozens, hundreds, or even thousands of client workstations.
The Migration Tool For NetWare does a beautiful job in assisting with this process, but it is possible to perform a phased migration, and that is where File And Print Services For NetWare comes in very handy.
Lets use a simple example. A NetWare server named NW_SERVER has two volumes, SYS and VOL1. VOL1 contains a directory called APPS that contains numerous applications, each in their own subdirectory. A system login script maps drives for users based on their group memberships.
Under normal circumstances, a NetWare to NT migration would entail using the Migration Tools For NetWare to copy user accounts, groups, and volumes. Then an NT logon scripts could be created that emulated the commands used in the NetWare system login script. And finally, each workstation would require its NetWare client software changed over to a Microsoft networking client. Depending on the number of users, this could take hours, days, or months. It would also probably require leaving the NetWare server on-line while users are slowly migrated over to the NT environment.
Now picture this. Use the Migration Tool for NetWare to copy user accounts, group, and volume. Install File And Print Services For NetWare giving the pseudo-NetWare the name NW_SERVER. Now a login specifying that preferred server would give the user the same login, but this time, it would be to the NT server. Next is creating a directory on the NT server, and placing the APPS directory from the NetWare server into this directory on the NT server. Then create a volume named VOL1 using this directory as the path. The users would then still find their applications within the APPS directory on VOL1, again, only this time its not on the NetWare server, but on the NT server. All you have to do now is flag all of the users as NetWare compatible, and assign them their old system login script (after copying it over, of course). Follow the same logic for creating print queues with the same name as the original NetWare queues. Now you are free to bring down the NetWare server and have all of your users function the same as they had, without them even knowing that any type of change had occurred.
This would then give you time to slowly bring workstations over to Microsoft networking, by installing their new client software, creating an NT logon script or creating persistent connections to the network shares they require, and removing their User Manager attribute of being NetWare compatible.
Using File And Print Services For NetWare To Integrate NT Into a NetWare Environment
Sometimes a NetWare shop will require the use of an NT server because of one application that runs only on NT Server. Most of the NT servers my company sells into NetWare environments is due to programs that need Microsoft SQL Server as their database, so I see this a lot.
Since an NT server has a lot of power to offer, and a company may not want to upgrade the hardware they are using for their NetWare servers, an ideal idea is to add new services to the NT server.
For instance, we have had customers that decided to attach CD-ROM drives to an NT server because they didnt want to invest in a dedicated CD server, or didnt want to attach any peripherals directly to their NetWare servers. File And Print Services For NetWare is the perfect solution for allowing current NetWare users access resources on an NT server without having to change their client software. By adding users to the NT server and flagging them as NetWare-compatible, they can map a drive, using their NetWare tools, to one of the CD-ROMs attached to the NT server.
File And Print Services For NetWare creates resources that are so NetWare-compatible, they can even be seen as part of a Novell NetWare NDS tree. I am adding an NT server that is running File And Print Services For NetWare to the NDS tree. Im adding a NetWare-compatible volume to this same NDS tree.
Adding a NT Server With File And Print Services For NetWare to a NetWare NDS Tree
Adding a NT Server File And Print Services For NetWare Volume To a NetWare NDS Tree
A NetWare NDS Tree Showing NT Resources
A printer that is attached directly to an NT servers parallel port can also be defined as a NetWare compatible print queue and accessed by any NetWare client workstation.
Of course, anyone using these services on the NT server must be licensed as an NT client, but the cost for this is minimal, and the benefits are great.
As you have just seen, Microsoft Windows NT Server makes it easy to integrate with NetWare, or even to migrate from NetWare.
The tools that are available, both with NT Server and as a separate product, can make your NetWare and NT integration easier than you probably thought.
Both Microsoft and Novell have been working to allow these two Network Operating Systems interact, and it seems that the ties are getting closer and closer.
Dont forget that migrating from one environment to the other requires a lot of planning. But if you get familiar with the tools Ive just written about, you should be able to create a plan that will run very smoothly.