Novell is now a part of Micro Focus

Implementing Novell's NT Workstation Manager

Articles and Tips: article

KEVIN PRIOR
Senior Consultant
Novell Consulting Services

01 Jun 1997


You've seen all the goodies that come with the IntranetWare Client for Windows NT, including Workstation Manager. In this AppNote, a Novell Senior Consultant guides you through how to install and use this powerful administrative tool.

Introduction

Novell recently released the IntranetWare Client for Windows NT, the latest in our client technology that takes full advantage of 32-bit operating systems. This new 32-bit client includes software for integrating computers running Microsoft Windows NT Workstation and NT Server, allowing them to reap the benefits of Novell Directory Services (NDS) and access resources on Novell networks.

One of the components included with the IntranetWare Client for Windows NT v4.1 is the Novell Workstation Manager. The AppNote entitled "Managing NT and NDS Account Information Using the Novell Workstation Manager" in the April 1997 issue of AppNotes introduced this tool and provided basic usage information. This AppNote goes into greater detail to help network administrators understand how to install, configure, and use the Novell Workstation Manager for Windows NT. The following topics are covered in this AppNote:

  • Overview of Novell Workstation Manager

  • Installing Workstation Manager, including command-line switches

  • Enabling Workstation Manager once it is installed

  • Setting up an NT Configuration object

  • Managing an NT Configuration object

  • Deployment of NT Workstation Manager

  • Upgrading from the Microsoft client for NetWare networks

The IntranetWare Client for Windows NT v4.1 software can currently be obtained at no charge on Novell's web site at the following URL:

http://support.novell.com/Ftp/Updates/nwos/iwclnt41/Date0.html

Overview of the Novell Workstation Manager

The Novell Workstation Manager allows all user account information, both for Windows NT and Novell Directory Services (NDS), to be centrally managed within NDS using a single administrative utility: NWAdmin. It also eliminates the need to have an NT domain or a large number of NT user accounts residing in the local Security Access Manager (SAM) of each NT workstation, therefore eliminating multiple administration and saving time and money.

The Workstation Manager stores Windows NT user and desktop configuration information in NDS. If a user's NDS user account is associated with this configuration information, that user can access the network via any NT workstation configured with the Workstation Manager. If the user does not have an account on the workstation at the time of login, Workstation Manager can create one according to the associated NT user information. Once the user is attached to the network, an associated individual profile and policy can be downloaded to the workstation to provide a consistent desktop on each NT workstation being used.

The Workstation Manager has two components:

  1. Novell'simplementation of the Graphical Identification and Authentication module for Windows NT (NWGINA).

    NWGINA is the component that collects the user's username and password and then authenticates the user to NDS and the NT Workstation. In order to perform this operation, NWGINA runs on the NT workstation with administrative privileges. This administrator-level access allows NWGINA to dynamically create and delete NT user accounts, provided it can obtain the necessary user information from the NT Configuration object.

  2. NetWare Administrator snap-in.

    The snap-in stores the NT user information in an NT Configuration object in NDS. It consists of two DLLs that snap into the NT version of the NWAdmin utility (NWADMNNT.EXE).By using this utility and the accompanying snap-in DLLs,the network supervisor can create NT Configuration objects within NDS containers. These NT Configuration objects store all the information necessary for NWGINA to dynamically create a preconfigured user account on the NT workstation and grant a user access to NT when that user logs in to the NDS tree.

    Workstation Manager is an add-on to the existing IntranetWare Client for NT. With this add-on you will no longer have the huge administrative costs of creating NT users on every NT Desktop. Novell's NT client software allows IntranetWare users to take advantage of the existing NDS infrastructure without the burden of manually having to create user IDs on each NT Workstation.

Installation of the IntranetWare Client for Windows NT

The installation program for the IntranetWare Client for Windows NT is called SETUPNW.EXE. The default client configuration that is installed is designed to give users full access to the IntranetWare resources and NDS objects in the network. The SETUPNW.EXE program makes the following changes to the user's computer:

  • Removes any existing NetWare client software, specifically Microsoft Client for NetWare Networks and Microsoft Service for Novell Directory Services

  • Installs Novell's IntranetWare Client for Windows NT

The Novell IntranetWare Client for Windows NT files are copied to the local hard disk. The folder for the Novell IntranetWare Client for Windows NT is created under the WINNT\SYSTEM32\NETWARE directory on the workstation's Windows drive. Most of the files are copied to this folder. Other files are copied to the appropriate Windows NT folder, such as the \WINDOWS\ SYSTEM32and \WINDOWS\HELP folders.


