Migrating to Netware 4.1

- 9 -

Setting Up NetSync for Bindery Emulation

Bindery Objects and Bindery Context in NetWare 4
Issues Pertaining to Bindery Services
The NetSync Cluster
Understanding Bindery Synchronization
Understanding NetSync Synchronization Problems
The Effect of Unloading NetSync
Understanding Super-Clusters
Understanding the NetSync Modules
Preparing for Installing NetSync
NetWare Name Service (NNS)
Installing NetSync
Installing NetSync on NetWare 3 from Disk
NetSync Maintenance
Observing the Effects of Super-Bindery Synchronization
Creating Home Directories for Synchronized Users
Creating NDS Objects for NetWare 3 and NetWare 2.x Servers
Synchronizing Printing Functions Using NetSync
Using NetWare 4 Print Databases
Synchronizing Print Servers

If your migration plan calls for some of your servers to remain on NetWare 3, you will need a means of integrating those NetWare 3 servers into the NetWare 4 NDS environment. Novell has a set of NLMs described by the general name of NetSync that enables many of the NetWare 3 server administration tasks to be performed from NDS using NetWare 4 tools such as NetWare Administrator and NETADMIN.

NetSync allows the management of NetWare 3 servers through the NDS. Because NDS is supported on NetWare 4 servers, you must have at least one NetWare 4 server. Under NetSync, NetWare 3 management tasks, such as user and group account creation, can be performed using the NetWare 4 tools NETADMIN or NWADMIN (NetWare Administrator). NetSync consists of the NETSYNC3, REMAPID, and NETSYNC4 NLMs that run on NetWare 3 and NetWare 4 servers, respectively. These NLMs permit the NetWare 3 user and group accounts to be synchronized using their bindery object representations on a NetWare 4 server.

You should use NetSync for the following reasons:

You want to make existing NetWare 3 users, groups, and print queues part of the NetWare 4 NDS without upgrading all NetWare 3 servers to NetWare 4.
You are running NetWare Name Services (NNS) and do not want to upgrade all servers in the NNS domain to NetWare 4 simultaneously.
You want to implement a temporary solution for central administration of a mixed NetWare 3/4 network before full migration to NetWare 4.

You should not use NetSync under these circumstances:

You intend to migrate all NetWare 3 servers to NetWare 4 simultaneously or in a short period of time.
You have only NetWare 4 servers on your network. That is, you do not have NetWare 3 servers.
You do not want to make NetWare 3 user and group accounts part of the NDS tree.
You plan to do administration using SYSCON or intend to have separate Supervisor passwords for administering the NetWare 3 servers.

If you plan to manage your NetWare 3 servers under NetWare 4, you will probably want to install NetSync. This chapter shows you how to install NetSync to emulate the NetWare 3 bindery under NetWare 4. Before I show you how to install NetSync, I will describe what it is and what it does.

Bindery Objects and Bindery Context in NetWare 4

The NetWare 4 server has the capability to allow objects in any NDS container to be seen as their equivalent bindery object representations. This is called bindery emulation and it provides backwards compatibility with NetWare 3 servers. The container in which you set the server's bindery services is called the bindery context.

Users who log in to a NetWare server from a NetWare 3 client must have their user NDS object in one of the containers specified in the bindery context. If a NetWare 3 client tries to log in to a NetWare 4 server that does not have the bindery context set, they will receive a bindery locked error.

Bindery emulation, also called bindery services, creates a "flat" structure for the objects within an Organizatonal Unit or Organization container. The objects in these containers can be accessed by both NDS objects and by bindery-based clients and servers. Bindery services are applicable only to the leaves in the bindery context.

Starting with NetWare 4.1, the bindery context can be set to up to 16 containers using the SET BINDERY CONTEXT console command. The NDS objects in these containers that can be emulated to a NetWare 3 bindery object will be seen by bindery-based tools as a single bindery. In earlier versions of NetWare 4, the bindery context could be set to a single container only. This forced NetWare administrators to place all objects that were to be seen by bindery-based clients into a single container. When multiple containers are allowed in the bindery context, you have more flexibility in placing objects in containers and yet are able to view these objects as belonging to a single bindery.

By default the NetWare 4 server's bindery context is set to the container in which the NetWare 4 server object is created during the server installation. If objects and clients in other containers need access to bindery services, set the bindery context to include these containers.

NetSync depends on setting a bindery context for the NetWare 4 server, and this bindery context cannot be changed without affecting NetSync operation. The default bindery context set for NetWare 4 is the container where the server is installed. However, you can set the bindery context for NetSync to any context, including a context that does not contain a NetWare 4 server.

The following shows the general format of the SET BINDERY CONTEXT command:

SET BINDERY CONTEXT=NDS container {; NDS container}

This command can be issued from the server console, but it is generally placed in the AUTOEXEC.NCF file so that the bindery context is set whenever the server is started.

With bindery emulation, it is possible for workstation clients that use the older shell (NETX.EXE or NETX.COM) software to access the NetWare 4 server. The NetWare 4 server appears as a bindery-based NetWare 3 server, and the NDS objects in the containers in the bindery context will appear as bindery objects. Bindery emulation is also important for NLMs that have been written to access bindery files. An example of this is the earlier version of the Norton Antivirus NLM that requires that you log in as the bindery user SUPERVISOR when making configuration changes. Other applications that depend on bindery-based objects are the following:

UnixWare clients
Windows NT and OS/2 clients
DOS workstations logged in to an NDS tree and making an attachment
Host access via NetWare for SAA
Users using the MAP command to access a directory in another NDS tree

When specifying the bindery context containers, do not use a leading period in the container name. The server will generate an error message if you use a leading period. For example, the following is illegal:

SET BINDERY CONTEXT = .OU=CORP.O=ESL;.O=ESL

Instead of the previous command, use the following legal command, which does not have a leading period before the container name:

SET BINDERY CONTEXT = OU=CORP.O=ESL;O=ESL

Because the bindery context is changed through the SET command, it can also be set using the SERVMAN.NLM that allows any SET parameter to be changed.

Issues Pertaining to Bindery Services

In general, avoid having objects with the same name in containers in the bindery context. Consider two users Karen Smith and Kim Smith who are in the Corporate and Engineering departments of the organization Kinetics. Assume that the login name convention used in the organization is first name initial plus last name. Because these users are in different departments, they could both be assigned a login name of KSmith. For example, the user Karen Smith could be described by the User object CN=KSmith.OU=CORP.O=KINETICS and the user Kim Smith could be described by CN=KSmith.OU=ENG.O=KINETICS. There is no conflict when these users log in using NDS names because the two users are in different containers. What would happen if the bindery context for the NetWare server used by Karen and Kim is set as indicated below?

SET BINDERY CONTEXT = OU=CORP.O=KINETICS;OU=ENG.O=KINETICS

If user Kim Smith logs in from a bindery-based client with the login name KSmith, the container OU=CORP.O=KINETICS will be searched first for the bindery object KSmith. The KSmith user bindery object will be found in the container OU=CORP.O=KINETICS, and the user Kim will attempt to log in as KSmith. But the bindery object found is for user Karen Smith, and not user Kim Smith. User Kim will attempt to log in with her password thinking that she is being asked by the server to log in as herself. The server will reject the login if user Kim's password is different from user Karen. In the unlikely event that users Kim and Karen have the same password, user Kim will log in to user Karen's account, and will not find the files and directories she expects in her home directory. In either case, the situation is ripe for chaos.

NetWare 4 searches the containers specified in the bindery context in the order in which they are specified. If there is more than one object with the same common name (CN), only the object in the first bindery context is visible; the remaining bindery objects in other containers are hidden by the first occurrence of an object with the same name.

