Where these files are stored depends on which version of NetWare you are using. With NetWare 3.x or bindery-based servers, these profiles are stored in the user's mail directory on the SYS volume. In an NDS scheme, they are stored in a "Windows NT 4.0 Workstation Profile" directory located in the user's home directory (as defined in NDS).

One more hint: You'll need to enable the LONG name space on 4.11 servers or the OS2 name space for 4.0x servers for this to function correctly. Upon login to the workstation, the aforementioned directory is copied to the local workstation. Changes are copied back upon logout. Should the machine crash before the user logs out, changes may be lost. If the user logs back into the same machine, the NT client will see that the local copy of the profile is newer than the version stored on the server and will prompt for which version to use.

Under the current NetWare client, roaming profiles are enabled on a workstation level. If enabled, all users of that workstation will benefit from roaming profiles.

Under Z.E.N.works, roaming profiles are enabled on the user object. By allowing only specified users to have roaming profiles, you might be able to save yourself some headaches. For example, if each machine is not set up the same for all applications, registry settings stored in HKEY_CURRENT_ USER, which follow the user from machine to machine, may not point to the correct file system locations. Other items such as desktop shortcuts may not work, as they could point to paths that are not on other machines.

All is not roses when using roaming profiles. If you use Microsoft's Internet Explorer 4.0, you'll need to be aware of one other configuration issue. When we were experimenting with roaming profiles in our labs, one particularly nasty problem cropped up: The default location for the storage of IE cache files changed from a common directory for all users to a directory stored in the user profile area. We found that this change causes major delays when users log in and out of the NT Workstation. Fortunately, we were able to change the IE 4.0 settings to remedy this problem.

Another issue to watch for has to do with applications storing their settings in the HKEY_CURRENT_USER portion of the registry. Though this isn't an issue if you are attempting to use an application that you installed, you may not be able to run applications installed by other users, including those installed by the administrator. In our environment, we circumvented this problem by ensuring that the NTUSER.DAT file located in WINNT\Profiles\Default User is always up to date (see "Keeping NTUSER.DAT Up to Date," on page 126).

The NTUSER.DAT file stores the HKEY_CURRENT_USER registry hive. The first time a user logs into an NT workstation, the system copies the WINNT\Profiles\Default User directory over to his or her profile directory. This allows administrators to have a base set of options preconfigured for users.

Policies 'R Us Here's a tip we've found helpful for maintaining our NT workstations: Use policy files. With policy files, you are able to control different aspects of the NT workstation and user profiles--including restricting access to the control panel and desktop color schemes as well as various workstation settings--or make settings that affect all users. We use Microsoft's POLEDIT utility to set up our policies. Whether you use the Microsoft or the Novell client, a file called NTCONFIG.POL located on the default server is used to set policies.

The downside to using it is that your .POL files will need to be located on all the servers in your network, or at least on all the servers a workstation might select as its preferred server. Also, if the Default Computer or Default User is used to create a restrictive policy, users or workstations that are not a part of your locked-down domain (in our case, faculty and staff) will create additional entries in your .POL file. If you have a number of machines or users that need to be excluded, you could be in for an administrative nightmare. For each user that needs to be excluded, you have to create a separate entry in POLEDIT.

With the Z.E.N.works client, Novell has made it possible for you to accomplish just about everything you could do with POLEDIT inside of NDS. Additionally, it's much easier to control the specific user accounts and machines to which you wish to apply policies. Unfortunately, if you need to add custom extensions, you are out of luck. No provisions currently exist to add custom extensions to this interface. However, Novell plans to add this functionality in the next update of the client.

James E. Drews is a network administrator for the Computer Aided Engineering Center of the University of Wisconsin-Madison. He can be reached at drews@engr.wisc.edu.