Some of the main topics in this chapter are
Microsoft and Novell have made much progress toward making Windows NT Server and NetWare work well together. This is good news for network administrators, many of whom need to support both platforms as part of a corporate network. Sometimes this support is temporary, such as during a transition from a legacy NetWare 3 environment to a Windows NT Server- based network, but other times it is ongoing, such as when an organization has defined strategic roles for both server platforms.
Complicated, heterogeneous networks are more the rule than the exception today, and knowing how to integrate them is one of the most valuable skills you can acquire. Novell's former dominance of the networking industry virtually ensures that most networking professionals will benefit from knowing how to integrate Windows NT Server with it. Today, though no longer able to dominate the networking industry as before, Novell's file and print server products still have many strong proponents and a larger installed base than Microsoft's do.
It's important to understand something about the typical architecture of a Novell network before discussing how Windows NT Server works as a part of one. Novell NetWare was designed primarily to make a shared, remote hard drive on the server look like a local hard drive to the client workstations on the network. When a NetWare server was running, client workstations could log on to the server and "map" drive letters from their workstations to directories on the server. Similarly, clients could also "capture" their printer ports and redirect them to shared network printers.
NetWare's architectural design took place in the early to middle 1980s, when computers were much more primitive than they are today and required many compromises so that the server could achieve good enough performance to be workable. All modern versions of NetWare still perform that basic file and print sharing relatively well; however, the architecture of the system hasn't kept up with the changing needs of modern networks that require more from their servers than they used to. The only fundamental change from older versions of NetWare to newer versions was the addition of Novell Directory Services (NDS), a hierarchical, distributed database of network information loosely based on the X.500 standard.
There are two major families of Novell's NetWare that you should know about. These two branches of the Novell family tree are NetWare 3.x and NetWare 4.x (including IntranetWare). Both require dedicated servers that cannot support any local users, provide administrators with a text mode interface for working directly with the server, and require that some administration issues (like adding users or configuring printing) be handled from a client workstation. Client computers for either kind of NetWare can run DOS, Mac OS, UNIX, Windows 95, or Windows NT. NetWare 4.x adds NDS, some limited optional memory protection, and Windows-based administration tools. IntranetWare is essentially NetWare 4.x with some additional features bolted on, such as a Web server and an IP to IPX gateway.
As the need arose for network servers to do more than file and print sharing, Novell started having problems because its server architecture was unfriendly to developers and didn't offer any memory protection to keep poorly written server programs (usually called NetWare Loadable Modules, or NLMs) from crashing the entire system. Anyone who has worked with NetWare for more than a short period of time is familiar with the system crashes and other problems a misbehaving NLM can easily cause. These problems, combined with Microsoft's release of Windows NT Server, have created a huge demand for people with the skills to integrate Windows NT Server into existing Novell networks.
The types of integration discussed in this chapter are:
All of these except Services for NetWare and Novell's NetWare/IntranetWare Client for Windows NT are included with Windows NT Server. Services for NetWare is a retail product that lists for about $150 U.S., whereas Novell's client for Windows NT is freely downloadable from the Web (http://support.novell.com/).
The Gateway (and Client) Service for NetWare is a service that comes with Windows NT Server and can do two things after it is installed.
The Gateway Service for NetWare provides access to NetWare resources.
Windows NT Server and clients for Microsoft networks use the SMB protocol for functions toward the upper layers of the OSI model, and so Microsoft clients translate their needs for network services to SMB requests. Windows NT Servers receive these SMB requests, execute the requested action, and send back replies using the SMB protocol. The transport protocol used for the transmission of SMB requests can be NetBEUI, TCP/IP, IPX, or another protocol (Digital supplies the DecNET protocol as one of the choices).
NetWare servers and clients, however, use the IPX/SPX transport protocols and the NCP protocols. Other protocol choices, such as TCP/IP or AppleTalk, are possible on NetWare servers and clients, but the native protocol used is IPX and NCP. Although Windows NT Server and Microsoft clients can use the IPX protocol via NWLink, they do not natively support the NCP used by NetWare.
After you install and configure the Gateway (and Client) Service for NetWare, it can receive SMB requests and translate these into equivalent NCP requests to the NetWare server (see Figure 46.2). The NetWare server processes the requests and sends and the replies to the Gateway (and Client) Service for NetWare running on the Windows NT Server. The gateway service translates the replies back to SMB replies and sends them back to the original client using whatever transport protocol they were requested with. As far as the Microsoft clients are concerned, the NetWare server resources appear to be on the Windows NT Server. This is good because the NetWare resources are therefore available without requiring any change to the Microsoft clients. Because the access to NetWare services occurs through a gateway, the performance is not as good as when using direct access to NetWare servers.
The Gateway service for NetWare does protocol translation between SMB and NCP.
The gateway solution to NetWare servers is fine for a small network or for occasional NetWare access. The MS clients share a single network connection to the NetWare server and take up only a single user license on the NetWare server. Legal issues aside, however, the moral issue remains: The original intent of the NetWare server license is circumvented. The gateway service enables you to make use of multiple user sessions to the NetWare server without paying for them.
If the NetWare servers are accessed as a primary resource, you may be better off to install the Gateway (and Client) Services for NetWare on all the Windows NT systems so that they can enjoy higher-speed access to NetWare and benefit from using native NetWare security (instead of everyone having the same privileges via the NTGATEWAY account) and skip using the gateway portion of the service (see Figure 46.3).
Some NetWare 4.x applications will not work with the Microsoft client for NetWare, so Novell supplies a separate client for Windows NT workstations--the Novell IntranetWare Client for Windows NT--which is fully NDS-compliant and can be used to access any NDS resources on a NetWare 4.x network. The Novell IntranetWare Client for Windows NT is available from Novell at http://support.novell.com/ and through Novell's NetWare forums on CompuServe.
Client Services for NetWare enables Windows NT Workstations to access NetWare servers.
Before Installing the Gateway (and Client) Services for NetWare. Before you install Microsoft's Gateway (and Client) services for NetWare, remove any existing NetWare redirectors such as the Novell IntranetWare Client for Windows NT from Novell. These redirectors will conflict with the redirector capability provided by the Gateway Services for NetWare if you do not remove them.
If these redirectors are installed, you can use the following list as a guideline for removing these redirectors:
2. Double-click the Network icon in Control Panel.
3. In the Network dialog box, select the Services tab and highlight the network redirector to remove.
4. Choose Remove.
5. Confirm your choice to remove the redirector.
6. Select Close from the Network dialog box.
7. Choose Yes to restart the Windows NT computer to make your changes effective.
Gateway Services for NetWare uses the NWLink (IPX/SPX) transport protocol. If this protocol is not installed, it is automatically installed as part of the installation procedure for Gateway (and Client) Services for NetWare.
Installing the Gateway (and Client) Services for NetWare. Use the following as a guideline to install and configure Gateway Services for NetWare:
2. Open Control Panel and select the Network icon. You should see the Network dialog box (see Figure 46.4).
You configure different network options in the Network dialog box.
3. Select the Services tab and choose Add. You should see the Select Network Service dialog box.
4. Select the Gateway (and Client) Services for NetWare and then choose
OK.
You should see a dialog box prompting you for the path of the distribution files.
If you installed from a CD on the Windows NT Server, the path to the CD distribution
files will be listed by default.
5. Choose Continue. You should see the Installing NWLink IPX protocol and
related components information box and a status of the copy operation as files are
copied.
At the return of the Network Services screen, choose Close. The Network Settings
Change information box will ask if you want to restart the computer for the settings
to take effect. Select Yes.
6. If you have not installed the NWLink protocol prior to installing Gateway Services for NetWare, you see the Select Preferred Server for NetWare dialog box after you log on. Use this dialog box to indicate your preferred NetWare server if you're using NetWare 3.x or bindery emulation on a NetWare 4.x server to make it appear to the network as a NetWare 3.x compatible server. Otherwise, select Default Tree and type in the tree and context information. If you set the name of a valid NetWare server, the Gateway Services for NetWare tries to log on using the username and password specified when you logged on to the Windows NT Server. If such a username does not exist on the NetWare server, the logon fails, and you're prompted to reenter the information.
7. When the system reboots, a new icon labeled GSNW (Gateway Service for NetWare) is added to Control Panel.
TIP: If you are logging on as Administrator on the Windows NT Server, you should know that, by default, no user accounts are named Administrator on the NetWare server. On a NetWare 3.x server, the administrator account is SUPERVISOR, and on a NetWare 4.x server, the administrator account is Admin. If bindery emulation is set on the NetWare 4.x server, a virtual SUPERVISOR account exists in that context on the NetWare 4.x server.
If you're setting up gateway services to a NetWare 4.x network, consider renaming the Windows NT Server gateway account to the shortened name Admin if you want everyone using the gateway to have full privileges to everything on the NetWare 4.x network or if you've restricted the default rights Admin has on the NetWare servers. This matches the name of the Admin account on the NetWare 4.x server.
Alternatively, you could just create accounts on both systems with the same username and appropriate non-administrative privileges on each so that you don't accidentally do something you'll regret. We'll walk through it this way later in the chapter in the sections "Configuring NetWare 3.x Servers with Gateway Accounts" and "Configuring NetWare 4.x/IntranetWare Servers with Gateway Accounts Using NWAdminNT."
By default, the NetWare network is added as the first network provider to be searched by the Multiple UNC Provider (MUP), which coordinates among the several possible redirectors, when resolving UNC names, to make sure that the correct redirector receives the request.
Before successfully configuring the Gateway Services for NetWare, you must create the following accounts:
The NetWare user account is used by the Gateway Service for NetWare to create a connection with the NetWare server. This connection appears to the Windows NT Server as a redirected drive. Windows NT Server can share the redirected drive as if it were a local resource on the Windows NT Server.
For example, you could create a network connection on drive N: to the NetWare directory that has the UNC name of \\NW411\SYS\APPS. You could then share drive N: as if it were a local drive on the Windows NT Server. If the share name is NWAPPS and the Windows NT Server computer name is NTSA, Microsoft clients can access this resource using the UNC name of \\NTS4\NWAPPS (see Figure 46.5). The shared resource can be on the Windows NT Server or the NetWare server, and this fact is completely transparent to the Microsoft clients.
Use a Windows NT Server shared name to access NetWare resources.
The user connection to the NetWare server used for the Gateway Service for NetWare is global to all users on the Windows NT server. The gateway user connection still exists when a user logs off from the Windows NT server. The user connection for the gateway connection is disconnected only if the Windows NT server or NetWare server is shut down, or the Windows NT server administrator disables the Gateway Service. Note that all clients accessing NetWare files through the gateway service will have the same rights on the NetWare server. You would have to create different shares to control each user's effective rights on the NetWare server by limiting who can access each share and the rights on the share.
NOTE: Because the user account and the NTGATEWAY group account are on the NetWare server, the NetWare administrator has total control over the rights allowed through the Gateway Service for NetWare. You must coordinate with the NetWare administrator to assign the rights needed by Microsoft clients.
The following sections describe the steps for configuring the Gateway Service for NetWare:
2. Enable the Gateway Service for NetWare.
3. Set permissions on the gateway share.
Configuring NetWare Servers with Gateway Accounts. You must create a user account and make this user a member of a specially created group called NTGATEWAY that is used for Gateway Service for NetWare.
On a NetWare 3.x server, you use the NetWare system administrator tool called SYSCON for creating user and group accounts. On a NetWare 4.x or IntranetWare server, you use the system administration tools NETADMIN in a DOS session, or the graphical NetWare Administrator (NWADMNNT.EXE) in Windows NT. Your NetWare administrator must assist you in setting up these accounts.
In case you're both the Windows NT Server and NetWare administrator, the following procedures can be used as a guideline in setting up user accounts. For additional details, consult the Novell documentation or any of the third-party books on NetWare. We'll start with the older NetWare 3.x systems first.
Configuring NetWare 3.x Servers with Gateway Accounts. Although NetWare 3.x is an older technology and a huge administrative burden in large networks, many people transitioning to Windows NT Server are still using it. People who aren't used to NetWare often find the text mode utilities that NetWare 3 uses confusing, so we'll cover in some detail how to use them to set up gateway accounts. To create user and group accounts on a NetWare 3.x server:
2. Run SYSCON.
3. Select User Information. You should see the list of currently defined users.
4. Press Insert to add a new user.
You are prompted to enter a username. Enter a suitable username that is to be used
by the Gateway Service for NetWare, such as NTGWUSER, and press Enter.
You are asked to enter a path to the user's home directory. Accept the default home
directory or specify another path. If the directory does not exist, select Yes to
verify creation of the home directory.
The new username appears in the Users List.
5. Select the new username. You see a list of administrative tasks that you can perform on the new user.
6. Select Change Password to set the user's password.
7. Select Account Restrictions to verify that no logon restrictions exist and that the account is enabled by default (see Figure 46.6). As a precaution, you might want to set Allow Users to Change Passwords to No.
Verify in Account Restrictions that the gateway account on the NetWare 3.x server is enabled.
9. Select Trustee Directory Assignments in the User Information settings to assign rights to the Windows NT user account to the NetWare file system (see Figure 46.7).
Set the Trustee Directory Assignments for a user.
Here the directory SYS:DATA has been added to the Trustee Directory Assignments.
Syscon displays a list of Trustee Rights Granted.
Syscon displays a list of Trustee Rights Not Granted.
11. Select Group Information. You should see the Groups currently defined on the server.
12. Press Insert to add a new group name. Enter the group name NTGATEWAY and press Enter. You should see the newly created group NTGATEWAY.
13. Select the newly created NTGATEWAY account. You see the Group Information task list for the new group account (see Figure 46.11).
The Group Information list contains details of the group's privileges.
15. Press Insert. You see the Not Group Members list.
16. Highlight the Windows NT user that you just created and press Enter to add this user as a member of the NTGATEWAY group.
17. Press Esc to return to the Group Information list.
18. Select Trustee Directory Assignments to add to the group rights to NetWare directories. The procedure for adding directories to the Trustee Directory Assignments list is the same as that discussed in Step 9. Use this as a guideline to adding to the trustee assignments for the NTGATEWAY group.
19. Press Esc or Alt+F10 to exit SYSCON.
Configuring NetWare 4.x/IntranetWare Servers with Gateway Accounts by Using NWAdminNT. On a NetWare 4.x or IntranetWare server, you need to create the user and group objects in the container that is part of the bindery context. If, for example, the SET BINDERY CONTEXT command on a NetWare 4.x server is the following, then you can create the user and group objects in any of the containers O=SOLUTIONS or OU=CORP.O=SOLUTIONS (see Figure 46.12).
SET BINDERY CONTEXT = O=SOLUTIONS;OU=CORP.O=SOLUTIONS
This is the Windows NT gateway user and group accounts and the NDS tree.
To create the necessary accounts for the Gateway Service for NetWare on a NetWare 4.x server:
2. Start the NetWare Administrator tool.
NOTE: Installing and using the NetWare Administrator on the Windows NT computer is covered under "NetWare Client and Administrator for Windows NT," but it will only run with the Novell client installed, not the Microsoft one. You might have to use a different workstation for this part or install Novell's client, add the user, remove Novell's client, and install Microsoft's Gateway (and Client) Service.
Here is the NetWare Administrator main screen.
4. Right-click the selected container and select Create. You should see the New Object dialog box.
5. Select the user object from the list of Class of New Object, and choose OK.
6. The Create User dialog box appears. Enter the Login Name for the Windows NT user account to be used by the Gateway Service for NetWare. This can be a username such as NTGWUser. Enter the Last Name; the actual value of this field is unimportant. It is, however, required for complying with the X.500 standard. Check the Define Additional Properties box.
The SOLUTIONS container under ROOT is selected for creating user and group accounts.
Type in the gateway user information in the User's properties dialog box.
9. Select Change Password and specify the NTGWUser's password. Click OK after you've entered it for your change to take effect and to return to the Additional Properties dialog box. Select Cancel to exit the dialog box.
10. Right-click the same container again, and select Create.
You can set password limitations in the Password Restrictions dialog box.
12. In the Group Name field, enter NTGateway.
13. Check the Define Additional Properties box; then choose Create. You should see the group object properties dialog box (see Figure 46.17).
Type the gateway account information in the Group object's properties dialog box.
15. Choose Add. The Select Object dialog box appears.
16. Select NTGWUser from the Objects list box, and choose OK. The Windows NT gateway user is now a member of the NTGateway group object.
17. Choose OK. You can see the newly created user objects in the selected container. Figure 46.18 highlights the Windows NT gateway and user accounts just created.
The Windows NT gateway and user accounts on a NetWare 4.x server.
Click a volume to display the directories under the volume object.
Set the rights for the trustees of the directory.
Choose trustees in the Select Object dialog box.
21. Select the Windows NT user and group gateway accounts in the Objects list box and click OK. Figure 46.22 shows that the Windows NT gateway accounts are added as trustees to the directory. Use the Access Rights and Inheritance Filter boxes to assign appropriate rights to the Windows NT user and group gateway accounts.
The Windows NT gateway and user accounts are trustees of the directory.
Enabling the Gateway Service for NetWare. After you have created the user and NTGATEWAY group account on the NetWare server, you can use this information to enable the Gateway Service for NetWare on the Windows NT Server. To enable the gateway, follow these steps:
2. Double-click the Gateway Service for NetWare (GSNW) icon in Control Panel. The Gateway Service for NetWare dialog box appears (see Figure 46.23).
Configure the gateway by using the Gateway Service for NetWare dialog box.
4. Check the Enable Gateway box to enable the Gateway Service.
Enable the gateway in the Configure Gateway dialog box.
6. Choose Add to create a NetWare share to be used by Microsoft networking clients. You should see the New Share dialog box for creating the NetWare share (see Figure 46.25).
The NetWare share APPS is assigned to the Gateway Service for NetWare.
In the Network Path field, enter the NetWare directory name using the UNC name. If, for example, the NetWare directory is SYS:APPS on a server named HOME, then the UNC name is \\HOME\SYS\APPS. Similarly, if the NetWare directory is the root of the SYS: volume on the NetWare server HOME, the UNC name is \\HOME\SYS.
In the Comment field, enter some descriptive text about the share name. This comment is visible to MS clients that examine shares on the Windows NT Server.
In the Use Drive field, select a drive letter on the Windows NT Server to be assigned to the NetWare directory. This drive letter is used as long as the Gateway Service for NetWare is running. By default, the first drive assigned is Z: for the first share name.
In the User Limit box, you can control the number of users who share the NetWare connection, or specify an unlimited number of users. For load-balancing purposes, you might want to control the number of users using a particular share name.
7. Choose OK to save your changes. You return to the Configure Gateway screen.
8. Choose OK to exit the Configure Gateway dialog box.
9. Choose OK to exit the Gateway Service for NetWare dialog box. Your changes will take effect next time you log on.
Setting Permissions on the Gateway Share. After the share name for accessing the NetWare directory is created, you can set access permissions on it. Setting permissions for the NetWare directory is conceptually similar to setting permissions on native Windows NT directory shares; in this case, however, you use the Configure Gateway Service.
To set access permissions by using the Gateway Service:
2. Double-click the GSNW icon in Control Panel.
3. When the Gateway Service for NetWare dialog box appears, choose the Gateway button.
4. In the Configure Gateway dialog box that appears, highlight the NetWare share name and choose Permissions. If this button is grayed out, make sure that the Gateway Service is enabled and running. You should see the current permission settings for the share name.
By default, the Windows NT group Everyone has Full Control over the share name (see Figure 46.26). This is the default permission that is set for all new shares in Windows NT. You might want to restrict the share permissions in a secure environment. You can set the permissions to No Access, Read, Change, or Full Control.
Set access restrictions in the Access Through Share Permissions dialog box.
The share-level permissions that you set for a share name apply to all MS clients that access the share. If you need to have separate permissions set for different MS clients, you must create separate share names and set permissions on each share name.
The trustee rights settings on the NetWare directory override any share-level permissions that you set. For example, if the NetWare directory rights are set to allow Read (R) and File Scan (F) rights and you set the share name to have Change permissions, the MS client is not able to modify, create, or delete files on the NetWare server, even though they are allowed these Change permissions through the Change share permissions. Figure 46.27 graphically illustrates the order in which the permissions are applied.
The order permissions are applied for a Gateway Service connection to NetWare with Windows NT.
Tables 46.1 and 46.2 show the NetWare rights equivalents to the Windows NT file permissions for directories and files. Table 46.3 shows the NetWare file attributes and the corresponding Windows NT file attributes.
| NetWare Directory Rights | Windows NT Directory Permissions |
| Supervisor (S) | Full Control (All) (All) |
| Read (R) | Read (RX) (RX) |
| Write (W) | Change (RWXD) (RWXD) |
| Create (C) | Add (WX) (not specified) |
| Erase (E) | Change (RWXD) (RWXD) |
| Modify (M) | Change (RWXD) (RWXD) |
| File Scan (F) | List (RX) (not specified) |
| Access Control (A) | Change Permissions (P) |
| NetWare File Rights | Windows NT File Permissions |
| Supervisor (S) | Full Control (All) |
| Read (R) | Read (RX) |
| Write (W) | Change (RWXD) |
| Erase (E) | Change (RWXD) |
| Modify (M) | Change (RWXD) |
| Access Control (A) | Change Permissions (P) |
| Read Only (R) | Read Only (R) |
| Delete Inhibit (d) | Read Only (R) |
| Copy Inhibit (Ci) | None |
| Rename Inhibit (R) | Read Only (R) |
| Archive (A) | Archive (A) |
| System (Sy) | System (S) |
| Hidden (H) | Hidden (H) |
| Immediate Compress (Ic) for NetWare 4.x | Compression (c) for Windows NT 3.51 and later using NTFS |
| Read Write (Rw) | None |
| Don't Compress (Dc) | None |
| Shareable (Sh) | None |
| Transactional (T) | None |
| Indexed (I) | None |
| Migrate (M) for NetWare 4.x | None |
| Don't Migrate (Dm) for NetWare 4.x | None |
When you log on to a Windows NT Server configured as a Gateway for NetWare, the logon process automatically attempts to log you on to a NetWare server by using the user name that you use to log on to the Windows NT Server (see Figure 46.28). If your username and passwords are different on the Windows NT Server and the NetWare server, you're prompted for a username or password. It's more convenient to users for logon and authentication purposes when the username and password are the same on the Windows NT Server and the NetWare server. If this is so, your credentials are passed through, and you aren't prompted for a separate username and password to connect to the NetWare server.
The Client portion of Gateway Service for NetWare provides transparent access to the NetWare server from an NT logon.
A part of the Gateway (and Client) Service for NetWare is a NetWare client service that's available to any user logging on to the Windows NT Server, as shown in Figure 46.28. Other MS clients cannot share the network connections established with this client connection. This network connection is for the convenience of the locally logged-on user to the Windows NT Server, who is typically a network administrator. To share a connection to the NetWare server, you must configure the Gateway Service for NetWare as described in the previous section. Other MS clients share the network connection to the NetWare server by using the share name assigned for this purpose.
To simplify logon to the NetWare server when a user logs on to the Windows NT Server, you should keep the same username and passwords on the Windows NT Server and NetWare server. To change the username and password on a Windows NT Server, use User Manager for Domains. On NetWare 3.1 servers, you can use the SETPASS command or the SYSCON tool. To provide transparent access to several NetWare 3.x servers, you need to change the password of the user account on all NetWare servers. Because NetWare 4.x user accounts are global to the network, you need to change the user password only once in the global database. You can use either NETADMIN or one of the Windows versions of the NetWare Administrator (NWADMN3X or NWADMNNT) to change your NetWare 4.x user password.
You can run the SETPASS utility from the SYS:PUBLIC directory of a NetWare server or from the Windows NT command prompt. For example, if drive N: is mapped to the SYS: volume on a NetWare server, NWS, you can use the following from a Windows NT command prompt:
N:> cd public N:\public> setpass
To configure the preferred connection for the logged-on user, you must log on as the user and use the following procedure:
2. From the Select Preferred Server, select the NetWare server that is the preferred server. If <None> is specified, the client connects to the first server that responds to a Get Nearest Server request from the client.
If the preferred server option is set, the next time you log on, the Gateway Service for NetWare connects to the NetWare server you specified as the preferred server.
NOTE: Note that the preferred server only affects the account that you log on as when setting the preferred server option. If another user logs on, he or she can have a different server name as the preferred server.
If the Gateway Service for NetWare is installed and configured, you can use any Microsoft network client to access the NetWare directory that's shared on the computer acting as the gateway.
To connect to a NetWare share for Gateway clients:
2. Start Windows NT Explorer.
3. Choose Tools, Map Network Drive.
4. You should see the Map Network Drive dialog box (see Figure 46.29). Double-click the Windows NT Server running the Gateway Service for NetWare. You should see the share names on the Windows NT Server. One of these share names is the NetWare server share name.
The share name NWAPPS is provided by the Gateway Service for NetWare running on the Windows NT Server NTS4.
This is the Map Network Drive dialog box.
6. Select the drive letter to assign for accessing the gateway share name in the Drive field.
7. Network drive connections can be made persistent, which means that an attempt is made to create the connection every time you log on. If you are using the File Manager and want to make the network connections persistent, make sure that the option Restore At Logon is set.
8. Choose OK to connect the network drive.
Occasionally, you might find it more convenient to connect to the NetWare directory from the command prompt. The NET VIEW command can be used to view the NetWare servers on the network from a Windows NT Server configured with Gateway Service for NetWare, or a Windows NT Workstation that has the Client Service for NetWare installed. To display a list of NetWare servers, use the command NET VIEW /NETWORK:NW. The following is an example of using this command on a sample network with four NetWare servers:
> NET VIEW /NETWORK:NW Resources on NetWare Network ----------------------------------------------------------------------- \\HOME \\DC \\REDMOND \\PHILY The command completed successfully.
The previous command shows the NetWare servers HOME, DC, REDMOND, and PHILY are on the network. Remember, for this command to work, you must install one of the clients for NetWare on the Windows NT computer used to execute it.
To see a list of shared resources on a specific NetWare server on the network, use the UNC form of the NetWare server name with the /NETWORK:NW option:
> NET VIEW /NETWORK:NW \\HOME Shared resources at \\home --------------------------------------------------------------------- Print \\HOME\HP5M Print \\HOME\HP5M-PS Disk \\HOME\SYS Disk \\HOME\VOL1 The command completed successfully.
The previous command shows the NetWare server HOME is sharing two network printer queues (\\HOME\HP5M and \\HOME\HP5M-PS) and two disk resources (\\HOME\SYS and \\HOME\VOL1). The disk resources are the NetWare volume names on the server.
To connect a drive to a gateway share name, use the following syntax:
NET USE X: \\gatewayserver\netware_share
Replace X: with an unused drive letter. gatewayserver is the computer name of the Windows NT Server on which the Gateway Service for NetWare is configured. netware_share is the share name on the gateway server assigned to the NetWare directory. To create a network drive F: on a Microsoft client assigned to the NetWare share name NWSYS on the Windows NT Server NTS4, use the following command:
NET USE F: \\NTS4\NWSYS
To assign the next available drive to the NetWare share name, replace the drive letter with the asterisk symbol (*). For example, you could use the following:
NET USE * \\NTS4\NWSYS
If you receive a message that the password is invalid, it means that the username and password you specified when logging on to the Windows NT client could not be validated on the preferred NetWare server. You could connect under another valid username and password by using the following syntax for the NET USE command:
NET USE X: \\gatewayserver\netware_share /user:username password
Replace username and password with a valid user and password combination on the NetWare server.
CAUTION: Specifying the password on the command line itself is a security risk because someone might be able to read it from the screen. You can replace the password with an asterisk (*) if you want to be prompted for the password. The password you type at the prompt is not displayed on-screen.
You can use the NET USE command to examine the status of all network drive connections.
Network drive connections can be made persistent, which means that an attempt is made to create the connection every time you log on. To make the network connection persistent by using the NET USE command, make sure that you use the /persistent:yes option. For example, the following connection to the share name NWSYS on the Windows NT Server NTS4 is persistent:
NET USE F: \\NTS4\NWSYS /persistent:yes
This is the same as checking the Reconnect at Login box in Explorer when making the initial drive connection.
You can use the Gateway Service for NetWare to access two types of resources on NetWare servers: file resources and network printer resources. When you enable the gateway, you enable both file and print gateway functions. No separate step for enabling print gateway functions exists.
After the Gateway Service for NetWare is enabled, the NetWare print queues appear on the Windows NT Server as shared printers. Your next step for configuring the gateway is to configure the NetWare print gateway by using the Print Manager. By using the Print Manager, you define a share name for the print device on the NetWare network. The print share name can then be used by Microsoft clients to connect to the NetWare printers.
To configure the NetWare print gateway:
2. Double-click the Printers icon in Control Panel. Select the Add Printer icon. You should see the Add Printer Wizard main window.
3. Select Network Printer and then choose Next. You see the Connect To Printer dialog box. Click the NetWare Server icon to expand the network and select the NetWare print queues.
4. Choose OK.
5. An information box asks whether or not you want to install the print drivers on your local machine. Choose OK.
6. The Select Driver dialog box appears. Select the appropriate print driver and choose OK. Enter the path where the driver can be found and choose Continue. If you're prompted for Printer Setup information such as amount of RAM on printer, enter the information for the printer you've selected. The Printer Properties dialog box appears (see Figure 46.30). Click OK.
The Printer Properties dialog box shows the device settings.
NOTE: You're only prompted for a test page if this is the first time you've used a specific printer.
The configuration window for the newly created printer displays documents in the print queue.
9. By selecting Printer, Properties, you can configure General information, Ports, Scheduling, Sharing, Security, and Device Settings. After configuring the Printer Properties, choose OK.
Now that you've created a share name for the printer, MS clients on the network can use it.
After you've created a share name for the NetWare printer, a Microsoft client can connect to it by using the Print Manager. The following is an outline of the procedure for connecting to the NetWare print queue on the Windows NT Server running Gateway Service for NetWare; the procedure is similar to the first part of configuring the print gateway described in the previous section, so only the barest outline without any screen captures is presented:
2. Double-click the Printers icon in Control Panel.
3. Select the Add Printer icon and choose Network Printer from the Add Printer Wizard.
4. Browse the NetWare network in the Shared Printers box to select the share name corresponding to the NetWare print queue.
5. Click Next.
6. The Printer Wizard prompts you to select the manufacturer and model of the printer. Select them, and click Next.
7. The Printer Wizard prompts you with a suggested name for the printer. Accept or change it, and click Finish.
8. Windows NT copies the files from the installation CD or the path you specify.
9. When it's finished copying, the Add New Printer Wizard enables you to print a test page. Click OK if you're satisfied with the test page. You should now see the new printer icon in the Printers window.
You can connect to a NetWare printer by using the NET USE command. The following is the syntax for connection to the shared printer:
NET USE lptx \\gatewayserver\printshare
For example, to connect local printer LPT1 to the share name HP5M on the Windows NT Server NTS4, use the following command:
NET USE LPT1 \\NTS4\HP5M
This command redirects print jobs sent to port LPT1 to the print queue HP5M on the NTS4 server. Because HP5M is a share name for a NetWare print queue, this print job is further redirected to the NetWare print device.
The print options are set for the user logging on to the Windows NT Server acting as a Gateway Service for NetWare and also for the Microsoft clients using the Gateway Service using the same interface. Setting these print options affects all gateway users and all NetWare print queues being used on the Windows NT gateway server. To set the NetWare print options for all Windows NT gateway users:
2. Double-click the GSNW icon. The Gateway Service for NetWare dialog box appears.
3. In the Print Options section, you can specify any of the following options:
Many NetWare 3.x and some NetWare 4.x/IntranetWare tools can be run from the Windows NT Command prompt. These tools are designed to run on DOS workstations. When they run at the Windows NT command prompt, they run under Windows NT's DOS subsystem.
Table 46.4 lists the NetWare 3.x utilities supported by Windows NT. Some of these utilities require the SYS$MSG.DAT file or the $RUN.OVL file (for NetWare 3.x). These files are found in the SYS:PUBLIC directory on the NetWare 3.x server. If you run the NetWare 3.x utilities outside the SYS:PUBLIC directory, you might see error messages that indicate these files are missing.
To run SYSCON and other utilities that require access to the NetWare bindery, you must be logged on to the NetWare server. To log on to the NetWare server from a Windows NT computer, you must be running one of the NetWare clients on your Windows NT system.
| Supported NetWare Utility | Description |
| chkvol | Checks NetWare volume and reports information on volume |
| colorpal | Changes the color palette of the graphical tools |
| dspace | Sets disk space quota |
| flag | Changes file attributes |
| flagdir | Changes directory attributes |
| fconsole | File server console |
| filer | File Manager tool |
| grant | Assigns rights |
| listdir | Lists directories |
| map | Performs drive mapping |
| ncopy | Network copy of files |
| ndir | Network directory listing |
| pconsole | Printer console utility |
| psc | Print Server Control |
| pstat | Printer status |
| rconsole | Remote console |
| remove | Removes users/groups as trustees of directories and files |
| revoke | Revokes rights for directories and files from users/groups |
| rights | Assigns rights |
| security | Checks security of server |
| send | Send messages |
| session | Session Manager tool |
| setpass | Sets password for logged-on user on server |
| settts | Sets the logical and physical transaction tracking record lock thresholds |
| slist | Displays list of servers on network |
| syscon | General-purpose System Console tool used for administrator functions |
| tlist | Displays list of trustees for a directory/file |
| userlist | Displays list of active users and their connection information |
| volinfo | Dynamically displays information on volume usage and number of directory entries per volume |
| whoami | Displays information on currently logged-on user |
The Windows NT NET USE command can be used for performing the functions of the NetWare MAP and CAPTURE commands. The NET VIEW command can be used to perform the functions of the SLIST command.
Some applications that are NetWare-aware might not work with the NetWare client that you prefer to use. There is no way to know for certain about an application before you test it, but the most common problems seem to be related to applications that use NDS. Those sorts of applications seem to prefer the Novell client to the Microsoft client. Some people, however, report that one client or the other seems more stable in their particular environment. You should try the other company's client if the one you start with doesn't seem to be living up to your expectations.
Besides the Client Service for NetWare and the Gateway Service for NetWare, other applications running in the Windows NT environment can use the IPX/SPX protocol implemented by NWLink. The IPX protocol is datagram-based. It can be used for general- purpose delivery and network applications that need a broadcast capability. The IPX protocol does not provide a guarantee for delivery of messages. If you need guaranteed delivery, the applications must use SPX, which builds a transport layer connection on top of the IPX protocol.
Some applications use the NetBIOS API. Microsoft's NWLink supports a NetBIOS component that interfaces with the NWLink transport protocols. The NWLink NetBIOS includes Microsoft's extensions to Novell's NetBIOS implementation for DOS/Windows platforms.
The default settings for NWLink should be optimal for most network environments, and you should not have to change the NWLink parameter settings. If you need to change the NWLink parameters, such as bind the NWLink protocol to a different network adapter:
2. Double-click the Network icon in Control Panel.
3. From the Network dialog box, select the Protocols tab (see Figure 46.32). Highlight the NWLink IPX/SPX Compatible Transport and click Properties.
Click the Properties button to configure the IPX/SPX protocols.
Use the NWLink IPX/SPX Protocol Properties dialog box to configure the basic NWLink network options.
Each computer on a Token Ring network uses a source routing table maintained on the computer. The source routing table is used for finding the optimal path on Token Ring networks connected using interconnection devices such as bridges and routers.
When a Windows NT computer on a Token Ring network receives a broadcast packet, multicast packet, or a packet whose MAC address is not in its source routing table, by default the computer forwards the packet as a Single Route Broadcast (SRB) frame. If you need to modify this default behavior or clear the source routing table, you can do so by using the IPXROUTE utility.
Microsoft's IPXROUTE utility is based on Novell's ROUTE utility available for DOS and OS/2 clients. In fact, even some of the options in IPXROUTE are the same as those for ROUTE.EXE. IPXROUTE has been extended so that it can now manipulate the network layer IPX routing table.
To see the current settings for IPX/SPX packets, just type the command IPXROUTE without any options:
> IPXROUTE NWLink Routing and Source Routing Control Program v2.00 DEFault Node (Unknown) Addresses are sent using SINGLE ROUTE BROADCAST Broadcast (FFFF FFFF FFFF) Addresses are sent using SINGLE ROUTE BROADCAST Multicast (C000 xxxx xxxx) Addresses are sent using SINGLE ROUTE BROADCAST
The preceding command shows that unknown addresses and broadcast and multicast addresses are sent in SRB mode. To see the information on IPX bindings, specify the CONFIG option:
> IPXROUTE CONFIG NWLink Routing and Source Routing Control Program v2.00 net 1: network number 000e8022, frame type 802.2, device CENDIS31 (0080c7d66f0f)
This command shows that the IPX network number of the network is E8022, the frame type is 802.2, and the driver name is CENDIS31. The node address of the Windows NT computer is 0080C7D66F0F.
Although the IPXROUTE command is designed for Windows NT computers on a Token Ring network, the commands listed previously also work on other networks such as Ethernet and FDDI. You, therefore, are able to use the IPXROUTE CONFIG command to discover the network number, frame type, driver name, and MAC address of a Windows NT computer on a network.The general syntax of the IPXROUTE command is shown next:
IPXROUTE IPXROUTE CONFIG IPXROUTE board=n [clear] [def] [gbr] [mbr] remove=xxxxx
The IPXROUTE command changes the parameters only for the current Windows NT session. When you log off or reboot, the current settings are lost. You can place the IPXROUTE command in the logon script or set the parameters in the Registry to make the changes permanent.
Whenever possible, you should change NWLink parameters by using Control Panel. If you need more direct control over the NWLink parameters, however, or you need to change parameters that cannot be changed using normal administrator tools, you can change the parameter settings in the Registry.
CAUTION: Exercise extreme caution when changing Registry values. Incorrect values can permanently disable your Windows NT computer or make the Windows NT computer operation inefficient. Always make a backup of your Registry files before manually editing them.
Not all parameters listed in this section might exist in the Registry. If a specific parameter does not exist, the default value listed in this section applies. If you need to change the default value, you must add that key to the Registry before you can change its value.
The Registry Editor is started by running the REGEDT32.EXE program. If you have created an icon for this program, you can double-click the icon. Make sure that you use REGEDT32 rather than REGEDIT because the latter one only enables you to modify file and application relationship Registry information. You can start the Registry Editor from the command prompt by using either of the following:
REGEDT32 START REGEDT32
The last command returns control to the command prompt after starting the Registry Editor.
To change the NWLink parameters, activate the HKEY_LOCAL_MACHINE window. Figures 46.34 and 46.35 show the IPX and SPX parameters under their respective keys. The IPX parameters can be controlled by using the value entries under this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NWLnkIPX\Parameters
The SPX parameters can be controlled by using the value entries under this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NWLnkSPX\Parameters
NWLink IPX parameters can be found in the Registry.
Tables 46.5 and 46.6 describe the IPX and SPX Registry value entries. All the Registry values used for configuring IPX and SPX are of type REG_DWORD.
NWLink SPX parameters can be found in the Registry.
| Parameter | Description |
| RipAgeTime | The IPX protocol uses the Routing Information Protocol (RIP) to find routes to computers on the network. This parameter informs RIP how long to wait before requesting an update for a route entry in the RIP routing table. The RIP timer for a route entry is reset when a new updated is received. It can range from 1 to 65,535 minutes and has a default value of 5 minutes. |
| RipCount | If RIP is unable to find a route on the network, it retries to find the route. This parameter controls how many times RIP tries to find the route before giving up. It can range from 1 to 65,535 and has a default value of 5. |
| RipTimeout | This controls the time-out period for not receiving a reply for a RIP request to find a route on the network. It can range from 1 to 65,535 half-seconds and has a default value of 1 half-second. |
| RipUsageTime | IPX builds a cache of the RIP routing table. If an update for a route entry is not received for a period of time, that entry is deleted from the cache. This parameter controls the maximum age of a route entry before deleting the route entry. An update to a route entry resets the timer. It can range from 1 to 65,535 minutes and has a default value of 15 minutes. |
| SourceRouteUsageTime | This parameter controls the maximum age of an unused entry in the source routing cache of a Windows NT computer on a Token Ring network. The entry is deleted after this interval. It can range from 1 to 65,535 minutes and has a default value of 15 minutes. |
| InitDatagrams | This parameter controls the number of datagram buffers initially allocated for IPX. It can range from 1 to 65,535 and has a default value of 10. |
| MaxDatagrams | This parameter controls the number of maximum datagram buffers allocated for IPX. It can range from 1 to 65,535 and has a default value of 50. |
| SocketStart | This parameter specifies the start of the range of socket numbers that are dynamically allocated. It can range from 0 to 65,535 and has a default value of 0x4000. |
| SocketEnd | This parameter specifies the end of the range of socket numbers that are dynamically allocated. It can range from 1 to 65,535 and has a default value of 0x8000. |
| SocketUniqueness | This parameter specifies the number of sockets starting with SocketStart that are set aside when assigning socket numbers. If SocketUniqueness is set to 8 and SocketStart is 0x4000, then sockets 0x4000 to 0x4007 are set aside. It can range from 1 to 65,535 and has a default value of 8. |
| VirtualNetworkNumber | This is the IPX internal network number for the Windows NT computer. It can range from 0 to 4,394,967,295 and has a default value of 0. |
| RipTableSize | This controls the number of buckets used in the RIP hash table. The hash table is used for quickly finding RIP entries. Increase this value only if you expect the RIP table to be very large. It can range from 1 to 65,535 and has a default value of 7. |
| DedicatedRoute | When set to 1, the computer is used as a dedicated router and does not have services running on it. This is treated as a Boolean with value of 0 or 1. The default value is 0 (non-dedicated). |
| EthernetPadToEven | When set to 1, Ethernet frames that are sent should be padded to even length to accommodate other computers that can receive only even-length frames. This is treated as a Boolean with a value of 0 or 1. Default value is 1. |
| SingleNetworkActive | When set to 1, only the LAN or WAN link can be active on the computer. This is used in the Gateway Service for NetWare to correctly locate the NetWare servers on the WAN when dialing in. This is treated as a Boolean with a value of 0 or 1. Default value is 0. |
| DisableDialoutSap | When set to 1, Service Advertising Protocol, or SAP, announcements and responses are not sent on dial-out WAN links. This prevents SAP traffic from saturating the WAN link. This is treated as a Boolean with a value of 0 or 1. Default value is 0. |
| DisableDialinNetbios | When set to 1, NetBIOS packets of type 20 are not sent on dial-in lines. This prevents unneeded NetBIOS traffic from saturating a dial-in WAN link. Set this to 0 only if a NetBIOS application on the local computer needs to connect to a remote computer over a dial-in WAN link. This is treated as a Boolean with a value of 0 or 1. Default value is 1. |
| Parameter | Description |
| ConnectionCount | This controls the number of times connection attempts (connection probes) are made to connect to a remote node if no response is received in the time specified by the ConnectionTimeout parameter. It can range from 1 to 65,535 and has a default value of 10. |
| ConnectionTimeout | This controls the time between connection requests to connect to a remote node. It can range from 1 to 65,535 half-seconds and has a default value of 2 half-seconds (1 second). |
| KeepAliveCount | When there is no activity on an SPX virtual circuit, a keep-alive packet is sent to verify whether or not the connection is still valid. The keep-alive packet verifies whether the remote node is reachable and active. This parameter controls the number of times the keep-alive packet should be sent if there is no response. It can range from 1 to 65,535 and has a default value of 8. |
| KeepAliveTimeout | When there is no activity on an SPX virtual circuit, a keep-alive packet is sent to verify whether or not the connection is still valid. This parameter controls the time that the node should wait before sending a probe to the remote node to verify that the SPX virtual circuit is still valid. It can range from 1 to 65,535 half-seconds and has a default value of 12 half-seconds (6 seconds). |
| WindowSize | SPX uses an allocation field to tell the remote node how many receive packet buffers it has. The value in the Allocation field is called the window size because it controls how many packets the remote can send before the buffers overflow. This parameter specifies the initial value to place in the Allocation field. It can range from 1 to 10 SPX packets and has a default value of 4. |
| InitPackets | This parameter specifies the initial number of packet buffers SPX allocates. It can range from 1 to 65,535 and has a default value of 5. |
| SpxSocketEnd | This parameter specifies the end of the range of SPX socket numbers that are dynamically allocated. It can range from 1 to 65,535 and has a default value of 0x7FFF. |
| SpxSocketUniqueness | This parameter specifies the number of SPX sockets starting with SocketStart that are set aside when assigning socket numbers. If SpxSocketUniqueness is set to 8 and SpxSocketStart is 0x4000, then sockets 0x4000 to 0x4007 are set aside. It can range from 1 to 65,535 and has a default value of 8. |
| MaxPacketSize | This parameter is used to support SPX II that uses this parameter value to negotiate the maximum packet size the remote node can support. It can range from 1 to 65,535 bytes and has a default value of 4,096 bytes. |
| RetransmissionCount | This parameter controls the number of times a packet can be retransmitted while waiting for an acknowledgment for the packet. It can range from 1 to 65,535 and has a default value of 8. |
The NetBIOS parameter settings (see Table 46.7) can be controlled through the Registry. These parameters can be found under the following key (see Figure 46.36):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NWLnkNB\Parameters
NetBIOS parameters for IPX can be set in the Registry.
| Parameter | Description |
| Extensions | When set to 1, it specifies whether the NWLink NetBIOS extensions are to be used. It is treated as a Boolean type with a value of 1 or 0. The default value is 1. |
| AckDelayTime | This parameter controls the value of the delayed acknowledgment timer. It can range from 50 to 65,535 ms and has a default value of 250 ms. |
| AckWindow | This parameter controls the number of frames to receive before sending an acknowledgment. A value of 0 turns off the sending of acknowledgments. This parameter can be used for flow control. If the sender and receiver are separated by a slow link (WAN or satellite link) or a link that has considerable time delay, you can set this parameter to a larger value. If little delay occurs on the link, and both sender and receiver are matched in terms of speed of sending and receiving packets, you can set this parameter to 0 to turn off sending of acknowledgments to sender. The setting of the parameter AckWindowThreshold can also be used to determine whether the AckWindow parameter value is used. It can range from 0 to 65,535 frames and has a default value of 2. |
| AckWindowThreshold | This parameter specifies the threshold value for the estimated round-trip delay that defines when the AckWindow parameter value is ignored. If the round-trip delay is less than the value in AckWindowThreshold, the acknowledgments are not sent; that is, the value in AckWindow is ignored. If the round-trip delay is greater than the threshold value, the value in AckWindow is used. If the value of the AckWindowThreshold is set to 0, the value in AckWindow is used; that is, the threshold setting in AckWindowThreshold is ignored. It can range from 0 to 65,535 ms and has a default value of 500 ms. |
| EnablePiggyBackAck | When set to 1, acknowledgments can be sent if the data response is returned by the receiver to the sender. This parameter is called piggy-back acknowledgments because the acknowledgment gets a piggy-back ride on the data frame. This is more efficient than sending a separate acknowledgment frame. Piggy-back acknowledgments typically are sent when the receiver has detected the end of a NetBIOS message. If the traffic is one-way (simplex) with no expected response from the receiver, set this parameter to 0. If EnablePiggyBackAck is set to 1 (piggy-back acknowledgments enabled), but no reverse traffic from receiver to sender exists, the setting in the AckDelayTime parameter is used to determine when to send a separate acknowledgment packet. The piggy-back acknowledgment is temporarily disabled until the receiver begins to send data, at which time piggy-back acknowledgment support is enabled. It is treated as a Boolean type with a value of 1 or 0. The default value is 1. |
| RcvWindowMax | This specifies the number of frames the receiver can receive at one time. This parameter is exchanged during session negotiation so that the sender knows the upper bound on the number of frames to be sent at any one time. This parameter is affected by the settings of the AckWindow and the AckWindowThreshold parameters. It can range from 1 to 49,152 frames and has a default value of 4 frames. |
| Internet | When set to 1, this parameter specifies when to change the packet type from 0x04 to 0x14 (Novell WAN Broadcast). It is used as a Boolean type with a value of 1 or 0. The default value is 1. |
| BroadcastCount | This parameter specifies the number of times to send a broadcast. If the Internet parameter is set to 1, the value is doubled. It can range from 1 to 65,535 and has a default value of 3. |
| BroadcastTimeout | This parameter controls the time between Find-Name requests. It can range from 1 to 65,535 half-seconds and has a default value of 1 half-second. |
| ConnectionCount | This parameter specifies the number of times a connection request is to be attempted before declaring that the connection could not be established. If the Internet parameter is set to 1, this parameter value is doubled. It can range from 1 to 65,535 and has a default value of 5. |
| ConnectionTimeout | This parameter specifies the time between connection attempts when initiating a connection. It can range from 1 to 65,535 half-seconds and has a default value of 2 half-seconds (1 second). |
| InitialRetransmissionTime | Like SPX, NetBIOS dynamically adjusts the retransmission time interval used to resend a packet that has not been acknowledged. This parameter specifies the initial retransmission interval value. It can range from 1 to 65,535 ms and has a default value of 500 ms. |
| KeepAliveCount | When there is no activity on a NetBIOS connection, a keep-alive packet is sent to verify whether the connection is still valid. This parameter controls the number of times the keep-alive packet should be sent if no response occurs. It can range from 1 to 65,535 and has a default value of 8. |
| KeepAliveTimeout | When no activity occurs on a NetBIOS connection, a keep-alive packet is sent to verify whether the connection is still valid. This parameter controls the time that the node should wait before sending a probe to the remote node to verify that the NetBIOS connection is still valid. It can range from 1 to 65,535 half-seconds and has a default value of 60 half-seconds (30 seconds). |
| RetransmitMax | This controls the maximum number of times a sender should retransmit before assuming that there is a problem with the connection. It can range from 1 to 65,535 and has a default value of 8. |
Under the following key, you find parameters for each binding of the NWLink transport protocol to a network adapter (see Figure 46.37):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NWLnkIPX\NetConfig\ adapter_name
The Registry contains the Network Adapter parameters for each NWLink transport protocol.
Table 46.8 describes the adapter-binding parameters that can be used to configure the adapter bindings. The source routing parameters are for Token Ring network adapters.
| Parameter | Description |
| BindSap | This parameter specifies the Ethertype value for Ethernet_II frame. The Ethernet type is a 2-byte field that is part of an Ethernet_II frame, used to specify the type of data in the Ethernet frame. The Ethernet type field is defined for most well-known protocols and is documented in the RFC (Request for Comment) titled Assigned Numbers available on the Internet. The type of this parameter is REG_DWORD. It can range from 1,501 to 65,535 and has a default value of 8,137 (hex) for IPX packets. |
| EnableFuncaddr | When set to 1, this enables the use of the IPX functional address C00000800000 (hex) for Token Ring adapters. When set to 0, IPX functional address is disabled. It is up to an application to make use of the IPX functional address. The type of the parameter is REG_DWORD and is treated as a Boolean with a value of 0 or 1. The default value is 1. |
| MaxPktSize | Specifies maximum frame size for the network adapter. If set to 0, NWLink gets this information from the network adapter driver. The type of this parameter is REG_DWORD. It can range from 0 to 65,535 and has a default value of 0, which means that parameter value is read from the network adapter driver. |
| NetworkNumber | This is the network number of the network segment the adapter is connected to. IPX network numbers are 4 bytes (8 hex digits) long. If this parameter is set to 0, NWLink determines the network number from an IPX router on the network. In a NetWare-based network, all NetWare servers act as IPX routers. If you set a non-zero value, it must be compatible with the network number set for other IPX nodes such as NetWare servers that are on the same physical cable segment. You can set the network number from the Network icon in Control Panel. The type of this parameter is REG_MULTI_SZ. It can be an 8-digit hexadecimal number and has a default value of 0. |
| PktType | NWLink can run on a variety of different physical networks such as Ethernet, Token Ring, FDDI, ArcNET, and so on. This parameter specifies the frame type to use. The following frame types are used: Ethernet_II(0), Ethernet_802.3(1), 802.2(2), SNAP(3), ArcNET(4), Auto-detect (FF). The numbers in parentheses in the previously mentioned frame types are the values of the PktType that denote the frame type. Ethernet can have a PktType with values of 0 through 3. Token Ring and FDDI can have values 2 or 3. For ArcNET, you select a value of 4. If you have a Token Ring or FDDI network adapter, a value of 0 or 1 works the same as a value of 2. The type of this parameter is REG_MULTI_SZ. It can have a value of 0 to 4 and has a default value of 1 (802.3 frame). |
| SourceRouteBcast | This parameter specifies the source route to be used for broadcast MAC packets that have a destination address of FFFFFFFFFFFF. When set to 0, the packet is transmitted to the Single Route Broadcast(0xC2, 0x70). When set to a non-zero value, the packet is transmitted to the All Routes Broadcast(0x82, 0x70). The type of the parameter is REG_DWORD and is treated as a Boolean. The default value is 0. |
| SourceRouteDef | This parameter specifies the source route to be used for a packet with a destination address that is not in the source routing table. If the destination address is in the source routing table, the route in the table is used. When set to 0, the packet is transmitted to the Single Route Broadcast(0xC2, 0x70). When set to a non-zero value, the packet is transmitted to the All Routes Broadcast(0x82, 0x70). The type of the parameter is REG_DWORD and is treated as a Boolean. The default value is 0. |
| SourceRouteMcast | This parameter specifies the source route to be used for a packet with a multicast destination address (C000xxxxxxxx). When set to 0, the packet is transmitted to the Single Route Broadcast(0xC2, 0x70). When set to a non-zero value, the packet is transmitted to the All Routes Broadcast(0x82, 0x70). The type of the parameter is REG_DWORD and is treated as a Boolean. The default value is 0. |
| SourceRouting | This parameter specifies whether or not source routing is to be used. The parameter is valid only for Token Ring networks. If you do not have source routing bridges, you can disable this parameter and all the source routing logic. A value of 1 enables source routing, and a value of 0 disables source routing. The type of the parameter is REG_DWORD and is treated as a Boolean. The default value is 0. |
| DefaultAutoDetect | This specifies the frame type to be used if NWLink cannot detect any servers or network traffic on startup. If a new packet is subsequently detected, the default initial value for the frame type is overridden by the detected frame type. The following frame types are used: Ethernet_II(0), Ethernet_802.3(1), 802.2(2), SNAP(3), ArcNET(4). The numbers in parentheses in the previously mentioned frame types are the values of the default frame type. The type of the parameter is REG_DWORD and can have a value from 0 to 4. The default value is 2, which means that the default frame type is 802.2. |
| EnableWanRouter | When set to 1, the RIP router is enabled for the specified network adapter interface. The type of the parameter is REG_DWORD and is Boolean. The default value is 1. |
Windows NT Server provides a number of capabilities that enable the integration of Windows NT Server in a NetWare network. One of these capabilities is the Gateway Service for NetWare (GNSW) that runs on Windows NT servers and enables Microsoft network clients to access NetWare servers. The GSNW enables a single connection to the NetWare server to be shared by an unlimited number of clients. If Windows NT computers (workstations or servers) need direct access to NetWare servers, you can use either Microsoft's Client Service for NetWare or Novell's NetWare Client for Windows NT. Although Microsoft's client works well straight out of the box for most purposes, from a lower-layer networking perspective, Novell's client works much better. Unlike the Microsoft client, it dynamically adjusts its burst window size, it performs native NDS logons without making a bindery connection first, and it handles things such as non-local preferred servers at logon time much more efficiently. Also, if you plan on using the NetWare Administration tool made to run on NT, you must run Novell's client rather than the NT Gateway and Client for NetWare.
Novell's NetWare client service for Windows NT fully supports Novell's Directory Services and can be used to access a NetWare 4.x network. The NT client software can be downloaded from the NetWare OS Files forum on CompuServe (GO NWOSFILES) or Novell's Web Server at http://www.support.novell.com/. In addition to the client, a 32-bit version of NetWare 4.x's administration tool, NWAdmin, is available. This 32-bit version of the NetWare Administrator tool can be used to manage the NetWare's Directory Services tree from a Windows NT workstation or server.
The NetWare Client for Windows NT supports 32-bit applications for Windows NT and 16-bit MS Windows applications that make calls to the 16-bit NWCALLS library.
The NetWare client for Windows NT comes in two forms: One installs through the network, the other from floppy disk. The NTENU41D.EXE file is a self-extracting file that runs in DOS mode and requires 13 disks. The Ntenu41n.Exe file is for network-based installations. It extracts itself to a standard \I386 subdirectory hierarchy so that you can integrate it into your network installs easily. You can also run the network install locally so that you don't have to create all those disks.
To install and configure the NetWare client:
3. The first screen explains the terms and conditions, which you must accept to extract the files. It extracts the following files (disk version):
MAKEDISK.BAT REV.A README.TXT IMAGE
Directory of C:\NOVELL\IMAGE NWMKDISK.SCR NWMKDISK.EXE NWMKDISK.MSG NT1_ENU.350 NT2_ENU.350 NT3.350 NT4.350 NT5.350 NT6.350 NTAENU_1.350 NTA_2.350 NTAENU_3.350 NTAENU_4.350 NTA_5.350 NTA_6.350 NTA_7.350
5. After the files are ready, go to Control Panel, double-click the Network icon, and select the Services tab.
6. Click Add.
7. In the Select Network Service window, click Have Disk.
8. Type in the full path to the IntranetWare client in the Insert Disk window (see Figure 46.38).
Type in the location of the IntranetWare files.
10. Read the license agreement and click Yes if you're willing to accept the terms of the license.
11. If you don't already have the NWLink IPX/SPX protocol installed, the system prompts you to install it now.
12. Type the directory; the IPX/SPX-related components are installed. The Novell IntranetWare Client for Windows NT is listed under the Network Services tab once installed.
13. Click Close.
14. After the Bindings are updated, you're prompted to restart the computer.
15. Once you reboot, the Begin Login window should have the IntranetWare logo on it. After you press Ctrl+Alt+Delete, the IntranetWare Window appears, as in Figure 46.39.
Type in your logon information in the Begin Login screen with IntranetWare.
You can indicate a preferred Tree or Server on the Connection tab. If you're connecting to a Novell 3.x server, you want to specify a server and connect in Bindery emulation mode. If you're working with the NetWare 4.x/IntranetWare family, you can also (and might need to) select a preferred context (see Figure 46.40).
The Connection tab enables you to specify a preferred context or server.
The Variables tab enables you to set any of the NetWare-specific variables that
can be used to change the behavior of logon scripts that were written to use them.
After IntranetWare is installed, it is present in the Programs folder of the Start
menu.
17. You can initiate a shutdown procedure or lock the workstation from the IntranetWare security window by pressing Ctrl+Alt+Delete at any time while running Windows NT.
After The Novell Client32 is installed, you are able to see the files on the Novell server if you explore your Network Neighborhood (see Figure 46.41). If you're not currently logged on, clicking the tree in the Network Neighborhood brings up a logon window to log on to IntranetWare.
The Network Neighborhood shows files on the Novell server.
Connect to NetWare Directory Services print queue objects.
Installing the IntranetWare client for Windows NT does not prevent a user from participating in a Windows NT domain. Windows NT can be logged on to both NetWare and a Microsoft domain at the same time, and the MUP ensures that the correct redirector handles each network transaction. When connecting to both a Microsoft domain and a NetWare resource, Windows NT automatically offers the non-primary connection the same logon credentials that it used to connect to its primary logon.
After the NetWare client for Windows NT is installed, you can install and run the NetWare Administrator tool. The NetWare Administrator is a graphical, Windows-based utility that enables you to administer almost all aspects of a NetWare 4.x/IntranetWare network. You must have the Novell Client for Windows NT installed to run the NetWare Administrator tool. It will not run with the Microsoft NT Gateway and Client for NT because of NDS compatibility issues.
If you won't be administering any parts of the NetWare network, you might still want to have the NetWare Administrator installed so that you can use it to change your password on the NetWare server when you change your Windows NT password. To install the NetWare Administrator for Windows NT:
| AIO.OVL | MUSCRL32.DLL | NWRCON.PIF |
| APPSNPNT.DLL | NDSMGRNT.EXE | NWRCONNT.DLL |
| AUDITNT.DLL | NDSRNT.DLL | NWVCTLNT.DLL |
| BIDS45F.DLL | NLS | NWVIS0NT.DLL |
| BWCC32.DLL | NMDLGSNT.DLL | NWVIS1NT.DLL |
| CMPQ_AIO.OVL | NMGRNT.DLL | NWVIS2NT.DLL |
| CMPQ_RUN.OVL | NMSNAPNT.DLL | NWVPSNT.DLL |
| CW3215.DLL | NRDDLLNT.DLL | NWVPTNT.DLL |
| DSMGSNNT.DLL | NUDBNT.DLL | NWVQUENT.DLL |
| HDECSNNT.DLL | NUOWLNT.DLL | OWL252F.DLL |
| HHLPSNNT.DLL | NWADMNNT.EXE | QCBR70US.DLL |
| HMEDSNNT.DLL | NWAPP32.DLL | RCONSOLE.EXE |
| HNCPSNT.DLL | NWBRWSNT.DLL | RDLGSNT.DLL |
| HOBJSNNT.DLL | NWCDSNT.DLL | REGEDTNT.DLL |
| IBM_AIO.OVL | NWCOMNNT.DLL | RUN.OVL |
| IBM_RUN.OVL | NWCORENT.DLL | SH30W32.DLL |
| ISREG16.DLL | NWCTRLNT.DLL | SNAPIN32.DLL |
| MIGENG3X.DLL | NWMOD0NT.DLL | TEXTUTIL.IDX |
| MIGSNPNT.DLL | NWMOD1NT.DLL | |
| MIGWIN3X.EXE | NWMUDNT.DLL |
3. After extracting its files, the Setup program begins; click Next.
4. The setup wizard prompts you for a destination directory. The default directory is Z:\PUBLIC\WINNT. Click Next, and the Setup program begins installing the files to the destination you specified. If you have problems installing to a network drive, make sure that you're logged on with sufficient rights to create files and write to the destination directory.
5. After setup is done, click Finish to complete the installation.
6. To run the NetWare Administrator for the first time, go to your installation directory and run NWADMNNT.EXE from Explorer, from a command prompt, or from the Run command on the Start Menu. For future use, you might want to put a shortcut on your desktop.
7. The first time it is run, you will probably get a message about the NDS schema on one or more of your network's trees not being up-to-date. Schema is a name used to describe the tables, columns, and relationships in a database. The NDS schema is extensible, meaning that programmers can modify it as new features are needed, and that's what this application does here. If you are responsible for administering the NDS tree, go ahead and click Modify. You will receive a message saying that the schema has been updated. Otherwise, contact your NetWare administrator and request that he or she update the NDS tree.
8. When you continue, the NetWare Administrator launches (see Figure 46.43). You're able to perform all NetWare-related maintenance from Windows NT.
The NetWare Administrator enables you to do Novell administration from Windows NT.
Windows NT Server comes with a migration tool for NetWare called--unimaginatively enough--the Migration Tool for NetWare. It's in the Administrative Tools folder and points to the file NWCONV.EXE.
You can use the Migration Tool for NetWare to copy NetWare account information into equivalent accounts on a Windows NT Server. Because the two systems are quite different, no exact translation of NetWare to Windows NT Server accounts exists, and in spite of the claims made by documentation, my experience shows that some manual configuration is usually still required. In cases in which there would be considerable manual configuration after running the migration tool, it might be better to build the Windows NT Server user accounts from scratch without using the migration tool.
Figure 46.44 shows how the migration procedure works for transferring NetWare account information to a Windows NT Server in a single Windows NT domain. First, users and group accounts are transferred to the Windows NT Server acting as the domain controller. If backup domain controllers exist, the transferred user account information is automatically replicated to the backup domain controllers. Next, the directories and files on the NetWare server are transferred to a selected Windows NT Server.
NetWare account information migrates to a single Windows NT domain network.
Figure 46.45 shows how the migration procedure can be used for transferring NetWare account information to a Windows NT Server that is part of a master domain model. First, user and group accounts are transferred to the master domain. If backup domain controllers exist, the transferred user and account information is automatically replicated to the backup domain controllers in the master domain. Next, the directories and files on the NetWare server are transferred to a selected Windows NT Server in a resource or trusting domain.
NetWare account information migrates to a master domain network.
The migration tool can be run on the Windows NT Server to which you are migrating or another Windows NT Server. The target Windows NT Server (the server to migrate to) must have the following:
Before running the migration tool on a NetWare 3.x server, you should make sure that everyone is logged off the server and then run the NetWare utility BINDFIX on the NetWare server. This utility verifies the internal consistency of the account database--or in Novell's terms, the bindery--on that NetWare server and performs any necessary repairs to it. You don't need to do this on a NetWare 4.x server because it doesn't have a bindery, though you might want to run a DSREPAIR from the server console if you suspect any problems. Next, although it sounds obvious, also make sure that a good network path (LAN, WAN, and so on) exists between the NetWare server from which you are migrating and the Windows NT Server to which you are migrating. It's also good practice to make a full backup of the systems just before you make any major changes. To migrate NetWare 3.x or 4.x information to a Windows NT Server:
2. Run the migration tool program. You can run this from the command line or double-click the NWCONV icon in the Administrative Tools folder.
3. If this is the first time you're running the migration tool since performing a migration, you see the Select Servers for Migration dialog box. Use this dialog box to select the source and target servers. The source server is the NetWare 3.x or 4.x server, and the target server is a Windows NT Server. Select the Browse buttons to see the dialog box for adding NetWare and Windows NT Servers.
4. After you've selected the source and target servers, you see the main Migration Tool for NetWare screen (see Figure 46.46).
The Migration Tool for NetWare dialog box displays the source and target servers.
NOTE: You can select more than one NetWare server to migrate or more than one Windows NT Server to accept accounts and data. You can, for example, decide to copy user accounts on a single NetWare server to multiple Windows NT Servers in different domains or combine user accounts from several NetWare servers to a single Windows NT Server.
To select a NetWare server to migrate, you must be logged on as a supervisor-equivalent user to the NetWare server. When you log on locally to the Windows NT Server that has a GSNW running, it automatically attempts to log you on to the NetWare server by using the user account/password combination you used to log on locally to the Windows NT Server. If these don't match your NetWare account, Windows NT prompts you to enter your correct NetWare credentials. To transfer data to a Windows NT Server, you must be logged on as a member of the Windows NT Administrators group.
You can set the migration options individually for each pair of servers. The migration options set for the current pair of servers apply to the next pair that you add.
Use the User and Group Options dialog box to configure how accounts are transferred.
The Use Mappings in File option enables you to specify the user and group accounts that are transferred in a text file. This option gives you more flexibility because it enables you to edit this text file. To use this option, you must first create the mapping file. This process is described in the next section.
You can select how passwords, usernames, group names, and certain other default options are affected during the migration procedure by selecting the appropriate index tab.
6. Select the Password tab to see the password options. The Password tab is displayed by default when you first open the User and Group Options dialog box.
For user accounts transferred to the Windows NT Server, you can set passwords to any of the following: No Password, Password is Username, or Password is: (for the latter, you select a specific password for all users). By default, the User Must Change Password option is checked, meaning that users who log on to the Windows NT Server after the migration are forced to change their passwords.
If you want to specify an individual password for each transferred user account, you can create a mapping file and edit it to specify the individual passwords. You must then set the Use Mappings in File option and specify the mapping file name.
CAUTION: For security reasons, NetWare user account passwords are not preserved because there's no way to decode the password for an account or directly transfer the encrypted password in a way that Windows NT would understand. In fact, there isn't even a software function call in the NetWare API for reading the encrypted password!
To deal with possible duplications in usernames, select the Usernames tab in the User and Group dialog box.
If Ignore is selected, then conflicting usernames are not transferred to the Windows NT Server but also are not written to the error log file; that is, they're ignored.
If Overwrite With New Info is selected, then on conflicting usernames, the existing account on the Windows NT Server is written with the new information. Such conflicts are also written to the ERROR.LOG file. You can inspect this error log file to manually resolve the username conflicts.
If Add Prefix is selected, then on conflicting usernames, the new account is created by adding the specified prefix to the username created on the Windows NT Server. Username conflicts also are written to the ERROR.LOG file. You can inspect this error log file to manually resolve the username conflicts. You must keep the prefix short enough so that the overall username does not exceed the Windows NT Server limit of 20 characters. Usernames can contain uppercase and lowercase characters except:
8. Select the Groupnames tab to configure how duplicate group name conflicts are resolved (see Figure 46.49). Duplicate names conflicts result when the NetWare group account name already exists on the Windows NT Server or domain, and they can cause problems in your migration if you don't pay attention to how they're handled.
If Log Error is selected, then conflicting group names are not transferred to the Windows NT Server but are written to the ERROR.LOG file. You can inspect this error log file to manually resolve the group name conflicts. If you are transferring group accounts from several NetWare servers that have duplicate names, you might want to select this option.
To deal with possible duplications in group names, select the Group Names tab in the User and Group dialog box.
If Add Prefix is selected, then on conflicting group names the new group account is created by adding the specified prefix to the group name created on the Windows NT Server. Group name conflicts also are written to the ERROR.LOG file. You can inspect this file to manually resolve the group name conflicts. You must keep the prefix short enough so that the overall group name does not exceed the Windows NT Server limit of 20 characters. Group names can contain uppercase and lowercase characters except:
9. Select the Defaults tab to configure how account restrictions are transferred (see Figure 46.50). If you set this incorrectly, you might lose the account restrictions on everyone you migrate over or might accidentally add more restrictions than you want.
The Defaults tab in the User and Group dialog box determines how and if account restrictions are transferred.
If Add Supervisors to Administrators Group is set (it's not set by default), NetWare supervisor-equivalent user accounts that are transferred are added to the Administrators group on the Windows NT Server. These users then have full administrative powers on Windows NT Server. If this option is cleared, NetWare supervisor-equivalent user accounts are not added to the Administrators group on the Windows NT Server. You can manually give administrator privileges to the transferred NetWare user accounts by using User Manager for Domains.
10. To transfer NetWare accounts to a Windows NT network organized using the master domain, you can transfer NetWare accounts to the domain controller for the master domain by selecting the Advanced button. You should see a new option to Transfer Users to Trusted Domains. Select Master Domain from the list next to this option name.
11. Choose File Options to control the files copied from the NetWare server to the Windows NT Server (see Figure 46.51). By default, all server files are copied to the Windows NT Server except the following:
You can select which types of files will be copied by using the File Options button on the migration tool.
12. Suppose that you want to selectively transfer only certain files on a NetWare volume. If so, you can choose Files to reach the Files To Transfer Dialog box (see Figure 46.52). The directory structure of the volume is displayed in the left pane, and the files in the directory are shown in the right pane. Next to the directory and file names are check boxes that indicate whether the directory or file is to be transferred. If the check box is marked, the corresponding file or directory is transferred; if it is cleared, the file or directory is not transferred.
Select which files to transfer.
14. To specify a different destination directory on the Windows NT Server where files are to be transferred, choose Modify on the File Options screen to reach the Modify Destination dialog box (see Figure 46.53). To transfer to a different destination, choose New Share and specify the new share name and the UNC path to the Windows NT Server directory. To change the path of new share, choose Properties. To transfer files to a subdirectory under the shared directory, enter the subdirectory name in the Subdirectory field.
Specify a different destination in the Modify Destination dialog box.
To make a trial run, select Trial Migration from the Migration Tool for NetWare screen. You should see the Verifying Information dialog box that shows status of information being verified. At the end, you see a Transfer Completed screen. Select View Log Files to examine the log files. You see a window for each log file. Figures 46.54, 46.55, and 46.56 show sample log files produced by a trial migration run. Some of the errors in the ERROR.LOG file are caused by duplicate usernames and the fact that the NetWare BINDFIX utility was not run prior to the trial migration run. Other errors are from the migration tool itself.
This is a sample LOGFILE.LOG that shows the details of a trial migration run.
This is a sample SUMMARY.LOG for a trial migration run.
Viewing ERROR.LOG for a trial migration run can show you what problems you need to resolve before running the real migration.
17. Choose Exit to exit the migration tool.
18. Use User Manager for Domains to examine the properties of the transferred accounts. Also examine the permission settings on the files to see whether they were transferred as expected to the Windows NT Server.
You can use the User and Group Options dialog box to create a mapping file that specifies how account information is transferred from the NetWare server to the Windows NT Server. To create the initial mapping files:
2. In the Servers for Migration list, select the NetWare server whose accounts you want to map.
3. Choose User Options.
4. Set the Use Mappings In File option in the User and Group Options dialog box and enter the name of file in which the account mappings are created.
5. Optionally, set any account transfer options, as described in the previous section.
6. Choose OK.
The migration tool creates the specified text file that contains the user and group account information that are transferred. When prompted whether you want to edit this file, answer Yes.
Figure 46.57 shows the edit screen that appears. You can edit the user and password information in this file. The mapping file contains sections for each user and group name in the following form:
NetWareUserName, NewName = Windows NT name, Password = newpassword Consider the following entry in the mapping file for NetWare user Bill:BILL, BILL, password
The previous entries mean that the new account on the Windows NT Server is BILL with no passwords set. If you edit the mapping file to make the following changes:
BILL, BILLG, saddle
then, the NetWare user account BILL is transferred as Windows NT Server user account BILLG with an initial password set to saddle. When assigning passwords, remember that Windows NT passwords are limited to 14 characters and are case-sensitive.
This is an example of a user mapping file.
Many attributes of user accounts between NetWare 3.x and Windows NT Server are common. The accounts have a username, password, group membership, and home directories, for example. One of the major differences between the NetWare and Windows NT servers concerns account restrictions.
In NetWare 4.x, default account restrictions are set using the USER_Template in each context. In NetWare 3.x, default account restrictions are set by using the Supervisor Options in the SYSCON tool. When a new NetWare account is created, the default account restrictions are copied to the individual account. You can individually customize the account restrictions per user account. In Windows NT, some account restrictions can be set individually on a per-user basis, whereas other account restrictions must be set globally for all user accounts through the user account policy.
Table 46.9 summarizes the NetWare account restrictions, their Windows NT equivalents, and how these accounts are transferred.
| NetWare Account Restriction | Windows NT Account Restriction | How Account Is Transferred |
| Expiration date | Expiration date | Per individual user account |
| Account disabled | Account disabled | Per individual user account |
| Limit concurrent connections | None | Not transferred |
| Require password | Permit blank password | User policy for all accounts |
| Minimum password length | Minimum password accounts | User policy for all length |
| Force periodic password changes | Password never expires | Per user account |
| Days between forced changes | User policy for all accounts | Maximum password age |
| Grace logins | None | Not transferred |
| Allow user to change passwords | User cannot change passwords | Per individual user account |
| Require unique passwords | Password uniqueness | User policy for all accounts |
| Station restrictions | None | Not transferred |
| Time restrictions | Logon hours | Not transferred |
| Intruder Detection/Lockout | Account Lockout | User policy for all accounts |
| User disk volume restriction | None | Not transferred |
In addition to the Gateway and Client Services for NetWare discussed previously, Microsoft has a separate product, Services for NetWare, which includes two tools for further integrating the NetWare and NT networks. Directory Services Manager for NetWare (DSMN) and File and Print Services for NetWare (FPNW). These services are designed to work with NetWare 2.x, 3.x, and NetWare 4.x networks (running in bindery emulation mode). They can help network administrators by centralizing the routine administrative tasks related to user management, and they simplify the network for users by creating what appears to be one network because user account and password information is always consistent. Microsoft Services for NetWare is available as a separately purchased item through Microsoft BackOffice resellers, and it comes in a CD-ROM format.
Directory Service Manager for NetWare (DSMN) provides centralized management of NetWare networks by using Windows NT management tools. DSMN is most likely to be an appropriate solution for your network if your site contains many more Windows NT servers than NetWare servers. This is pretty common in networks transitioning from one type of network to another. After DSMN is installed, you cannot use the traditional tools on NetWare to manage NetWare servers and have the changes remain in sync with the Windows NT side of the network, so this tool is definitely for organizations moving away from NetWare. Figure 46.58 illustrates the DSMN approach, where the Windows NT Server contains the accounts database for NetWare servers. Modifications to the accounts are performed on the Windows NT Server, and these modifications are sent to the NetWare servers through a Remote Procedure Call. This tool makes it easier for a single person to administer both the NT domain, as well as the NetWare components of the network.
Directory Service Manager for NetWare manages NetWare servers from Windows NT.
The Windows NT Server running the DSMN software must be a primary domain controller that has the Gateway Service for NetWare installed and running. DSMN enables a trial synchronization of the user accounts. Also, it provides access for management via dial-up or from an NT or Windows 95 workstation. Because usernames are the same for both NT and NetWare, there is only one logon account, and if a user changes his password through Windows NT, the change automatically propagates to the NetWare account so that pass-through authentication can take place. There are a few things to keep in mind, though:
The approach DSMN takes is conceptually similar to that taken by Novell with its NetSync product. NetSync is included with NetWare 4.x servers and can be installed on NetWare 3.x servers so that updates to the centralized database of accounts on a NetWare 4.x server are propagated to the otherwise non-centralized accounts on all NetWare 3.x servers. The NetWare 3.x accounts are pulled into Novell Directory Services, and both the servers and accounts can be managed through the central NDS database. The NetSync approach is illustrated in Figure 46.59. If you compare Figures 46.58 and 46.59, you notice that the major difference is that the central server is Windows NT Server in one case and a NetWare 4.x server in the other. The NetSync approach is more suitable if you have predominantly NetWare 3.x and NetWare 4.x servers, and your Windows NT servers aren't widely used. The NetSync approach does not address Windows NT user updates at all, so they would still have to be done separately. If the NetSync approach is used, the NetWare 3.x servers are managed as if they were part of a NetWare 4.x NDS domain. If the DSMN approach is used, the NetWare 3.x servers are managed as if they were part of a Windows NT domain.
NetSync is used for managing NetWare servers.
Installing DSMN. DSMN is designed to synchronize the user account database (the bindery) on NetWare 3.1x servers with the user account database in a Windows NT domain. DSMN can also work with NetWare 4.x/IntranetWare servers that are running in bindery emulation mode. You control which Windows NT user accounts are synchronized, which gives you the flexibility to control easily who has access to both NT and NetWare.
The Server you install on must be a primary domain controller, and Gateway services for NetWare must be installed:
2. Click Add. From the Select Network Service dialog box, click Have Disk. Make sure the CD is in the CD-ROM drive, and type the path, D:\DSMN\NT40\i386, where D is the CD-ROM drive.
3. Select DSMN by highlighting it and pressing Enter. Type the password and confirm it.
4. You should install DSMN before installing FPNW if you plan on installing both services. If you have installed File and Print Services for NetWare already, the DSMN installation will warn you that it will not be able to propagate FPNW NetWare compatible accounts unless their passwords match the ones on the real NetWare servers.
5. After the files are copied, DSMN appears in the Network Services list. Click Close.
6. You're prompted to restart the computer for your changes to take effect.
Using DSMN. After you've installed DSMN, you need to configure it to know which NetWare servers it should treat as part of the Windows NT domain. You're able to import the existing NetWare account information into the Windows NT domain, as well as add existing Windows NT domain users to NetWare servers. To add Novell NetWare servers to an NT domain:
2. You must add each NetWare server to be managed with DSMN by using the Synchronization Manager (see Figure 46.60). To enable DSMN also to work with NetWare 4.x servers, add the following value to the Registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSYNC\Parameters:
Allow4x:REG_DWORD
Add a NetWare server to the DSMN Synchronization Manager to manage the NetWare server with DSMN.
4. If the logon is successful, the Propagation dialog box appears (see Figure 46.61) and prompts you for your options in moving the NetWare logon accounts over to your Windows NT domain. This is a little like running the migration tool, except that it continues to keep the account databases synchronized after you've moved the accounts. You have to make sure that all your account administration is done from Windows NT, however, for this to work.
Fill in the information in the Propagation dialog box to synchronize the databases.
6. Make sure that the results are what you expect before running the real propagation. The results are stored in the file mssync.log, in the %systemroot%\system32\SyncAgnt directory.
7. When you begin the real propagation by clicking OK, DSMN warns you that you should make sure that you've run Novell's BINDFIX.EXE on the server(s) you're about to add to the Windows NT domain. If you've already done that and you're ready to continue, click OK. The servers chug along for a little while, exchanging data.
8. Next, you need to tell DSMN which Windows NT domain accounts you want to add to the NetWare file server. You can select all accounts or specify which ones by the groups they belong to.
9. The Directory Service Manager can remove those NetWare users that were not propagated. Click Yes to delete them. If you want them to remain, click No; you must administer them with NetWare's administrative tools rather than Windows NT.
After you've propagated the NetWare information to the NT server, the Synchronization Manager continues to update the information regularly. After making many changes, however, you might want to force the updates to happen immediately. You might also want to force the updates to happen immediately if a server was offline when changes were made. Four options under the NetWare Server menu enable you to do this. You can synchronize a selected server or all the servers. Only select the Fully Synchronize option if the server is (or servers are) badly out of synchronization; otherwise, it's better to do a normal synchronization, which only involves sending changed information across the network.
One of the more important precautions you can take is to make regular backups of your synchronization database, so make sure that your tape backup routine includes backing up the synchronization database. Its files are stored in the directory %systemroot%\SYSTEM32\SYNCAGNT\BACKUP\NEW.
Another maintenance task involves periodically reorganizing the synchronization database and compacting it. Do this whenever you've made many changes to the user account database to clean it up and make it more efficient.
DSMN Commands. DSMN comes with some utilities that you should start using instead of the equivalent NetWare utilities. The easiest way to begin doing this is to rename the equivalent NetWare utilities to *.old, and then to rename each of these to its NetWare equivalent. These utilities are installed automatically in %systemroot%\system32\ syncagnt\dosutils, and you can copy them from there.
These are the DSMN Utilities for DOS:
The second component of Services for NetWare is File and Print Services for NetWare (FPNW). This makes the Windows NT Server look like a NetWare 2- and NetWare 3-compatible file and print server. FPNW does not emulate the behavior of a NetWare 4.x server, so an NT Server running FPNW will not participate in NetWare Directory Services.
Figure 46.62 shows the configuration in which FPNW would typically be used. The NetWare 3.x clients continue to access the Windows NT Server because they see it as a NetWare server instead of a Windows NT Server. Microsoft clients can access the Windows NT Server by using their native Microsoft Network client software. This is a great way to handle a network that is transitioning from NetWare to Windows NT because it lets you take your time updating the client workstation software while everyone still has complete access to all the same shared files. This avoids both the performance penalty of using the Gateway service and the administrative overhead of having to maintain a separate NetWare server.
File and Print Services for NetWare enable NetWare clients to use a Windows NT Server as if it were a NetWare server.
The Windows NT Server can be used to run Windows NT applications but cannot be used to run the installed base of NLMs.
An NT Server running FPNW appears to be a NetWare server to NetWare clients. The directories and most of the NetWare utilities are the same, such as Attach or Setpass. Of course, some of the server-specific utilities such as Rconsole won't work.
Installing FPNW. To install File and Print Services for NetWare, which enables your Windows NT Server to look like just another Novell NetWare server to the rest of your network, follow these steps:
2. Select the Services tab and click Add.
3. From the Select Network Service window, click Have Disk, and when prompted, type the path to the installation files. For example, if you have the installation CD mounted as drive D:, enter d:\fpnw\nt40\i386. Click OK.
4. Select File and Print Services for NetWare by highlighting it and clicking OK.
5. You're prompted to specify the directory below which the data placed in the emulated NetWare SYS: volume will appear. SYS: is a required volume on all NetWare servers, and you can place it wherever you want on the NT Server--but remember that it must be on an NTFS partition to work like a normal NetWare server does with respect to security. Trying to put it on a FAT partition will generate a warning message because it is generally a bad idea, but you can put it on one if you have to. On this screen, you also enter the NetWare server name that FPNW should use (which must be different from the Windows NT name for the server), as well as the NetWare password for the Supervisor account. The Supervisor account is a privileged account in NetWare 3.x, similar to the default Administrator account in Windows NT.
6. Type the password for the Supervisor's account; make sure that this password conforms to the eight-character length limitation in NT. Type the password in the confirm box also.
7. The lower section of the dialog box enables you to set the tuning for the server. How you're using your server will determine your selection here. If you're using this server primarily as an access point for NetWare, Maximizing the File and Print Services Performance will provide faster access.
8. The last option on this screen is related to the system's performance settings. Your choices are basically whether the FPNW service will try to run really fast (which takes more memory), whether it will try to use as little memory as possible (which will be slower), or whether you want it to try and balance these two objectives. In general, if your server is dedicated to file and print sharing, you should try to maximize performance for that. If your system is used primarily as an application server for client/server-based applications, you will probably be better off to minimize memory use so that the applications (like SQL Server) can perform better. For lightly used servers, you can choose to balance between memory usage and performance because it's not likely to create a resource conflict.
9. If the server onto which you're installing FPNW is part of a Windows NT domain, you're prompted to enter a password for the FPNW Service's user account. This is a password the service will use when starting up. The only tricky thing to remember is that the password needs to be the same on all the FPNW servers you install it onto within that domain (see Figure 46.63).
Enter the same password for all FPNW servers within a domain.
11. Click the Close button. The network bindings are reviewed and updated if necessary. When finished, click OK.
12. You're prompted to shut down the computer for the changes to take effect. After you restart the computer, an FPNW icon appears in Control Panel.
Installing the File and Print Services for NetWare Administrative Tools on Another NT Computer. If you want to administer FPNW from another Windows NT-based system, you need to install the File and Print Services for NetWare Administrative Tools. These are the tools that enable you to control the FPNW that is running on another NT Server. They include an updated User Manager for Domains, an updated Print Manager, and an updated Server Manager to support the FPNW-specific options.
2. Click Add, and from the Select Network Service dialog box, click Have Disk. It's important not to select the option from the available list even if it does show up there. If it's already in the list, it refers to an older version that will not work correctly with NT 4.0.
3. When prompted for the path, type in the location of the installation files. Here we used D:\FPNW\NT40\i386. Click OK.
4. Select File and Print Services for NetWare Administrative Tools by highlighting it and clicking OK.
5. The installation copies files; when it's finished, click the Close button.
6. The bindings update, and you're prompted to restart the computer for the changes to take effect.
7. The FPNW icon in Control Panel can now access FPNW on whichever servers it's installed on within the domain, and you can add User Manager for Domains and Server Manager to your system's Administrative Tools menu to run, as needed. The filenames, respectively, are USRMGR.EXE and SRVMGR.EXE.
Configuring and Using File and Print Services for NetWare. FPNW will generally appear exactly like a NetWare server to your users, but you need to know a few things about how to administer it. If you're also running DSNM and you want to specify which user accounts have permission to log on from NetWare clients and propagate that information out to synchronized NetWare servers, you should run the updated User Manager for Domains and click the Maintain NetWare Compatible Login check box. After that is checked, you can select the NW Compat button to control the FPNW logon options for that user, such as how many logons to FPNW they can have at the same time, whether their password has expired, how many grace logons they get, and what their personal logon script will do (if anything) (see Figure 46.64).
The extended version of User Manager for Domains includes information for FPNW logons.
Installing the FPNW administration tools adds support for NetWare compatible print servers to the Ports tab of your printer worksheets. This allows you to direct print jobs from NetWare clients to NetWare compatible print queues on the FPNW server. These printers will appear to the Print Manager as NetWareCompatiblePServerX, where X is the number of the print device's port (see Figure 46.65).
The extended Server Manager is also installed as part of the FPNW tools. It adds an FPNW menu item along the top of the Server Manager window.
From the FPNW menu on Server manager, you can select Properties, Shared Volumes, Print Servers, and Send Message. The Properties button gives you the same dialog box that you get when you run FPNW from Control Panel.
Selecting Shared Volumes gives you a window from which you can create and delete FPNW volumes, as well as set limits on the number of concurrent users for each volume, and set the default permissions on each volume (see Figure 46.66). The default for FPNW volumes is for users to have full control of everything on the volume. This is different from in NetWare, in which the default is for users to have no access unless otherwise granted, so be sure to take this into account as you plan your FPNW installation.
The extended Print Manager enables you to configure printers to use FPNW queues.
The Shared Volumes option on the FPNW menu of Server Manager enables you to configure your FPNW volumes.
The Print Servers option from the FPNW menu of Server Manager replaces the NetWare PCONSOLE utility. From it, you can add print servers (usually one is enough to support several printers), printers (which connect to network print queues), and select which file servers are serviced by which print servers:
Use the File and Print Services for NetWare dialog box to configure FPNW.
3. In the bottom portion of the dialog box, however, you can do some useful things. You can edit the name the FPNW server uses on the network.
4. You can add a description (in case you have so many that you have difficulty remembering which one is which).
5. You can set the home directory path, which is where new users' home directories will be created. I usually use a SYS:USERS directory so that the server is a little more organized than the default--the default is to add each user's home directory at the root of the SYS: volume. Note that FPNW does not support placing users' home directories on volumes other than SYS:, and this is different from NetWare where SYS: is commonly configured to hold only system files and queued print jobs.
6. You can set a default queue for users who are printing to the NetWare server. This is like the SPOOL console command in NetWare, with which you can set a default print queue for users by entering SPOOL 0 TO QUEUE <queuename>. Many NetWare administrators don't set this because they prefer people to specify which printer they'll be using, instead of defaulting everyone to the same printer.
7. The Allow New Users to Login check box is used to prevent additional users from logging on. You should typically use this when you're getting ready to perform server maintenance so that you won't have people connecting just before you start making changes that will interrupt their work.
8. The Respond to Get Nearest File Server Requests check box should be used if you want users to connect to the FPNW server directly. When a NetWare bindery client initializes, it sends a Get Nearest File Server request and connects to the server it receives the first response from. You will want to uncheck this box if you put the FPNW server on a network before all the user accounts are created on it because otherwise you'll have users accidentally connecting to it and wondering why they cannot log on.
9. Click the Users button to display a list of connected users and the resources they are connected to. If a resource appears more than once, that means that the user has more than one connection to it.
10. Click Send Message. From here you can send a message to a user, a group of users you select, or to all users on the FPNW server. You might want to send to all users when you have scheduled server maintenance and you want to make sure that everyone knows to log off before you begin (see Figure 46.68).
File and Print services has an option for you to send a message to all users or to a specific user.
11. The Disconnect and the Disconnect All buttons do essentially the same thing except that the Disconnect option only affects the selected user, whereas Disconnect All affects all users. These buttons immediately disconnect a user from whatever FPNW resources he is connected to. It's much better if you can just ask people to log off because files they had open can be corrupted if you forcibly disconnect them.
12. The Volumes button lets you disconnect either all or selected users from the highlighted volume. This is different from using the User button to disconnect because the Volumes disconnection only affects connections to a specific volume, whereas a user disconnection affects all that user's connections (see Figure 46.69).
You can check Volume usage by clicking the Volumes button.
Use the Files button to see who has which files open.
© Copyright, Macmillan Computer Publishing. All rights reserved.