Because only the common name of the leaf object is seen by bindery clients and bindery-based services, this name must be compatible with bindery names. For example, if the leaf object in the bindery context has the complete name of .CN=JohnD.OU=CORP.O=ESL, the bindery-equivalent name will be JOHND. You should, therefore, use common names that comply with bindery-naming rules. For example, you should avoid using spaces in common names.

NetWare 3 clients can only use bindery-emulated leaf objects that they can understand. NDS objects and properties such as profile objects and profile properties are not available through bindery-based services. Login scripts that are defined in the NDS objects are not available for use through bindery-based services. If you want to have a bindery-based login to a NetWare 4 server, you must manage this through bindery-based system login script (kept in the SYS:PUBLIC\NET$LOG.DAT file) and user login scripts (kept in the SYS:MAIL directory).

NOTE: NDS objects and properties such as profile objects and profile properties are not available through bindery services.

The NetSync Cluster

A NetSync cluster consists of one NetWare 4 server and up to 12 attached NetWare 3 servers (see fig. 9.1). The NetWare 3 servers attach to the NetWare 4 server in the bindery emulation mode.

Whenever you update or create a user in the bindery context of the NetWare 4 server, that user is synchronized with all NetWare 3 servers in the NetSync cluster. If a new NDS user is created in the NetWare 4 bindery context, that user exists as a bindery user on all NetWare 3 servers that are part of the NetSync cluster and that are attached to the NetWare 4 server. Similarly, if a property of the user such as the user's last name is changed, that change is replicated to all the NetWare 3 servers in the NetSync cluster. A practical benefit of this is that you do not have to update or create the user on each NetWare 3 server.

The updated bindery on each NetWare server is a superset of all the individual binderies at each NetWare server and is therefore called the super-bindery. Any NetWare 3 user can access any other NetWare 3 server that is part of the same NetSync cluster.

Figure 9.1 A NetSync cluster.

NOTE: The super-bindery consists of the combined bindery and NDS users and group objects in the bindery context that is copied to all NetWare 3 servers that are part of the NetSync cluster.

After a NetSync cluster is created, you must make all user and group account changes using the NetWare 4 administrative utilities such as the NETADMIN or NWADMIN. Do not use SYSCON for these tasks because SYSCON does not have knowledge of the NetSync cluster. Changes made through SYSCON will result in the bindery objects on the servers being out of synchronization with each other. Synchronization in the NetSync cluster is achieved by the NETSYNC3.NLM that runs on each NetWare 3 server and the NETSYNC4.NLM that runs on the NetWare 4 server.

The NetWare 4 server acts as a repository for bindery objects that are copied from the NetWare 3 server into its bindery context. The NETSYNC4.NLM continuously monitors changes to objects in the NetWare 4 server's bindery context. Any changes made to the bindery objects in the NetWare 4 server's bindery context are downloaded to all the objects in the NetWare 3 servers in the NetSync cluster (see fig. 9.2).

If you do not want the NetWare 3 servers to be managed from a central NetWare 4 server, do not join the NetWare 3 server as part of the NetSync cluster. If, for example, you plan to have a separate network supervisor for each NetWare 3 server and manage users and group accounts separately with SYSCON, do not make the NetWare 3 server part of a NetSync cluster. Also, if you have only NetWare 4 servers on your network or intend to migrate all your NetWare 3 servers to NetWare 4 at the same time, there is no purpose in creating a NetSync cluster.

Figure 9.2 NetSync synchronization.

Understanding Bindery Synchronization

Synchronization of the binderies in the NetSync cluster takes place from the NetWare 4 server bindery context to the NetWare 3 binderies (refer to fig. 9.2). Changes are made to the objects in the NetWare 4 bindery context first and these are automatically copied as part of the bindery synchronization to the NetWare 3 binderies. These updates from the NetWare 4 bindery context to the NetWare 3 binderies are automatic and the NetWare 4 bindery context is monitored continuously for changes.

If a NetWare 3 server that is part of a NetSync cluster is down when an update is sent out by the NetWare 4 server, the NetWare 3 server's bindery will be out of synchronization. When the NetWare 3 server is brought online again, the NetWare 4 server detects this event and downloads its bindery context to the NetWare 3 server so that the NetWare 3 server's bindery is now synchronized.

Ordinarily, the only time a NetWare 3 server's bindery is copied to the NetWare 4 bindery context is when the NetWare 3 server is first made part of the NetSync cluster. If inadvertent changes are made using SYSCON to a user or group on a NetWare 3 server that is part of a NetSync cluster, these changes will not be copied to the other binderies in the NetSync cluster, and this will cause the bindery objects to be out of synchronization. In this case, an explicit copy must be made of the changed object on the NetWare 3 server to the NetWare 4 bindery context.

After a NetWare 3 server joins a NetSync cluster, you must make all changes to users, groups, and print services on the NetWare 3 servers using either NETADMIN or NetWare Administrator in the NetWare 4 server. Changes that are made using these utilities are automatically sent to all servers in the NetSync cluster. Remember that one of the benefits of joining a NetSync cluster is central administration of the NetWare 3 servers. If you do not want central administration and prefer to manage users and groups using SYSCON, you should not join the NetSync cluster.

SYSCON must still be used for managing accounting charge rates on each NetWare 3 server. This is because accounting charges represent service and disk block usage and are always for a specific server. Therefore, by definition, the account charges are local to a server, and it makes little sense to synchronize this information across the servers in the NetSync cluster.

NOTE: The NETSYNC NLMs should be run continuously. You should, therefore, place the LOAD NETSYNC4 and LOAD NETSYNC3 commands in the AUTOEXEC.NCF files of the NetWare 4 and NetWare 3 servers respectively.

Figures 9.3 and 9.4 illustrate bindery synchronization by showing the bindery objects on NetWare servers before and after the servers join a cluster.

Figure 9.3 Bindery objects before joining a NetSync cluster.

Figure 9.4 Bindery objects after joining a NetSync cluster.

Table 9.1 summarizes the items that are or are not synchronized by NetSync.

TABLE 9.1 NetSync and Items Processing of Items for Synchronization

Item	Synchronized Status	Description
Users	Yes	Bindery-based users are combined into the NetWare 4 server's bindery context.
User passwords	Yes	User passwords on bindery users are translated to the password property of the User object in the NDS. Passwords are the only pieces of information in NetSync that are synchronized in both directions. You can change passwords on any NetWare 3 or NetWare 4 server in the NetSync cluster. This change is propagated throughout the cluster. The reason for this is that if users have accounts on more than one server, they will typically maintain the same password on all servers. If you use NetWare 3 SETPASS or LOGIN to change passwords, the utilities will ask you if you want to synchronize password changes to all attached servers. Passwords are synchronized even if you answer "No" to this question.
User login scripts	Yes	Login scripts are transferred into the NDS as login script properties of the User object.
		NetSync synchronizes NetWare 3 user login scripts kept in the MAIL directory to the NDS login script property on the NetWare 4 server. Changes made to the NDS user's login script on the NetWare 4 server are synchronized to the login script files (in the MAIL directory) on all NetWare 3 servers. You also can specify that NetSync create a login script file in the user's MAIL directory on the NetWare 4 server. In this situation, the user login script will be synchronized in three places: the NDS login script property on the NetWare 4 server, the user's 3.x MAIL directory, and the user's 4.x MAIL directory. Keeping a synchronized login script in the MAIL directory on the NetWare 4 server allows NetWare 3 users to log in to the NetWare 3 server using bindery emulation and execute the same login script that is on the NetWare 3 server. If you have multiple NetWare 4 servers in the same bindery context and you want to keep the login script in SYS:SYSTEM\MAIL synchronized with the NDS login script on all the servers, you must run NETSYNC4 on each NetWare 4 server.