Note: The SETUPNW.EXE program does not automatically enable the WorkstationManager. By default,it only installs the core of the IntranetWare Client for NT. The following sections describe how to enable and managethe Workstation Manager.

Installation Switches for Workstation Manager

There are a few switches that can be viewed by running SETUPNW.EXE /? from Start | Run or from a command prompt. These switches are as follows:


/U

Uses a textfile to specify the default functionality. The default text file, UNATTEND.TXT, is used if no alternative is presented with the /U:<unattended file path<option.

/ACU

Specifies thatthe program is to check the version stamp and proceed to install using the defaultsif an older version of the client software is detected. If not all the values can bedefaulted, the user will be prompted only if absolutely necessary. If used in conjunction with the /U option, the defaults will be taken from the Unattended file.

/W

Installs theWorkstation Manager utility.

/?

Displays helpinformation about using SETUPNW.EXE.

To install the Workstation Manager, run SETUPNW.EXE /W:Tree1,.... You can specify the names of the NDS trees to look for NT Configuration objects.

Enabling the Workstation Manager

Once Workstation Manager is installed you must enable the NWAdmin snap-in settings and the Workstation Manager settings in the Windows NT Registry.

Enabling the NW Admin Snap-in Settings. Included with the IntranetWare Client for Windows NT is a file called WORKMAN.REG, where the NT client configuration settings are stored. This file must be run for the client to view and manage an NT Configuration object. If this file is not run, you will not be able to administer NT Configuration objects and a "?" (denoting an unknown object) will appear in the tree for these objects.

The WORKMAN.REG file reads as follows (line breaks have been added for readability):

REGEDIT4

[HKEY_CURRENT_USER\Software\NetWare\Parameters\NetWare

  Administrator\Snapin Object DLLs WINNT]

"APPSNPNT.DLL"=hex(7):41,50,50,53,4e,50,4e,54,2e,44,4c,4c,00"
"AUDITNT.DLL"=hex(7):41,55,44,49,54,4e,54,2e,44,4c,4c,00"
"REGEDTNT.DLL"=hex(7):52,45,47,45,44,54,4e,54,"
          2e,44,4c,4c,00 "NWCSNAP"="NWSMGR32.DLL""
; This is a simple registry file that will create the user

; registry keys for the Novell Workstation Manager NWAdmin

; snapin. When this key is created the Novell Workstation

; Manager snapin can be used to configure the Novell NT

; Workstaion Manager objects in NDS.

Until these settings are made manually or by double-clicking this file, the updates will not be made and you will not be able to create or manage any NT Configuration objects. It is vital that you understand what this file does and that you run it to achieve a successful installation of a management PC.

Enabling the Workstation Manager Settings

If Workstation Manager has not been enabled on a workstation, Novell IntranetWare Client for Windows NT was not installed using the SETUPNW /Wor SETUPNW /U option. You can enable the NT Workstation Manager without reinstalling the client by enabling Workstation Manager on the Novell Workstation Manager property page in the Novell IntranetWare Client Services Configuration dialog box, accessible from the Network Control Panel.

Once Workstation Manager is activated, you will need to add at least one tree to the Trusted Trees list on the property page. The Trusted Trees list contains the names of the NDS trees that Workstation Manager searches to find NT Configuration objects.

The following registry settings are made to enable the Workstation Manager to view and "Trust" an object from the NDS Tree. Here is an example of how the settings might read (line breaks have been added for readability):

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Novell\NWGINA\Workstation

  Manager]

"Enabled"=dword:00000001"
"Trusted Trees"="Your Tree Name Here""
@=dword:3310ad31

"Configuration Object"="CN=NT Config 1.O=organization""
"Description"="Test of Client configuration 1"
1.)  Login Tabs

  NetWare and NT Tabs Only

  2.)  Login Scripts

     No Changes  

     3.)  Profile/Policy

        Enabled Roaming profiles 

        Home Directory

        4.)  Welcome Screen

\"This is Config 1   Screen\" "

