Novell is now a part of Micro Focus

How to Perform a Health Check of Novell Account Management 2.1 for Windows NT

Articles and Tips: article

Patrice Clement
Major Account Support Engineer
Novell Technical Support
pclement@novell.com

01 Aug 2002


Because it integrates two completely different architectures from two different manufacturers (Microsoft's NT Domains and Novell's eDirectory), Novell Account Management (NAM) 2.1 for Windows NT can prove challenging to troubleshoot. However, the way NAM 2.1 for Windows NT works (redirection) is very simple. Once you understand its basic principles, the steps needed to perform a health check become logical and easy to understand. These steps are detailed in this AppNote.


Topics

eDirectory, user account management, NT Domains

Products

Novell Account Management 2.1 for Windows NT

Audience

network administrators, support technicians

Level

intermediate

Prerequisite Skills

familiarity with eDirectory, NT Domains, and NAM 2.1

Operating System

Windows NT 4.0

Tools

NDS4NT Toolbox

Sample Code

no

Introduction

One of the main challenges when troubleshooting Novell Account Management (NAM) 2.1 for Windows NT is to avoid confusion arising from the interaction of its different components. When some users complain about slow login to the NT Domain, how do you know whether the problem is coming from the redirection component, eDirectory, or the NT Domain itself? How do you know where to look for relevant information about the problem? The best approach is to use a checklist to verify point-by-point that everything is configured properly. Several years of experience doing technical support for Novell Account Management for Windows NT revealed that, in the vast majority of cases, checking a few things made it possible to find out what was wrong and to solve the problem.

This AppNote lists the main checkpoints to look at when troubleshooting NAM for Windows NT. For each of these checkpoints, an explanation will be given on why it is important, how you can check it, what are the likely symptoms that you will see in case of a problem related to that checkpoint, and, in that case, how you can resolve it.

This AppNote focuses on version 2.1 of Novell Account Management for Windows NT. However, most of the procedures detailed herein can also be used for previous versions of the product (NDS Corporate Edition and NDS for NT 2.0x).

Understanding the Components of NAM for Windows NT

Before starting a health check of NAM for Windows NT, it is very important to understand the role of its different components. There are mainly two separate components within NAM for Windows NT:

  • SAMSRV.DLL, which provides redirection of the NT Domain into eDirectory

  • DHOST.EXE, which is the eDirectory replica on the NT Server

Although these two components are included with NAM for Windows NT, they are actually independent from each other. This means that, depending on your environment, you will have one of three possible configurations:

  • Redirection only

  • eDirectory replica only

  • Redirection and eDirectory replica

Typically, you will have the first configuration (redirection only) when you have an NT Domain Controller located on the same LAN segment as the NetWare servers holding a replica of the partition where the NT Domain object is located. On the other hand, if the NT Domain Controller is separated from the NetWare servers by a WAN connection, or if there are no NetWare servers in your environment, you will typically be using the third configuration (redirection and eDirectory replica). Lastly, you might want to add eDirectory replicas on some NT servers for additional fault tolerance (Novell recommends a minimum of three replicas of each partition).