User GUEST	Yes	The user GUEST becomes an NDS User object.
Groups	Yes	All bindery-based groups become NDS groups.
Group EVERYONE	Yes	An NDS group EVERYONE is created. All users in the NetWare 4 server's bindery context are added to this group. Any file and directory rights assigned to group EVERYONE on a NetWare 3 server are synchronized (combined) and apply to all users in the NetSync cluster.
NetWare Name Service (NNS) Profiles	Yes	NetWare Name Service profile login scripts are common login scripts for a group of servers running NNS. These profile login scripts are converted to NDS profile objects.
Account Balances	Yes	Bindery-based user account balances become NDS properties of their respective user objects.
PRINTCON database	Yes	PRINTCON job configuration templates created on NetWare 3 servers become properties of NDS objects.
PRINTDEF database	Yes	The PRINTDEF database on the NetWare 3 server becomes the property of the container object that is in the NetWare 4 server bindery context.
User SUPERVISOR	No	The user SUPERVISOR remains as a separate object on each NetWare 3 server in the NetSync cluster. This is for security reasons, because the SUPERVISOR account is used to control critical functions and tasks on each NetWare 3 server.
Accounting	No	The accounting charge rates are server based. For this reason, accounting charges are not synchronized. Accounting charge rates apply to the server on which accounting has been installed and configured. For example, when a user uses disk blocks on a NetWare 3 server, the user's account balance is diminished on that 3.x server only, and not on the synchronized user definitions on other servers in the NetSync cluster. NetWare 3 accounting is managed through SYSCON, and NetWare 4 accounting is managed through NETADMIN or NetWare Administrator.
File System	No	File system rights continue to be server based. The file system trustee rights apply to individual files and directories on the server. Synchronizing them would lead to situations that would give excessive rights or rights to non-existent directories on servers. If you want users on a server to be assigned rights on other servers, you must perform this step manually.
Home Directories	No	Home directories are not synchronized, because they are specific to users on a file server. When a user is created in the NetWare 4 bindery context and synchronized with the NetWare 3 servers, NetSync does not create a home directory for that user on each NetWare 3.1x server. Also, when users are copied from the NetWare 3 server into the NetWare 4 bindery context, no home directories are created on the NetWare 4 server. If you need home directories on other than the original server, you must manually create them and grant appropriate trustee assignments.
Illegal characters	No	Any object names that include characters that are illegal in bindery names are not synchronized. The only legal characters in bindery names are letters A-Z, numbers 0-9, hyphens, and underscores. NDS object names, on the other hand, can be up to 64 characters long and allow a wider range of permissible characters.
System login scripts	No	System login scripts are not synchronized. These login scripts are specific to the server and should not be synchronized.

Understanding NetSync Synchronization Problems

If a NetWare 3 server is down, it will not receive the synchronization information sent by the NetWare 4 server. This will cause the NetWare 3 server to be out of synchronization with the NetSync cluster. When the NetWare 3 server is brought back up, the super-bindery on the NetWare 4 server is downloaded to the NetWare 3 server. This resynchronizes the NetWare 3 server.

In general, you should avoid deleting or renaming objects unless all servers in the NetSync cluster are online. If you delete or rename User or Group objects in the NetWare 4 bindery context while the NetWare 3 servers are down, these servers will be out of synchronization. When the downed NetWare 3 servers are brought online again, you must manually remove the objects that were deleted from the NetSync cluster. Otherwise, the deleted objects will be re-created if you manually uploaded the NetWare 3 bindery to the NetWare 4 host. Remember that if a new object is added to the super-bindery, it is synchronized to all the NetWare 3 servers in the cluster.

If the NetWare 4 host in the NetSync cluster goes down while the binderies of one or more NetWare 3 servers are being uploaded to the NetWare 4 server, you should restart the synchronization when the NetWare 4 server comes back up.

If a NetWare 3 or NetWare 4 server runs out of disk space while receiving bindery synchronization information, an error message is displayed on each server. You should add more disk space or make room for the bindery objects. You should then reload NETSYNC3.NLM or NETSYNC4.NLM.

The Effect of Unloading NetSync

If you unload NETSYNC4 from the NetWare 4 server, the NETSYNC3 NLMs on the NetWare 3 servers in the NetSync cluster are automatically unloaded. To reload NETSYNC3 on the NetWare 3 servers, you must first load NETSYNC4 on the NetWare 4 server and then load NETSYNC3.

The REMAPID.NLM used for password synchronization must always remain loaded on the NetWare 3 server. If you unload REMAPID, you must assign new passwords to all bindery users in the system.

Understanding Super-Clusters

If there are multiple NetWare 4 servers in the same bindery context, and they are all running NetSync, all NetWare 3 servers that are attached to these hosts are synchronized with the same super-bindery.

Consider the example in figure 9.5 that has three NetWare 4 servers in the same bindery context. If all three NetWare 4 servers are running NetSync, and each of them has 12 NetWare 3.1x servers attached, all 36 NetWare 3 servers will upload their binderies to the 4.x bindery context, and this super-bindery will then be downloaded to the 36 NetWare 3 servers. The NetWare 4 and NetWare 3 servers form a NetSync super-cluster.

There is no upper limit to the number of NetWare 4 servers in any bindery context, but as the number of NetWare 4 and NetWare 3 servers increases so will the processing overhead on the servers. The NetSync NLMs are CPU- and memory-intensive processes. As the size of the super-cluster increases there will be more objects that need to be synchronized, and this will increase the synchronization traffic.

Understanding the NetSync Modules

NetSync consists of three primary NLMs (see fig. 9.6):

NETSYNC4 that runs on NetWare 4 servers
NETSYNC3 that runs on NetWare 3 servers
REMAPID that runs on NetWare 3 servers and is used for password synchronization

Figure 9.5 Three NetWare servers in a bindery context.

Figure 9.6 NetSync NLMs.

These modules are discussed in further detail in this section.

The NETSYNC4.NLM runs on a NetWare 4 server and is used to control the NetSync cluster. You can use NETSYNC4 to authenticate NetWare 3 servers that are reachable through the network and copy necessary files to the 3.x servers. Once NetWare 3 servers are synchronized to the bindery on the NetWare 4 server, NETSYNC4 monitors the super-bindery for changes and downloads updated bindery information to all NetWare 3 servers in the NetSync cluster. For the NetSync cluster to work, the NETSYNC4 should run continuously. It is therefore best to place the following command in the NetWare 4 server's AUTOEXEC.NCF file:

LOAD NETSYNC4

The NETSYNC3.NLM runs on each NetWare 3 server that is part of the NetSync cluster. On joining the cluster, NETSYNC3 uploads the 3.x server's bindery information to the NetWare 4 server's bindery context. The NetWare 3 server then establishes a connection to the NetWare 4 server to receive updates to its bindery. In addition to synchronizing the server bindery, NETSYNC3 converts the 3.x PRINTDEF and PRINTCON databases to a NetWare 4 compatible database format, and it can move NetWare 3 print servers and their associated queues and printers to NetWare 4.

Both NETSYNC4 and NETSYNC3 log their activity in the SYS:SYSTEM\NETSYNC working directory on their respective servers under the filename NETSYNC.LOG. The log file is in ASCII format and contains the messages displayed by NETSYNC3 on the server console. These messages describe the occurrence of events such as uploads and downloads of bindery information. The SYS:ETC\NETSYNC directories are created as part of the NetSync installation. The default log file maximum size is 0.5 MB. If the NETSYNC.LOG file is not cleared before it reaches its maximum size, NetSync automatically closes this file and renames it to NETSYNC.OLD. A new NETSYNC.LOG is then created. You can have only two NETSYNC files, NETSYNC.LOG and NETSYNC.OLD, at any time; older NetSync log files are automatically deleted.