In summary, there are four ways to enable the NT Workstation Manager:

  1. Run SETUPNW.EXE /W:TreeName1,TreeName2,TreeName3.

  2. Update the information in the UNATTEND.TXT file to include Workstation Manager settings and run SETUPNW.EXE /U.

  3. Enable a Trusted Tree from START | Control Panel | Network | Services | Novell IntranetWare Client for Windows NT | Novell Workstation Manager | Enable Workstation Manager on these Trusted Trees. Type in the tree name(s) and click on Add.

  4. Manually edit the registry (not recommended).

Setting Up an NT Configuration Object

After the IntranetWare NT Client software is installed and the client has the proper registry updates, you are ready to create the NT Configuration object by running NWADMNNT.EXE. First go to the container where you want the object located (O=Novell in this example). Select Object | Create | NT Configuration and click on OK, as shown in Figure 1.

Figure 1: The screen in the NWAdmnNT utility where you can create an NT Configuration object.

After the NT Configuration object has been created, the window shown in Figure 2 appears. From here, you can view and changed the properties of the NT Configuration Object you just created.

Figure 2: The NT Configuration object properties window.

Identification. The first property tab is the Identification tab. This brings up the Identification page which shows the object's name and provides a Description entry box. You can enter a brief description of the object and what it is designed to provide for users, group and container objects associated with this object. You could also note any changes you are making to this object. This is strictly for an informational description of the object; the text you enter is not used by Workstation Manager.

Login Tabs. The next property tab is called Login Tabs. Clicking on that tab presents the page shown in Figure 3.

When users first log in, they must press the <Ctrl<-<Alt<-< Delete> keys to initiate the login process and display the graphical login screen. These settings determine which of the four possible tabs will be available. To include a tab, place a check mark in the corresponding box. An empty check box means that tab will not be displayed at login.

Figure #: The Login Tabs page is used to determine which login tabs users need to see when logging into the network.

Login Scripts. From the Login Scripts page (not shown), you can disable login scripts so they will not be processed. You can also provide an alternate login script or profile script (login scripts must be enabled). Other settings include whether you want users to see the script results displayed in a window as they log in, and whether you want the script results window to be closed automatically. Normally, the script results window remains open if an error is encountered during the processing of the login script.

You can also define variables to be passed to the login script. These variables provide a valuable method for customizing login scripts. They are administered in NDS so as to provide central administration for these variables.

Profile/Policy. This tab allows you to configure Windows NT user profiles and system policies. Refer to the online help for more detailed information.

Welcome Screen. By default, the IntranetWare Client for Windows NT comes with a standard bitmap image that is displayed when the workstation is started up. This bitmap is shown on the Welcome Screen page (see Figure 4). If you want, you can create an alternate bitmap with your company logo and insert information specific to your company. Click on the Change button to specify your own bitmap file. You can also change the title message to reflect a greeting or company name.

Figure 4: From the Welcome Screen page, you can specify any bitmap file for your login screen.

Dynamic Local User. The Dynamic Local User page allows you to configure a user account to be created dynamically on the NT workstation after a person successfully logs in (see Figure 5).

Figure 5: Click on the Dynamic Local User tab to tell NWGINA to use NDS to create a temporary user for the NT Workstation.

If the Dynamic Local User box is not checked, NWGINA does not create a user in the local access manager (SAM) and will attempt to find an existing NT user with the user credentials located in the Windows NT tab. You may elect to use IntranetWare credentials (NDS login name, full name and description), in which case the user's password will be the same as the user's NDS password. If you do not use IntranetWare credentials and the User object does not already exist (as indicated by the Manage Existing Accounts check box), Workstation Manager will create the User object as a volatile User object, which means that the User object will be automatically deleted when the user logs out. This will be apparent because the Volatile User check box will be automatically checked if the Use IntranetWare Credentials check box is not checked.

Check the Manage Existing NT Account box if the User object you want to manage with Workstation Manager already exists. If the user exists and this option is set, Workstation Manager will manage the existing account. Workstation group assignments specified by Workstation Manager will be implemented. This also includes whether the Workstation Manager Volatile User box is checked. If this box is checked, the account will be changed from nonvolatile to volatile when the user logs in to the account, and it will be removed from the workstation after the user logs out. If this option is not checked, Workstation Manager cannot manage the existing User object already installed on the NT Workstation.

When NWGINA creates the NT workstation user, it can provide group membership to any NT user groups. The groups that the user is added to are listed in the "Member of" list box. The default configuration is for the user to be added to the Users group. Other groups can be added by selecting the group from the "Not member of" list box and clicking the Add button. Groups can be deleted by choosing the group in the Member of list box and choosing the Remove button.