This AppNote will focus on troubleshooting the redirection component of NAM for Windows NT. As for eDirectory itself, the health check procedures are pretty much independent of the platform on which eDirectory is located. For more information on how to perform such a health check for eDirectory, see "Health Check Procedures for NDS eDirectory on Supported Platforms" in the May 2001 issue of Novell AppNotes (located online at http://support.novell.com/techcenter/articles/ana20010503.html).

Performing a Health Check

In order to perform a full health check of Novell Account Management for Windows NT, the following checks must be performed:

  • Checking the SAMSRV.DLL

  • Checking the Novell Client versions

  • Checking the name resolution configuration

  • Checking the eDirectory versions

  • Checking the eDirectory synchronization

  • Checking the Revision Count attributes

  • Checking the rights of the Domain object

  • Checking the Built-In Administrator

  • Checking for duplicates

A number of these health check procedures rely on the NDS4NT Toolbox utility. This utility provides a convenient way of accessing most of the relevant information needed when performing a health check of NAM for Windows NT. You can download this utility from the Novell Downloads Web site. To find it, go to http://download.novell.com/ and do a search on the NDS4NTTB.EXE filename in the Product Update section. This will allow you to find the most recent version of the utility. As of this writing, the current version is 1.3c. The Toolbox is a Windows application that you run on the NT Domain Controllers.

Checking the SAMSRV.DLL

This is one of the easiest, yet most important, things to check when assessing the health of NAM for Windows NT. You need to verify that you are running the most recent version of SAMSRV.DLL. You also need to make sure you are running the same version of SAMSRV.DLL on all the Domain Controllers of the Domain being redirected. Last but not least, you need to check that all the Domain Controllers (of the Domain being redirected) are running the Novell SAMSRV.DLL and not the Microsoft SAMSRV.DLL. This can easily be checked by looking at the properties of the SAMSRV.DLL file located in the SYSTEM32 directory (see Figure 1).

Checking the version and manufacturer of SAMSRV.DLL.

If you still have some Domain Controllers running the Microsoft SAMSRV.DLL, you will need to first install NAM for Windows NT on those Domain Controllers and then update the Novell SAMSRV.DLL to the most current version.

To find the most current version of SAMSRV.DLL, go to the Novell Support Web site's Product Update section and search for the SAMSRV.DLL file. As of this writing, the most current version of SAMSRV.DLL for NAM 2.1 for Windows NT can be found in the AM210PT2.EXE patch.

Symptoms of problems caused by incorrect versions of SAMSRV.DLL can range from performance issues to domain synchronization issues to inconsistency problems (for example, sometimes a user can log in and other times the same user cannot log in). This simple check is easily the most important check to do and can solve a wide range of problems.

Checking the Novell Client Versions

Another simple check to do is to verify the version of the Novell Client running on the Domain Controllers. For NAM 2.1 for Windows NT, the recommended version is Novell Client 4.81 for Windows NT (or higher). Also make sure that you are running the same client version on all the Domain Controllers.

Some symptoms of problems caused by an outdated client version are that Domain Controllers might "freeze". Due to some memory leak problems in older clients that are now fixed, it could happen that with older client versions the Domain Controllers would hang after a few days of operation.

Checking the Name Resolution Configuration

For NAM for Windows NT to function properly, it is important for SAMSRV.DLL to be able to quickly locate a server hosting a real copy of the Domain object. This process is mainly controlled by the name resolution configuration of the Novell Client running on the Domain Controllers. In an IPX environment, this is not really an issue since the Novell Client uses the Service Advertising Protocol (SAP) to quickly locate a server with a copy of the Domain object. In an IP environment however, the fastest name resolution method is DNS.

By default, the Novell Client will first try DNS when locating a service before trying other methods such as Service Location Protocol (SLP) and Novell Directory Services (NDS). This is why, in an IP environment, it is recommended to provide DNS name resolution for the Novell Clients running on the Domain Controllers. This can be done by configuring a DNS server with the tree name and the IP address of a server hosting a real copy of the Domain object. The other possibility is to use the HOSTS file of the Domain Controllers. While this is more difficult to maintain, it allows a finer level of control. For example, making sure that the tree name entry in the host file is pointing to a server with a copy of the Domain object which is local to the Domain Controllers will avoid unnecessary traffic over WAN links.

A typical symptom of a problem that can occur when name resolution is not working is Event 5 being generated by NWSAM in the System Log (see Figure 2).

Event 5 error generated by NWSAM in the system log.

This error occurs when SAMSRV.DLL is unable to locate a server hosting a replica of the partition where the Domain object is located. Figure 3 shows the Event Detail window for this error.

Event Detail information for Event 5 error.

Checking the eDirectory Versions

Make sure that your NDS/eDirectory versions are up-to-date. Also make sure that you are not mixing different versions of the same NDS/eDirectory "generation." In other words, make sure you are running the same 6.x, 7.x, 8.x, or 85.x versions of NDS/eDirectory everywhere. Do not mix different versions of an NDS/ eDirectory generation. For example, do not mix several versions of eDirectory 8.5 (for example, 85.12a, 85.20c, and 85.23) in the same tree. Make sure that all your eDirectory 8.5 servers are running the same up-to-date version of eDirectory 8.5. It is okay to have different generations of NDS/eDirectory in the same tree as long as you are running up-to-date versions of each generation.

A typical problem that can occur when running outdated versions of NDS/ eDirectory is out of synch Revision Counts. See the section "Checking the Revision Count Attributes" for more information about this problem.

Checking the eDirectory Synchronization

As Novell Account Management relies heavily on eDirectory, it is important to ensure that eDirectory is healthy and synchronizing properly. A discussion of eDirectory health check procedures is beyond the scope of this AppNote. For in-depth information, refer to "Health Check Procedures for NDS eDirectory on Supported Platforms" in the May 2001 issue of AppNotes.

In addition to that, the NDS4NT ToolBox can allow you to quickly verify that all replicas of the partition where the Domain object is residing contain the same number of domain members. While such a check does not replace a normal eDirectory health check, finding out a difference there would clearly indicate a problem. From the NDS4NT ToolBox, select the "NDS Tools" option and then "IWS:Member". This will open a window in which the number of members of the Domain is calculated on each replica (see Figure 4). These numbers must be the same on each replica.

Checking that IWS:Member numbers are the same for all replicas.

If you find differences, apply standard eDirectory troubleshooting procedures. Such a problem would be an eDirectory-related problem, not a Novell Account Management problem.

A typical symptom of an eDirectory synchronization problem would be that a user can sometimes log in without a problem but other times cannot log in at all, depending on which replica the SAMSRV.DLL is contacting.

Checking the Revision Count Attributes

The Revision Count is an attribute of every object in the NDS database. This attribute is incremented whenever the object is modified. NAM for Windows NT uses the Revision Count attribute of the Domain object and the Domain Users object to determine whether the domain information which has been cached locally is still accurate or not. For this process to work properly, it is critical that the Revision Count attributes be in synch on all replicas of the partition where the Domain object is located. You can easily check this by running the NDS4NT Toolbox utility and choosing the "NDS Tools" and "Revision" options (see Figure 5).

Checking the Revision Count attributes for all replicas.

Note: If you see only a small difference between the Revision Counts, it could be due to the fact that NDS/eDirectory has not yet synchronized the latest modifications to all the replicas. In that case, wait a few minutes and check again to see whether the Revision Counts are then in synch.

If the two revision counts (Domain and Domain Users) listed by the NDS4NT Toolbox utility are not in synch, you can try to remove the replica where it is not in synch and then add it back (allow enough time between the two operations for NDS/eDirectory to synchronize).

If it is not practical to remove and replace the replica to solve this problem (for example, when the Revision Count attributes are out of synch on all the replicas), you will have to open a support incident with Novell Technical Support to have a Novell engineer dial in to your tree to fix the problem. Before opening such an incident, make sure that you have checked all the other points listed in this AppNote (especially the ones in the "Checking the SAMSRV.DLL", "Checking the Novell Client Versions", and "Checking the eDirectory Versions" sections). Failure to do so could cause the Revision Counts to go out of synch again after the dial-in fix.

A typical symptom of a problem caused by out of synch Revision Counts is a very slow NT Domain: for example, the login to the NT Domain is very slow or it takes an unusually long time for the "User Manager for Domains" utility to display the list of users.

Checking the Rights of the Domain Object

The SAMSRV.DLL logs in to the eDirectory tree as the Domain object. This means that the Domain object must have enough NDS rights to allow the modification, creation, and deletion of various objects (such as users, local groups, global groups, and computers). During the installation, the Domain object is by default made a trustee (with Supervisor rights) of the Organizational Unit (OU) where it is located, as well as the OU you selected as being the OU where new users would be created by default. This "Default User Creation Context" parameter can be seen (and changed) on the properties page of the Domain object, as shown in Figure 6.

Checking the "Default User Creation Context" parameter for a Domain object.

It is important to verify that those rights have been assigned properly and that they have not been removed. An easy way to check this is to use the NDS4NT ToolBox utility and select "NDS Tools", "Users", and then "Rights". This option will verify that the Domain object has enough rights to all the related User objects (see Figure 7).

Message verifying that the Domain object has sufficient rights.

In case you get an error, make sure the Domain object is a trustee with Supervisor rights of its own OU as well as the "Default User Creation Context" OU.

A typical symptom of a problem caused by insufficient rights is the impossibility for the SAMSRV.DLL to synchronize accounts created or modified in the "User Manager for Domains" utility with eDirectory.

Checking the Built-In Administrator

In an NT Domain, the Administrator account is special. Some operations require this special account; without it, the operation will fail. That's why the "User Manager for Domains" utility will not allow you to delete the Built-In Administrator and Guest accounts. If you attempt it, you'll see the message shown in Figure 8.

Error received when attempting to delete user Administrator.

On the other hand, once the Domain is redirected in eDirectory, nothing prevents you from deleting such a built-in account from ConsoleOne (since, from eDirectory's point of view, nothing distinguishes these "built-in" accounts from the other accounts). If you do accidentally delete the Built-In Administrator and need it back, just recreating an account in the NT Domain with the name Administrator and the necessary privileges will not be enough. What sets apart built-in accounts from "normal" accounts is their corresponding RID number. Indeed, the Built-In Administrator account always has an RID of 1F4, while the Built-In Guest account always has an RID of 1F5.

With the NDS4NT ToolBox, you can easily verify that the Built-In Administrator account has not been deleted. To do this, select the "NT Tools" and "Built-in Admin" options. This will check whether there is still a user member of the NT Domain whose RID is 1F4. If it cannot find one, you will get the warning message shown in Figure 9.

Warning message if built-in Administrator is not found.

To solve this problem, you will first need to create a new account (the name does not have to be "Administrator", but to avoid confusion, it might be better to name it that) and make that account member of the Domain Admins group. Make sure you set the "Primary Group" as being the Domain Admins group. Then, go into the NDS4NT ToolBox utility. Choose the "NDS Tools" and "Users" options. There, select the user you just created and click on the "restore Admin" button. This will change the RID of that account to the Built-In Administrator RID of 0x000001F4 (see Figure 10).

Message confirming successful creation of a new built-in Administrator.

Keep in mind that file access rights under NT are linked to the RID and not to the account name. That's why you should create a new account to restore the Built-In Administrator instead of using an existing account. Indeed, if you use an existing account, you might lose access to some files or directories because the RID has been changed.

A typical symptom of problems caused by a missing Built-In Administrator account is that some operations will fail with an error message that you do not have sufficient rights, even you are member of the Administrator group. For example, adding a new Backup Domain Controller to the Domain requires you to log in as the Built-In Administrator of that Domain.

Checking for Duplicates

The NT Domain is flat database; there cannot be two users with the same name within the Domain. On the other hand, eDirectory is a hierarchical database. It is possible for two users with the same name to exist in the same tree as long as they are located in different contexts. Furthermore, eDirectory is a "multi-master" database (meaning that any server can make changes to the database), while the NT Domain is a "master-slave" database (meaning that only the Primary Domain Controller can make changes to the database). Redirecting a NT Domain into eDirectory transforms it into a multi-master database. It is then also possible to make changes through the Backup Domain Controllers.

With the earlier versions of NAM, the creation of a duplicate user name was allowed in the NT Domain. This issue has been addressed in version 2.1 of Novell Account Management for Windows NT. To check if you have duplicates within the NT Domain, you can use the NDS4NT ToolBox utility. Choose the "NT Tools", then "Duplicates" option. This will verify whether or not there are duplicates in the NT Domain. If not, you'll see the message shown in Figure 11.

Message verifying there are no duplicates in a Domain.

Conclusion

Following the checklist in this AppNote to perform a regular health check of your NT Domains redirected into eDirectory through Novell Account Management for Windows NT will allow you to avoid most, if not all, of the potential problems related to the use of this product. In addition, these health check procedures will also ensure that NAM for Windows NT is configured for optimum performance.

Performing these health check procedures does not mean that you should overlook the standard NT Domain health check procedures. For example, you should check the Event Log of the Domain Controllers on a regular basis to verify that no errors occurred during the booting of the server or that no errors related to the Domain are happening.

Following these procedures will allow you to be much more proactive and address potential problems before they become critical, or even before they start affecting your users.

* 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