You should run NETSYNC3 continuously so that the NetWare 3 server can receive updates. But NETSYNC3 can only receive updates if NETSYNC4 has been loaded on the NetWare 4 server. You must, therefore, load NETSYNC4 first on the NetWare 4 server and then load NETSYNC3 on the NetWare 3 servers. You should add the following command to the NetWare 3 server's AUTOEXEC.NCF file:

LOAD NETSYNC3

The REMAPID.NLM is automatically loaded when NETSYNC3.NLM loads. REMAPID performs password synchronization for the bindery objects and should remain loaded even if the NETSYNC3 module is unloaded.

When you install NETSYNC3 on a NetWare 3 server, certain support NLMs are also installed. These support NLMs are CLIB, STREAMS, NWPSRV3X, NWSNUT, AFTER311, A3112, and PBURST. The latest versions of these NLMs replace older versions on all NetWare 3 servers in the NetSync cluster.

Preparing for Installing NetSync

Before you can install and configure NetSync, you must review the names of NDS objects in the bindery context and the NetWare 3 binderies to avoid name conflicts. Specifically, you must ensure that there are no duplicate NDS or bindery object names (with the exception of print queue and printer names) that refer to different objects on NetWare servers that are to be a part of the same NetSync cluster. If you have duplicate names, be aware that any existing NDS object name takes precedence over any bindery object with the same name.

Duplicate names arise because the binderies on NetWare 3 servers are separate. After synchronization, a super-bindery object that contains the objects in all binderies is created. Objects that have identical names will cause name collisions and unintended results.

The NetWare 3 utilities convert diacritic characters (such as umlaut, accents, cedilla, tilde, circumflex, and so forth) to uppercase. NetWare 4 does not perform such a conversion. As a result of this, you could end up with two usernames in the super-bindery--one containing the diacritic characters and the other name with the translated characters. NetSync tries to solve this problem by performing an approximate match of the two usernames and assuming that they refer to the same user. Novell recommends the following precautions to ensure consistent behavior of foreign language characters in usernames:

Use the same code page in the NetWare 4 server's LCONFIG.SYS file (done through INSTALL.NLM), and in each NetWare client's CONFIG.SYS file (done through the COUNTRY= statement)
Users using the NetWare 4 LOGIN and SETPASS utilities should use the following syntax:

LOGIN servername/username LOGIN username /b  SETPASS servername/username SETPASS username /b

If you are using the NetWare 4 LOGIN utility to log in to a NetWare 3 server, you must use the LOGIN /NS command. This is equivalent to the ATTACH command in NetWare 3. However, you should be aware that if you use the LOGIN /NS command, this attachment does not show up as a connection when viewed from NetWare 3 utilities unless you map a drive to the NetWare 3 server.

NetWare Name Service (NNS)

NNS does its own synchronization of user accounts in an NNS domain. This synchronization is incompatible with the NetSync synchronization. Therefore, you must migrate all NetWare 3 servers running NNS to NetSync at the same time. In fact, if you load NETSYNC3 on a NetWare 3 server that has NNS running, it is automatically deactivated and deinstalled. This is because NETSYNC3.NLM checks for the presence of NNS on the server and removes it from the server.

When NetSync is installed, NNS profiles are converted to NDS profile objects. The default profile property in NNS is converted to the profile property of the profile object in the NDS. This ensures that users who had default profiles in NNS still have them after converting from NNS to NetSync. Because the NetWare 3 LOGIN utility does not understand profile login scripts, the NetWare 4 LOGIN utility is copied to each NetWare 3 server during NetSync installation. This enables NetSync users to use profile login scripts even if they were not doing so with NNS. If you plan on using profile login scripts for NetWare 3 users, you must use NETADMIN or NetWare Administrator to change the profile login script on the NetWare 4 server. Remember that login scripts execute in the following order: first system login script specific to each 3.x server, then profile login script, and then user login script.

Installing NetSync

To install NetSync you must have at least one NetWare 4 server and up to twelve NetWare 3 servers per NetWare 4 server. You should also keep in mind the fact that NetSync is memory and CPU intensive on the NetWare 4 server, and CPU intensive on the NetWare 3 servers. Novell recommends that when NetSync is running, you should not let the cache buffer count drop below 200 or server utilization rise above 80 percent.

The NetWare 4 NetSync files are copied into SYS:SYSTEM directory during the NetWare 4 server installation. After installing NetSync on the NetWare 3 server, the NetSync files exist in the SYS:SYSTEM\NETSYNC directory on NetWare 3.

Before commencing the NetSync installation, you should perform the following tasks:

Scan objects in the bindery context and each NetWare 3 server that is to be part of the NetSync cluster to ensure that there are no unintended duplicate names.
Ensure that the bindery context on the NetWare 4 server is set to the proper containers.
You should not change the bindery context when NetSync is running.
Ensure that you have a valid user account and rights to the SYS:SYSTEM directory on all servers that are to be part of the NetSync cluster.

Use the following steps to install NetSync:

1. Load NETSYNC4 on the NetWare 4 server. Run the following command at the NetWare 4 server console:

LOAD NETSYNC4
NOTTE: NETSYNC4 autoloads the following NLMs: CLIB, STREAMS, NWPSRV, NWSNUT, and DSAPI.

NOTE: The SYS:SYSTEM\NETSYNC directory is automatically created during NetWare 4.1 server installation. This directory contains NetSync log files and NetWare 3 NetSync files.

2. When NETSYNC4 first loads, you should see a screen similar to figure 9.7 that informs you that you must authorize at least one NetWare 3 server before you can use NetSync.

Figure 9.7 NETSYNC4 initial screen.

3. Press Enter. You should see the Authorized 3.1x Servers menu (see fig. 9.8). You must authorize each NetWare 3 server that will be part of the NetSync cluster. The authorization enables a NetWare 3 server to attach to the NetWare 4 host.

Figure 9.8 The NETSYNC4 Authorized 3.1x Servers menu.

4. From the Authorized 3.1x Servers menu, highlight the number of the NetWare 3 server you want to authorize.

Press Enter or Ins. You should see the Authorized Server Information form (see fig. 9.9).

Figure 9.9 The NETSYNC4 Authorized Server Information form.

NetWare 3 servers in the NetSync cluster are numbered from 1 to 12. If this is the first time you are using NETSYNC4, the number 1 will be highlighted.

5. Use Authorized Server Information to add NetWare 3 servers to the cluster. The fields in this form have the following meanings:

3.1x File Server Name. This is the name of the NetWare 3.1x server whose bindery you want to synchronize with the NetWare 4 host.

NetSync Password. The NetSync password appears only when you authorize a NetWare 3.1x server. When you re-edit the server information, you will not see the password option. The NetSync password must not be confused with the user password or Admin password. You should avoid using privileged account passwords to prevent these passwords from being compromised. The NetSync password is used only for NetSync authorization purposes. It is used to initially authorize the NetWare 3.1x server, and on each NetWare 3 server to initially attach to the NetWare 4 server's NetSync cluster. Once the password is set, NetSync remembers it. You can specify a different NetSync password for each NetWare 3 server. But you must use the same password to authorize the NetWare 3 server to attach to the 4.x server. If you forget the password, you must remove the NetWare 3 server from the "Authorized 3.1x Servers" list and re-authorize it with a new password.

Install Files on 3.1x Server. To copy NetSync files to the NetWare 3 server, set this field to Yes. This option only appears when you initially authorize a NetWare 3 server. It is not seen when you re-edit the server in-formation. The default value is Yes, so that a newly authorized NetWare 3 server can have all the necessary NetSync files copied to it. The NetSync files are copied to the SYS:SYSTEM\NETSYNC directory on the NetWare 3 server.