Client Upgrade. The Client Upgrade tab lets an administrator enable the workstation so that the client files can be automatically updated with newer files on a server. The next time a user logs in, the workstation is automatically upgraded to the new client version and then rebooted to have the new settings take effect. This provides administrators a "hands-off" approach to upgrading the client software on every NT Workstation. This can be a significant cost savings when compared to someone having to manually upgrade every NT Workstation individually, which is necessary with the Microsoft clients.

For this to work, you must create a directory that contains the updated client software and the SETUPNW.EXE file, and point to that directory in the Alternate Login Script Location box (see Figure 6).

Figure #: From the Client Upgrade page, you can enable the workstation to automatically invoke a client upgrade of the IntranetWare Client software.

Associations. The Associations page allows you to associate this NT Configuration object with a particular user, group, or container (see Figure 7).

Figure 7: The Assocations tab lets you associate the NT object with a user, group, or container.

The NT Configuration object will first look at users, then groups, and finally containers. If a user is associated with more than one NT Configuration object, the results can be unpredictable. It is important that you understand and manage this so as to prevent any user, group, or container from being associated with multiple objects.

Managing the NT Configuration Object

As described above, an NT Configuration Object can be associated with any user, group, or container. If you decide to assign an object to the Organization (O) container of your NDS tree, all users in the tree will be associated to this object. Keep in mind that a given user, group, or container object can be assigned to only one NT Configuration object in the tree. If you assign an NT Configuration object to the O container, all users would have the same settings in the entire tree. If you did this and then tried to assign an NT Configuration object to a user in the tree, you would be prompted that this object is already assigned to an object, and you would be given to choice to overwrite this object with this new configuration. The same holds true for any users, groups, or containers when an object is already assigned.

NWGINA Login Process

NWGINA checks for NDS NT Configuration object associations in the order of user first, group second, and container last. NWGINA will use the first NT Configuration object it finds. Thus, if a user is associated to multiple groups and each group is associated to a different NT Configuration object, there is no way to guarantee which NT Configuration object will be used.

To understand this, let's take a look at how the NWGINA determines which NT Configuration object to use. When the user logs in to the NT Workstation and NWGINA is enabled, NWGINA captures the username and password and first verifies that this is a legitimate user for the network and that the user does have access privileges. Then NWGINA looks to see if there is an NT Configuration object associated to that user. If so, NWGINA will use that object to set the configuration and then check to see if there is an entry in SAM for that NDS user.

If a user does not have an object associated to it, NWGINA will look at groups objects the user is associated and a member of. If there is an association, NWGINA uses the first group that it found for the configuration.

If there are no user or group associations, NWGINA will check the local container (the one in which the user object resides) to see if there is an object associated to that container. If no objects are found in that container, NWGINA will go up one level and check for a NT Configuration object. NWGINA will continue to walk the tree up to the [Root] to see if there are any objects associated to that NDS user. Keep in mind that NWGINA uses the first NT Configuration object it finds in this entire process.

From this description of the login process, you can see that management can be very easy or a bit tricky, depending on how you decide to use the objects and assign them in the tree. This is a very useful administration tool and should be understood before you create multiple NT Configuration objects in the tree.

Objects for Manageability

By default, you may want to create at minimum two NT Configuration objects. The first one will be for users who will act as administrators on the NT Workstations to be sure the users are maintained properly and have full access if the NTFS file system is used. The second one would be for all users of that NT Workstation who will be using this as a client machine on the network.

Object for Users. By default, any user created on the NT Workstation belongs to the Users group which has default rights on the workstation. This group can be compared to the group EVERYONE that the NWAdmin utility assigns all newly-created users to for default rights to the IntranetWare network.

You may also decide to create separate groups for association to the NT Configuration objects, to have an easier guideline on assigning these objects to groups and not individual users. This can be done as long as users are not members of more than one group that have an NT Configuration object associated. This will guarantee that each time a user logs in, that user always gets the sane NT Configuration object configuration. If a user is a member of more than one group that has an NT Configuration object associated, it is possible to have different configurations each time the user logs in.

By default, the NT Configuration Object will assign any new user created on the NT Workstation to the Users group. You can easily add or delete any other group you feel is required. This is a good start for the majority of all users to access an NT Workstation and use the IntranetWare and other network resources that user has rights to.