Copy 3.1x Bindery to 4.x. This option enables you to upload bindery data from the NetWare 3 server to the NetWare 4 server. The initial default value is Yes, so that the NetWare 3 server can synchronize itself to the super-bindery. If you re-edit the server information, the default is No, because the NetWare 3 server is assumed to be synchronized. Answer No for the server authorization if you are running NNS and you have already copied the domain information to the NetWare 4 server when you authorized another NNS server. If you want to discard the authorized server's user and group bindery objects but still be part of the NetSync cluster, answer No.

After you enter the necessary information, press Esc and answer Yes to the question Is this information correct?.

6. You will be informed that a username that has Read, Write, Modify, and Erase rights to the SYS:SYSTEM directory on the NetWare 3 server is needed so that NetSync can copy the files to the NetWare 3 server's SYS:SYSTEM directory (see fig. 9.10).

Figure 9.10 A message about the rights needed by a user.

Press Enter to continue.

You can enter the SUPERVISOR names, or the names of any other users that have "RWE" rights.

7. You will be prompted for the user's password. Enter the user's password.

8. You will be asked if you want to include the command to load NetSync in the AUTOEXEC.NCF file of the NetWare 3 server. Answer Yes.

9. If the files copied successfully, you will see the message shown in figure 9.11, informing you that the NetSync files have successfully been copied to the NetWare 3 server.

Figure 9.11 Message indicating successful copy of NetSync files to a NetWare 3 server.

Press Enter to continue.

10. The name of the NetWare 3 server that was authorized will appear in the "Authorized 3.1x Servers" screen (see fig. 9.12).

Figure 9.12 Name of authorized NetWare 3 server displayed.

You might see any of the symbols *, @, or ! against a server name. The asterisk means that you are currently attached to this server. The at sign means the server is currently receiving downloaded bindery information from the NetWare 4 host. The exclamation point means that the server is currently uploading information to the NetWare 4 host.

Press Esc to return to the Options menu.

11. You can repeat steps 4 through 10 to authorize additional NetWare 3 servers to be part of this NetSync cluster.

12. After you have authorized at least one NetWare 3 server, you can access the Options menu. The Options menu will appear whenever you load NETSYNC4, as long as at least one NetWare 3 server has been authorized.

13. You must now load NETSYNC3 on each NetWare 3 server that is part of the NetSync cluster. Before doing this, ensure that NETSYNC4 is already loaded on the NetWare 4 server.

Before loading NETSYNC3, ensure that any of the following NLMs that are running are unloaded:

PSERVER.NLM, CLIB, STREAMS, NWPSRV3X, NWSNUT, AFTER311, A3112, and PBURST (for NetWare 3.11 only).

During the installation, newer versions of these NLMs needed by NETSYNC3 are copied to the NetWare 3 server. If these NLMs are already in memory, newer NetWare 4 versions of these NLMs will not load. You must therefore unload these NLMs. You can use the console MODULES command to find out which NLMs have been loaded.

14. Load NETSYNC3 on the NetWare 3 server that will join the NetSync cluster, using this command:

 LOAD NETSYNC3

NETSYNC3.NLM autoloads REMAPID.NLM, and the following NLMs: CLIB, STREAMS, NWPSRV3X, NWSNUT, AFTER311, A3112, and PBURST (NetWare 3.11 only).

15. If this is the first time NETSYNC3 is loaded on this server, you will be asked to enter the name of the NetWare 4 host that you want this NetWare 3 server to synchronize with (see fig. 9.13).

Figure 9.13 NETSYNC3 initial screen asking name of 4.x to synchronize with.

Enter the name of the NetWare 4 server, and then enter the NetSync password.

NetSync will upload NetWare 3 bindery information to the NetWare 4 bindery context. If other NetWare 3 servers exist in the NetSync cluster, this information will be downloaded from the NetWare 4 bindery context to the NetWare 3 servers.

The Options menu will appear after the bindery synchronization (see fig. 9.14).

16. You can optionally configure the NetSync environment on the NetWare 3 server by selecting the options in figure 9.14.

17. You can verify that all information is synchronized. You can also examine the NetSync log files by selecting the option View Active Log from the Options menu.

Figure 9.14 The NETSYNC3 Options menu.

Installing NetSync on NetWare 3 from Disk

You can install NetSync on NetWare 3 servers from disk. This involves creating the installation disks and then installing NetSync using the Product Options from the INSTALL.NLM menus. The steps to perform these tasks are as follows:

1. Log in to a NetWare 4 server as a user that has at least Read and File Scan rights to SYS:SYSTEM.

2. Change to the SYS:SYSTEM\NETSYNC directory.

3. Run the MAKEDISK batch file to create the installation disks. Use the following command:

 MAKEDISK A:

4. Insert blank formatted disks in drive A when prompted to do so.

5. From a NetWare 3 server, load the INSTALL.NLM with this command.

 LOAD INSTALL

6. Select Product Options. You will see a list of currently installed products installed via this Product Options. Examples of these products are NetWare NFS, NetWare for SAA, NetWare Communications Server, and so on.

Press Ins to add a new product.

7. When prompted to insert the installation disk in drive A, insert the NetSync installation disks prepared in steps 3 and 4.

The INSTALL.NLM invokes the installation script on the disks and proceeds with the installation.

8. Exit INSTALL.NLM when the installation completes.

NetSync Maintenance

When NetSync is running, you might be required to perform some maintenance tasks. Or, you might want to monitor that NetSync is performing the bindery synchronization correctly. The maintenance tasks can be done from the Options menu of the NETSYNC4 and NETSYNC3 NLMs. These tasks include the following:

View activity log
Log file options
Edit server list
Configuration options

These options are shown in figure 9.15 for NETSYNC4 on a NetWare 4 server.

Figure 9.15 The NETSYNC4 Options menu.

The Edit Server List option is used to add NetWare 3 servers to the NetSync cluster or edit information on the servers. (Adding a new NetWare 3 to a NetSync cluster was described in the NetSync installation section in this chapter.)

The View Activity Log option is used to view a log of the bindery synchronization events. Figure 9.16 shows a typical activity log that is displayed by making this selection.

Figure 9.16 NETSYNC4 Activity Log.

This activity log is the contents of the file SYS:SYSTEM\NETSYNC\NETSYNC.LOG. Each entry in this log has a date and time of the occurrence of the event. A brief description of the event enclosed in asterisks (**) is displayed. The second line in each log entry shows the C++ language function called and the parameters to this function. The NetSync log file includes synchronization events such as the following:

Additions, deletions, or changes to users or groups
Password changes
Logins and logouts of NetSync servers
Login script changes
Success or failure of local modification attempts
Items that are queued to be sent to other servers

The Log File options are shown in figure 9.17. The View Log File History option shows the entire contents of the NETSYNC.LOG file. This is different from the View Active Log that shows only the events that are occurring now.

When the Enable Log File option is set to Yes, synchronization events are logged. If set to No, logging of these events is disabled.

When the Delete Current Log File option is set to Yes, the current log file is deleted, and a new log file is started. If you do not want to delete the current log file, set this field to No.

Figure 9.17 NETSYNC4 Log File Options.

When the Show All Events on Log Screen is set to Yes, all bindery synchronization events are logged. This could produce a voluminous log. If you only want to report major bindery synchronization events, set this field to No.

The Maximum Size of Log File shows the maximum size of the NETSYNC.LOG file in bytes. This field is used to control the amount of data in the log file. When the maximum size is reached, the file is renamed with an OLD extension, and a new log file is begun. Because the system can have two log files at any time, you will have free disk space that is at least twice the value of this field. The default value is 524,288 bytes.

Figure 9.18 shows the Configuration Options of the NETSYNC4 main menu. If the Delete NetSync Configuration Data option is set to Yes, the system default values for the NetSync configuration parameters are used.

Figure 9.18 NETSYNC4 Configuration Options.

The Watchdog Delay Interval controls how frequently NETSYNC4.NLM checks the NetWare 3 servers in the NetSync cluster to see if they are online. The default value is 300 seconds; it can be set from 30 seconds to 18 hours. If a NetWare 3 server does not respond within this interval, NETSYNC4 will retry a few more times. If there is no response, NETSYNC4 terminates the connection to the server.

If the Synchronize Login Script Updates to Mail Dir option is set to Yes, the NDS login script changes are sent to the login scripts in the NetWare 4 server's SYS:MAIL directory. This enables users to log in to the NetWare 4 server in the bindery mode and execute the same updated login scripts that are synchronized to the NDS login script for the user. If you have users who log in as NDS users and also as bindery users, you should set this option to Yes, so that the users' login environment is similar. If you do not have users logging in the bindery mode, you should set this option to No to avoid the overhead of login script synchronization.

Removing a NetWare 3 Server from a Cluster

Earlier, you learned how to add a NetWare 3 server to a NetSync cluster. On occasion, you may want to remove a NetWare 3 server from a NetSync cluster. If, for example, you want to upgrade a NetWare 3 server to a NetWare 4 server, you should first remove it from the NetSync cluster.

You can remove a NetWare 3 server from a NetSync cluster using NETSYNC4.NLM. This is done by deleting the server name from the list of Authorized Servers. This automatically removes the NetWare 3 server from the NetSync cluster. You can remove the servers only one at a time.

Removal of a NetWare 3 server from a NetSync cluster can be performed using the following steps:

1. Make sure NETSYNC4 is running on the NetWare 4 server.

2. From NETSYNC4's Options menu, select Edit Server List.

3. Highlight the NetWare 3 server you want to delete and press Del.

Uploading a NetWare 3 Server's Bindery to the NetWare 4 Server

If SYSCON is used on the NetWare 3 server to modify user properties other than the user password, the server bindery will be out of synchronization with the super-bindery. The NetWare 3 bindery could also be out of synchronization if you ran a program on the NetWare server that modified the bindery.

In this case, you must manually upload the changes to the NetWare 4 server, so that the servers in the NetSync cluster are synchronized with the changes.

You must perform this synchronization from NETSYNC4. An outline of these steps follows:

1. Ensure that NETSYNC4 is running.

2. From NETSYNC4's Options menu, select Edit Server List.

3. Highlight the NetWare 3 server whose bindery you want to upload and press Enter. The Authorized Server Information screen appears (see fig. 9.19).

4. Set the Copy 3.1x Bindery to 4.1 field in the Server Information form to Yes.

5. Press Esc. You will be asked to verify if this information is correct. The NetWare 3 server bindery information is copied. Only new information is added. Duplicate information is ignored.

Figure 9.19 The NETSYNC4 Authorized Server Information screen.

Deleting NetSync Configuration Information

If you lose the NetSync password or want to join the NetWare 3 server to a different NetSync cluster, or if the NetWare 3 server is not going to run NetSync anymore, you must delete the NetSync configuration information.

On a NetWare 4 server, the NetSync configuration data includes the names of the NetWare 3 servers in the NetSync cluster (and associated passwords) and the NetSync password.

On a NetWare 3 server, the NetSync configuration data includes the name of the NetWare 4 host and the NetSync password.

The procedure for deleting the NetSync configuration data for a NetWare 3 server is as follows:

1. From NETSYNC3's Options menu, select Configuration Options.

2. Select Delete NetSync Configuration Data.

3. Enter Yes.

Observing the Effects of Super-Bindery Synchronization

The NDS user and group objects in the bindery context form a super-bindery. These objects are the aggregation of all user and group objects that are on the NetWare 3 servers in the NetSync cluster. Any changes made to objects in the bindery context on the NetWare 4 server are synchronized to all NetWare 3 servers in the NetSync cluster. This enables the servers in the NetSync cluster to be managed from a central location.

Even though NetWare 3 servers have no directory service capability, they can reap the benefits of directory services by joining the NetSync cluster. If a new User object is added to the super-bindery, it is replicated to all the servers in the NetSync cluster. However, you must still assign appropriate file system rights, such as rights to individual home directories, for the new users in their respective servers.

Any NetWare 3 server can join the NetSync cluster, but there is a limit of 12 NetWare 3 servers per NetWare 4 server. This limit is placed for performance reasons. The NetSync NLMs are memory and CPU intensive. As more NetWare 3 servers join a cluster, the amount of synchronization could increase and this would adversely impact the performance of the servers.

You must also take into account the number of objects in the super-bindery on the NetWare 4 server. Although there is no limit to the number of objects in a container, experience suggests a limit of 3,000 objects in a single container. Novell recommends a more conservative limit of 1,000 objects. Remember, as the number of objects increases in a container, scrolling through the lists of objects using NWADMIN or NETADMIN to find the object that you want can become tedious.

The following is a guided tour of observing the effects of bindery synchronization when changes are made to the super-bindery.

Figures 9.20 and 9.21 show the objects in the containers OU=CORP.O=ESL and O=ESL. The bindery context of the NetWare 4 server is set to OU=CORP.O=ESL;O=ESL. Figures 9.22 and 9.23 show the Group and User objects viewed using SYSCON on a NetWare 3 server that is synchronized to the super-bindery on the NetWare 4 server.

The group objects Corporate, Engineers, Everyone, Marketing, Nfsgroup, Nogroup, and Students (see fig 9.20) existed originally on the NetWare 3 server (see fig. 9.22). When the NetWare 3 server joined the NetSync cluster, these bindery objects were uploaded to the super-bindery as corresponding NDS group objects. The bindery group MGRS (see fig. 9.22) originally existed in the container O=ESL (see fig. 9.21) prior to bindery synchronization. Because O=ESL is in the bindery context, the NDS group object Mgrs was synchronized to the NetWare 3 server when the NetWare 3 server joined the NetSync cluster.

The users ADMIN, JAN, DEI, KSS, and LISA (see fig. 9.23) originally existed in the bindery context on the NetWare 4 server (see figs. 9.20 and 9.21). These NetWare 4 users were synchronized to the NetWare 3 server as bindery user objects. Figure 9.24 shows additional user objects in the OU=CORP.O=ESL container that were not shown in figure 9.20. The NDS users Anonymous, Guest, HACKER, Nobody, Test, User1, User10, User11, User12, User13, User14, User1, User2, User3, User4, User5, User6, User7, and User8 were transferred from the NetWare 3 bindery to the bindery context on the NetWare 4 server.

Figure 9.20 Objects in container OU=CORP.O=ESL.

Figure 9.21 Objects in container O=ESL.

Figure 9.22 Group objects on NetWare 3 server.

Figure 9.23 User objects on NetWare 3 server.

Figure 9.24 Additional user objects in OU=CORP.O=ESL.

Now consider what happens when a new user object Newuser is created in the bindery context in container OU=CORP.O=ESL. Figure 9.25 shows this new user object being created on the NetWare 4 server. Figure 9.26 shows the list of users on SYSCON a few seconds after the user Newuser is created. Notice that the Newuser object appears in the list of users on the NetWare 3 server. Figure 9.27 shows the full name property of this user on the NetWare 3 server. Notice that the full name property for the NDS user Newuser is preserved during synchronization (see fig. 9.25).

Figure 9.25 New user object created in OU=CORP.O=ESL.

Figure 9.26 New user object synchronized to NetWare 3 server.

Figure 9.27 Full name property of user synchronized to NetWare 3 server.