Object for Administrators The administrators for a particular Organizational Unit (OU) in your NDS tree need to have control of all NT Workstations. By creating an NT Admin Group and assigning the Group Administrator to this object, you will allow any user that is part of this group to have administrative rights on any NT Workstation they log in on. You may also want to have them part of Backup Operators, Power Users and Replicator if this capability is needed in your environment.

For example, suppose a user was already created on the NT Workstation prior to installing Workstation Manager. Now this user has moved to another department and no longer needs access to this NT Workstation. By having an object created with Administrator group rights, administrators will be able to delete that user or change any user settings on that machine. They can also reassign any file ownership on that machine from another user that they do not own, provided NTFS is implemented on the NT Workstation.

Deployment of NT Workstation Manager

The deployment of the NT Workstation Manager on NT Workstations can be as easy or as difficult as the administrator makes it. Larger environments can pose some challenges, but predetermined guidelines or rules decided ahead of time make this very easy. Here are a few rules of thumb to start out with:

  • The more objects that are created, the more objects you will have to manage. Try to keep these objects limited to a few per container unless explicitly needed for some reason.

  • Understand how these objects are read and determined in NDS. Just as with designing the NDS tree and replication, you will want to avoid having users traverse a slow link to get to the NT Configuration object to which they are associated. If there will be mobile users frequently traveling between sites, you may want to create an object near your major sites to avoid slow links whenever possible. This should be determined prior to randomly creating these objects in unnecessary places.

Some other issues to consider are:

  • What type of administration is currently in place: centralized or decentralized?

  • From your NDS tree design and replica matrix, what partitions are available on your local servers if container objects are used at higher levels in the tree?

  • How many NT workstations do you have on your network that you will managing with NT Workstation Manager?

  • Of these NT workstations, how many belong to different groups (engineering, marketing, HR, and so on) and may require different configuration settings?

  • How are these different groups defined in your NDS tree and where are they located in the tree?

  • Other than the default of Users, what groups, if any, must be assigned on the workstation?

Based on your answers to these questions, you might decide to roll out one of the following scenarios based on your environment, large or small.

Scenario 1

This is a decentralized environment where there are sub-administrators at each location who can manage their locations, with containers below that for each of the departments. The NDS tree is designed around the WAN links, and as a guideline there are local Read-Write replicas local for the two partitions above this container ([Root], OU=NA). There are a few thousand NT Workstations spread out among four regional locations, 12 site locations, and multiple departmental groups. Most users are not required to be a part of any NT Workstation group other than Users.

Because there are LAN-speed connections between location and departmental OUs, create two objects in each container at the location level: one for administrators and one for users. Associate the administrator of the containers of that location to the administrator NT Object and the group Everyone to the user NT Object. This rule can be followed at each location level of the tree as long as the scenario guidelines are met.

Scenario 2

There is a centralized environment with no sub-administrators at any location. The administration IS group is located in Detroit, MI. Again, the NDS tree is designed around the WAN links and as a guideline there are local Read-Write replicas for the two partitions above this container ([Root], OU=MI). There are a few thousand NT Workstations spread out among seven regional locations, 12 site locations, and many workgroups. Some users are required to be a part of Power Users group on the NT Workstation group.