Creating Home Directories for Synchronized Users

When a user is created in the super-bindery on the NetWare 4 server, it is replicated on all the NetWare 3 servers in the NetSync cluster. However, the home directory for this user is not created on the NetWare 3 servers. This must be performed as a separate step. You can create the home directories by logging in to the NetWare 3 servers and then creating the home directories and assigning suitable file system rights to the user.

Alternatively, you can create the home directories through NDS tools such as NWUSER on the central NetWare 4 server. To do this, you must have an NDS object representation for the NetWare 3 servers and its volumes in the NDS tree. Creation of these NDS representations of the NetWare 3 server and volume objects are described in the next section. After you create the NDS object for the NetWare 3 server, you can create the home directory by selecting the volume object from NWADMIN. Figure 9.28 shows the directories under the NetWare 3 volume object S386_SYS for the server S386. Figure 9.29 shows the creation of the home directory. The screen shown in this figure is obtained by highlighting the USERS directory, pressing the right mouse button, selecting Create, entering the directory name to be created, and pressing Enter.

You can use NWADMIN to assign trustee rights to the user's home directories. Figure 9.30 shows trustee rights of Read, Write, Create, Erase, Modify, File Scan, and Access Control being assigned to user NEWUSER for the home directory SYS:USERS\NEWUSER.

Figure 9.28 Directories under NetWare 3 volume object.

Figure 9.29 Creation of home directory for a NetWare 3 user from the NetWare 4 NWADMIN.

Figure 9.31 shows the directory trustee assignments of user NEWUSER on the NetWare 3 server when viewed from SYSCON. From this figure you can verify that the rights changed through NWADMIN are indeed changed on the NetWare 3 server, and SYSCON can be used to confirm these changes.

Figure 9.30 Assigning trustee rights to home directory for a NetWare 3 user NEWUSER using NWADMIN.

Figure 9.31 Viewing trustee rights to home directory for a NetWare 3 user using SYSCON.

Creating NDS Objects for NetWare 3 and NetWare 2.x Servers

NetWare 4 allows the creation of NDS objects corresponding to NetWare 3 and NetWare 2.x servers within the NDS tree. These NDS objects can be defined anywhere in the NDS tree. As long as you assign an NDS name that is the same as the name of the NetWare 3 server, you can perform limited server-management functions on NetWare 3 and NetWare 2.x servers.

The following is a guided tour of how you can create the NDS representation of a NetWare 3 or NetWare 2.x server and perform management functions on NetWare 3 and NetWare 2.x servers.

1. Log in to the NDS tree as a user with Browse and Create object trustee rights in the container where the NDS object is to be created.

2. Run NETADMIN or NWADMIN and select the container in which the NDS object is to be created.

It is assumed in this guided tour that you want to create the server objects in the container OU=ENG.O=ESL. Also, it is assumed that the NWADMIN tool is being used. The steps for using NETADMIN are very similar.

3. With the container highlighted, select the Create function.

4. When the New Object dialog box appears, select the NetWare server object, and select the OK button.

5. When the Create NetWare Server dialog box appears, enter the name of the NetWare 3 or 2.x server, and select the Create button.

6. If you are prompted for a login name, enter the login name and password for a valid user with Supervisor privileges to the NetWare 3 server.

7. Highlight the newly created server object and examine its properties (see fig. 9.32).

Figure 9.32 Properties of the NetWare 3 server object.

You can examine the name of the server, the network address of the server, and the version number of the server. Figure 9.32 shows that the name of the server is S386.CORP.ESL; its IPX network address is F0000311:000000000001:451; its version number is Novell NetWare 3.11 (100 user).

You can also examine other properties of the NetWare server such as error log, operators, and accounting information such as blocks read, blocks written, connect time, disk storage, service requests, and so on.

You can install accounting or remove accounting functions for the NetWare 3 server from the NDS tools.

8. Create the volume NDS objects for the NetWare 3 or 2.x server while still logged in as a user with Browse and Create object trustee rights to the NDS container in which you want to create the volume objects.

Highlight the container in which the volume object is to be created.

9. With the container highlighted, select the Create function.

10. When the New Object dialog box appears, select the volume object, and select the OK button.

11. When the Create Volume dialog box appears, enter the following information:

Volume Name. This is the NDS name of the volume. It does not have to match the physical volume name on the NetWare server.

Host Server. This is the name of the NetWare server to which the volume is connected. This must be the name of the server in the NDS tree. For NetWare 3 and 2.x this is the server name.

Physical Volume. This is the physical name of the volume as seen from the host server. You can select the down arrow on the right of this field to select the physical volume names on the server.

A sample Create Volume dialog box is shown in figure 9.33. Select the Create button to create the volume object.

You can now manage the NetWare 3 volume object as any other NDS volume object. Specifically, you can see the file system directory structure for the volume, create and delete file system directories, assign trustee rights to the file system, and view volume statistics.

Figure 9.34 shows the detail properties screen for the NetWare 3 NDS volume object. Figure 9.35 shows the statistics for the volume, which shows a graphical display of disk space and directory usage. This shows that the disk space is 85 percent full with only 9 MB available. If the PURGE command is used, 7,872 KB of space would become available. The volume block size is 4,096 bytes, and 71 percent of the allocated directory entries are in use. This screen also shows the name spaces installed on the volume. In this example, the volume S386_SYS has DOS, NFS, and FTAM name spaces.

Figure 9.33 The Create Volume dialog box for a NetWare 3 volume.

Figure 9.34 Volume properties for a NetWare 3 volume.

Figure 9.35 Volume statistics of a NetWare 3 volume.

Figure 9.36 shows the user space limits report obtained by selecting the User Space Limits button from the detail properties screen for the volume object (refer to fig. 9.34). This shows that user HACKER has a space limit of 1,024 KB and has used 20 KB; it also shows the amount of disk space used by each user on the NetWare 3 server.

Figure 9.36 User Space Limit restrictions on a NetWare 3 volume.

Synchronizing Printing Functions Using NetSync

During NetSync installation on the NetWare 3 servers, all NetWare 4 workstation print utilities are copied to the NetWare 3 servers that join the NetSync cluster. The utilities that are copied are CAPTURE, NPRINT, NPRINTER (NLM and EXE), PCONSOLE, PRINTCON, PRINTDEF, PSC, PSERVER.NLM, and PUPGRADE.NLM. All support files needed for these utilities are copied as well.

After completing NetSync installation on the NetWare 3 server, replace the NetWare 3 RPRINTER.EXE in NetWare 3 workstations with the equivalent NPRINTER.EXE utility. Replacing RPRINTER with NPRINTER can improve the printing performance on remote printers.

NOTE: During NetSync installation on the NetWare 3 servers
All NetWare 4 workstation print utilities are copied to the NetWare 3 servers that join the NetSync cluster.

Databases for PRINTCON and PRINTDEF are upgraded to NetWare 4.

If you are running the NetWare 3 PSERVER.NLM on NetWare 3 servers, unload it and run the NetWare 4 PSERVER.NLM that was installed as part of the NetSync install on the NetWare 3 server. When the NetWare 4 PSERVER loads, it will automatically load the NetWare 4 NPRINTER.NLM.

The NetWare 4 print utilities can operate in a bindery mode, and their behavior in the NetWare 3 server is similar to what can be expected from their NetWare 3 counterparts. The print job configurations and print databases created with PRINTCON and PRINTDEF are converted to a NetWare 4 format and copied to the NetWare 4 print databases.

To simplify administration of the NetWare 3 print servers, you can merge them into a single print server object in the NDS. This merging will also result in the NetWare 3 printers being placed in the NDS, where they can be managed from a single NetWare 4 print server.

When you run NETSYNC3 on a NetWare 3 server, you must confirm that you will be using the NetWare 4 print databases and utilities. If you do not confirm this change, NETSYNC3 will unload itself.

The following sections discuss additional details for print synchronization.

Using NetWare 4 Print Databases

When the NetWare 3 print database is converted to the NetWare 4 print database format, the original information is retained in the conversion process; only the format is changed. The NetWare 4 print database format is needed by the NetWare 4 utilities that are copied onto the NetWare 3 servers in the cluster. The NetWare 4 utilities cannot use the NetWare 3 print databases directly because they have an incompatible format.

To avoid conflicts, the NetWare 3 PRINTCON and PRINTDEF utilities are deleted during the NetSync synchronization. Even though the NetWare 3 print databases cannot be accessed by the NetWare 4 utilities, they are retained as a backup and for third-party utilities that may still require them. If you do not need these NetWare 3 print databases for backup or third-party utilities, delete them.

The NetWare 4 server acts as a focal point of all changes that need to be synchronized. You should, therefore, make changes to the NetWare 4 print databases from the NetWare 4.1 server. These changes will then be synchronized to the NetWare 3 servers. If you make changes to the NetWare 3 server print database directly, these changes will not be synchronized with other servers in the NetSync cluster.

Synchronizing Print Servers

If you have a complex printing environment under NetWare 3, you can simplify it by moving it to a NetWare 4 environment. NetSync does much of the necessary synchronization, but you might still have to perform some manual configuration.

You can use NetSync to move the NetWare 3 print servers to the NetWare 4 NDS so that these print servers can be administered from a central location. You can merge the print resources of all the NetWare 3 servers in the NetSync cluster (up to 12 NetWare 3 servers). As a result of this merging, configuration information for the NetWare 3 print servers and their associated printers and queues is transferred to a single NetWare 4 print server NDS object.

NOTE: You can merge the print resources of all the NetWare 3 servers to a single NetWare 4 print server NDS object that can support up to 256 printers.

During the print server merging operation, NetSync makes no distinction between a NetWare 3 PSERVER.NLM running on a server and a PSERVER.EXE running on a dedicated workstation. Both types of print servers are merged into the NetWare 4 print server object. Under NetWare 4, PSERVER.EXE and RPRINTER.EXE do not exist. These are replaced by NPRINTER.EXE at the workstation. Remote printers attached to NetWare 4 servers are handled by NPRINTER.NLM running on the NetWare server. There is no equivalent to the NPRINTER.NLM in the NetWare 3 printing environment.

The first NetWare 3 print server you merge retains the configuration information it had in NetWare 3, including printer numbers. When additional NetWare 3 print servers are merged, the printer numbers could conflict with printer numbers already assigned to the NetWare 4 print server. When printer number conflicts arise, NetSync assigns new numbers to the new printers. It is not necessary to merge all NetWare 3 print servers to the same NetWare 4 print server. You could, for instance, merge 7 NetWare 3 print servers to the print server PS-CORP running on a NetWare 4 server and merge another 5 NetWare 3 print servers to PS-ENG on another NetWare 4 server.

When merging NetWare 3 servers to a NetWare 4 server, keep in mind that the maximum number of printers administered through a single NetWare 4 print server is 256. This number is considerably larger than the NetWare 3 print servers limit of 16 printers per print server. NetWare 3 print servers that are not merged must be administered through PCONSOLE on the NetWare 3 server.

The following is a guided tour of the print merge administration tasks.

1. Log in to the NetWare 4 server as a user that has Browse and Create object trustee rights to the server's bindery context containers.

2. To merge the print servers on the NetWare 3 server, you must have access to the NetWare 3 server console. This can be done by physically going to the NetWare 3 server or using RCONSOLE for remote console access.

From the NETSYNC3 menu running on the NetWare 3 server, select the Move a Print Server option. You will see a list of print servers that are available for merging (see fig. 9.37). If there is only one print server, you will be asked to confirm the name of the print server.

NOTE: During moving of print servers, if you type in a new name of a NetWare 4 print server that does not exist, it will be created in the NDS database without a password.

Figure 9.37 List of NetWare 3 print servers available for merging.

3. After you select the print server name, you must enter the name of the NetWare 4 print server to which the NetWare 3 print server is to be merged (see fig. 9.38).

Figure 9.38 NetWare 4 print server to which to merge.

The selected print server is now merged to the NetWare 4 printing environment.

To examine the changes that have taken place, you can view the activity log on the NetWare 3 (see fig. 9.39) and NetWare 4 servers (see fig. 9.40).

Figure 9.39 Activity log for NETSYNC3 showing the print server merger.

Figure 9.40 Activity log for NETSYNC4 showing the print server merger.

You can also examine the printing environment using PCONSOLE or NWADMIN. Figure 9.41 shows the queues that are imported using PCONSOLE. Four queues named {S386_QUEUE_0}, {S386_QUEUE_1}, {S386_QUEUE_2}, and {S386_QUEUE_3} are imported. These queues were connected to the merged NetWare 3 print server and were named QUEUE_0, QUEUE_1, QUEUE_2, and QUEUE_3.

Figure 9.41 Viewing queues imported from NetWare 3 with PCONSOLE.

Figure 9.42 shows the print server PS_NETSYNC's assignment property. PS_NETSYNC was the name of the NetWare 4 print server to which the NetWare 3 print server was merged. The printer P_NETSYNC.CORP.ESL was already defined on the NetWare 4 server. The printers "Serial Printer.CORP.ESL" and "unixprinter.CORP.ESL" were imported from NetWare 3 as a result of the merger.

Figure 9.42 Viewing change of NetWare 4 print server assignments using NWADMIN.

To examine the print server, printer, and print queue associations, select the Print Layout page button from the detail properties of the print server object. Figure 9.42 shows the new associations. From this figure you can see the following:

The queue Q_NETSYNC is assigned to the printer P_NETSYNC.

The queues {S386_QUEUE_0}, QUEUE_0, {S386_QUEUE_1}, QUEUE_1, {S386_QUEUE_2}, QUEUE_2, {S386_QUEUE_3}, and QUEUE_3 are assigned to Serial Printer.

The queues {S386_QUEUE_1} and QUEUE_1 are assigned to the printer unixprinter.

The printers P_NETSYNC, Serial Printer, and unixprinter are assigned to the print server PS_NETSYNC.

To complete the print configuration, you must make sure that the printers are connected as indicated in the NetWare 4 printing environment. NetSync does not know about the physical printer configuration, or to which device or printer port the printer is supposed to be connected. You must also load the PSERVER NLM and specify the merged print server to activate the NetWare 4 printing environment. Because NetWare 4 print server functions are more efficient than NetWare 3 print server functions, NetWare 3 users may notice an improvement in speed and performance over the NetWare 3 printing environment.

Some print environments use third-party direct network attached print devices. These devices either connect to a printer and then to the network, or are installed in a port at the printer, or are placed in a slot inside the printer itself. These print devices emulate a NetWare 3 print server and are designed to look in the NetWare 3 bindery for network printing information. Therefore, you should not move the queue server configurations used by these print devices unless you plan to reconfigure these print devices to the NetWare 4 environment. The third-party print devices can work with the NetWare 4 printing environment if you are using the bindery emulation mode at the NetWare 4 print server.

Although it is possible to operate NetWare 3 servers under NetWare 4, the NetWare 3 servers do not have the inherent central management capability of NDS. NetSync enables you to manage NetWare 3 servers from the NDS of a NetWare 4 host. Users, groups, and print environments of a NetWare 3 server can be managed from the NetWare 4 NDS.

Migrating to Netware 4.1 -- Ch 9 -- Setting Up NetSync for Bindery Emulation