If you have LAN-speed connections between site locations and any OUs below this, create one new group for Power Users (if you haven't already) and two NT Configuration objects in each container at the location level: one for Power Users and one for Users. Associate the Power Users group in that location to the Power Users NT Object, and the group Everyone to the user NT Object. Also create one NT Configuration object at either the Organizational level or in the IS users container, then associate this object to your IS Administrators group. If administrators need to log in at a remote site, they would use their NDS login ID and find the NT Configuration object over the WAN. Another option might be to create an subadmin ID in each location's OU, and create an NT Configuration object with the group administrators associated to the subadmin ID. This rule can be followed at each location level of the tree as long as the scenario guidelines are met.

Scenario 3

There is a decentralized environment where there are sub-administrators at each location who can manage their locations, with containers below that for each of the departments. The NDS tree is not designed around the WAN links and they do not have a local Rread-Write replica for the two partitions above this container ([Root], OU=NA). There are a few thousand NT Workstations among nine different departmental groups. Most users are not required to be a part of any NT Workstation group other than Users.

Because there are not LAN-speed connections between location and departmental OUs, create two objects in each location container: one for administrators and one for users. For the local users, this will avoid having to walk the tree over the slow WAN links. Then associate the administrator of the containers of that location to the administrator NT Object and the group Everyone to the user NT Object. This rule can be followed at each location level of the tree as long as the scenario guidelines are met.

Miscellaneous Tips

Upgrading from the Microsoft Client

When using the Automatic Client Upgrade (ACU) feature with the Microsoft Client for NetWare Networks or Service for Novell Directory Services, SETUPNW.EXE must be placed in the login script that corresponds with the type of login (bindery or NDS). For example, if you are using the bindery-based Microsoft Client for NetWare Networks, SETUPNW.EXE must be run from the user's bindery login script (located in the SYS:MAIL directory) in order for the Automatic Client Upgrade to work.

Preparing for the Upgrade. The client must have access to a folder where all the installation files are stored. To make this happen, the network administrator needs to do the following:

  1. Create a folder for the Automatic Client Upgrade(for instance, create the directory SYS:PUBLIC\WINNT\ACUINSTL).

  2. Copy all Novell IntranetWare Client for Windows NT installation files into the ACU install folder. This would include all files currently in the client installation package. A good way to obtain these files is to download the NTENU41.EXEfile from the Novell web site and then extract it to create the required files and directories for the install.

  3. Make sure that all clients scheduled for automatic upgrade have Read and File Scan rights to the ACU install folder, by placing the this under the SYS:\PUBLICdirectory.

  4. Update the proper login script.

    a. For a Microsoft NDS Client upgrade, update the container login script for clients using the Microsoft NDS client to reflect the following:

    IF MEMBER OF "NTCLIENTUPGRADE"   THEN BEGIN

      SYS:PUBLIC\WINNT\ACUINSTL\SETUPNW/ACU

/W:TREENAME   END

    b. For a Microsoft Bindery Client upgrade, update the user login script for clients using the Microsoft bindery client to reflect the following:

    SYS:PUBLIC\WINNT\ACUINSTL\SETUPNW

/ACU /W:TREENAME

  5. Verify your work by testing this on a few machines in a lab. It is important to understand that the PC will reboot after the ACU process has completed. This will happen each time a new user logs in to this machine.

Updates to Currently Installed IntranetWare Client for NT

There are times when a network administrator might want to update one or more files without upgrading the entire client. For example, if Novell releases a new version of a file with additional functionality, the supervisor might decide that all clients need to use this file. Because this isn't a new version of the Novell IntranetWare Client for Windows NT, there isn't a client revision number for ACU to check, and the client will not be automatically upgraded. In this case, the supervisor can force the clients to upgrade, using ACU, so that all clients use the newer file.


Troubleshooting?

If you encounter any problems with the IntranetWare Client for WindowsNT, verify that you have followed the instructions in this AppNote. Alsoconsult the SETUPNW.HLP, README.HLP, and ADMSETUP.HLPfiles included with the client software. These help files are installed to thefollowing directory:

[drive:]\<directory install files were unzipped to<\I386\NLS\LANGUAGE

For example,C:\Novell\NTClient\I386\NLS\ENGLISH\

Other help files are copied to the WINNT\HELPdirectory. Thesefiles can be accessed by selecting the Help option from the Start menu.

In the UNATTEND.TXT file used for unattended install (located in the I386\NLS\<language<folder), there are two version parameter numbers:

  • Major Internal Version

  • Minor Internal Version

The version parameters can be any number from 0 through 4,294,967,295. These version numbers are used to decide when the client upgrades. To force the upgrade, the supervisor must make the version number higher than it is when UNATTEND.TXT is first opened (for example, if the number is 0, make it a 1). With this done, ACU compares the version numbers upon client login, finds the discrepancy, and upgrades the client to the system's newer files.

Unlocking a Locked NT Workstation

What do you do if a user decides to lock a workstation and has applications open that cannot be reached? With the IntranetWare Client for Windows NT, an administrator or the current user can unlock the machine with the NDS username and password. When the administrator unlocks a workstation, the logged-in user's applications are terminated and the user is logged out, thereby freeing the workstation to be used by any user who subsequently logs in. Users' opened files are not saved; any changes made since the last save are lost. Access to the logged-in user's desktop is not allowed. Only the user who is logged in to the workstation can unlock the workstation and access the user's desktop, thus being able to save any open files that are currently opened.

Conclusion

Novell's NT Workstation Manager lets you manage all user account information for both the Windows NT and NDS environments. Judicial and knowledgeable use of this tool can help administrators be more efficient and avoid some of the problems often encountered when correct usage isn't properly understood.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates