Planning ahead can be a difficult task for many administrators—partly because most work reactively rather than proactively. When reacting to situations on a continual basis, you have a constant drain on your time. This drain results in not spending the time to figure out a better way of doing things. Reacting to different situations on a constant basis also frequently results in having to spend time figuring out how to do the same task each time you do it because you cannot remember how you did it the last time, which may have been six months ago.

A good way to start planning ahead is to spend a little extra time documenting solutions to problems as you go along. Finding the time for documentation is not always an easy task when you’re moving from crisis to crisis. Remind yourself—and your management—that documenting your solutions ultimately saves you time and saves the company money.

Start small when documenting solutions: Take some notes along the way and refer back to them. When dealing with problems, one of the most critical phases of evaluating the solution is reviewing the situation and what happened between the time the problem was discovered and the time it was resolved.

Documenting changes as they are made is also a good way to save time during the troubleshooting process. By having a record of recent changes made, you may stand a better chance of solving the problem quickly. By documenting changes, you can also start to lay down a framework for standard ways of doing things. Having standards is a good way to meet the second strategy for managing eDirectory: saving time.

By spending a little extra time looking at how certain repetitive tasks are done, you might find ways to reduce the amount of time spent doing them. By shaving a little bit of time off each iteration, you can make yourself more productive—and in many environments, being productive is a key to promotion or to working on other projects.

Let’s take a simple example: starting ConsoleOne. On a 2GHz Celeron-based machine running Windows 2000, when launched locally on the workstation ConsoleOne takes about 45 seconds to start, depending on the number of snap-ins to be loaded and the other applications running on the system. If you need to add a user to a group, that operation can take a minute or two—significantly more time than the startup of the utility.

If you shut down ConsoleOne and have to restart it later to perform another administrative task, you face another repeat of the startup delay. While 45 seconds may not seem like much, it adds up quickly. If you start ConsoleOne an average of 10 times a day, that’s over 35 minutes’ worth of your time just waiting for the utility to start up over the course of a week. That may not seem like much at first, but if you can find a number of places where you can make small changes, the time adds up. Reducing the time you spend performing repetitive—and frequently boring—tasks gives you time to work on projects you want to be working on.

Coming up with standard ways of doing tasks also makes it possible to train others to do repetitive tasks. If you are a programmer, knowing when you can save time by writing a program—as opposed to using standard tools to complete the task at hand—is important. If you know your programming skills can make shorter work of a repetitive task, spend a little extra time writing the program. Using automated tools—even home-grown tools—can help ensure consistency in how tasks are performed and make your network easier to administer.

There is nothing worse for a new administrator than the overwhelming task of learning how to effectively use all the tools available. To know when to use ICE instead of ConsoleOne, for example, you need to know the features of both utilities and be able to ascertain when one utility is better than the other.

You should spend time with the different utilities to learn the strengths and weaknesses of each one. What works for you may not work for someone else, but knowledge always works to your advantage, particularly when you’re trying to save time.

You should look at older tools if they are available. Novell does not provide the DOS-based NETADMIN utility with NetWare 5 and higher, but a NetWare 4.x server on your network would have a copy of it. NETADMIN has its own features that can prove useful in making lots of changes when ICE or UImport cannot be easily applied (for example, when you’re updating console operators on multiple servers or making a quick change to a login script). One limitation of NETADMIN to be aware of is that it does not support extended schema classes and attributes, not to mention some of the newer classes introduced in NetWare 5 and higher, and it definitely does not support auxiliary classes.

You should also spend time with third-party tools. If your company spends money on a management tool, the best return it can get on the investment is realized only if the tool is used effectively.

If possible, you should reuse parts of tools. For example, Chapter 13, “eDirectory Health Checks,” talks about the product bv-Control for NDS eDirectory from BindView Corporation. bv-Control is an extremely powerful tool, but using it fully involves reusing reports that you have created or that are part of the standard reports included with the product. Not having to recreate reports that already exist—or modifying existing reports that almost contain the information you need—saves you time. The only way you can do this, though, is by knowing what comes with the product and organizing your reports so you can find them for reuse later.

Similarly, if you create a data file for a mass user modification with ICE or UImport, you should save the control and data files as well as the tools and scripts you used to create the data files. You never know when they might come in handy—particularly in a disaster-recovery situation.

Knowing your tools also involves knowing shortcuts for certain functions. For instance, when using NetWare Administrator, why would you use the mouse to open the Object menu and select Move when you could simply select the object and press the F7 key to accomplish the same task more quickly? Train yourself to use the shortcut keystrokes instead of using the mouse.

No, we are not talking about the capabilities in your operating system of choice to run more than one program, although we are talking conceptually of a similar way of doing things. Desktop operating systems typically do not do true multitasking; they do what is called task switching. Task switching between multiple computers is what you need to do as an administrator.

Task switching is particularly effective if you use a tool such as bv-Control that can tie up a machine for a significant amount of time (hours to days sometimes, when you’re generating complex reports). Having a separate machine to perform tasks like this can save you time and enable you to work on multiple tasks.

Many administrators benefit from having more than one computer at their disposal. It takes some time to get used to the idea of working on more than one project at a time, and it takes a bit of practice to keep from getting lost. If you can master the skill of task switching, though, you’ll find your job a whole lot easier.

One single-object trick is to create users by using ConsoleOne. As an administrator, you undoubtedly often get requests from managers to create new users that look exactly like other users: “We have a new Accounts Payable clerk named Carl who will be working alongside Jane and needs to access the same information Jane does.” Normally, the administrator creates a new user ID for Carl and then spends time examining the group memberships and security equivalences and looking through the file system to make sure that Carl has the same rights as Jane.

With ConsoleOne’s support for templates, you have a quick way to accomplish this task through the use of a template. To use this shortcut, you start by creating a template object, as shown in Figure 14.1.

FIGURE 14.1 Creating a template object.

As you can see in Figure 14.1, you select to create the template with the Use Template or User option checked. This option enables you to create the template based on the values in another template object or in a user object. You simply create the template based on Jane’s user ID.

Once the template is created, we can then create Carl’s ID using the new template object (AP_template), and we will have granted Carl the same (DS) rights that Jane has without having to take any extra steps.

Earlier in this chapter, we discussed the use of the NetWare 4.x NETADMIN utility, which is not included with NetWare 5 and higher. The NETADMIN utility and the other DOS-based utilities included with some versions of NetWare are some of the most valuable tools for managing an eDirectory tree. The primary reasons these tools are so valuable are the time you save in launching them and the quick access they offer to various standard attributes used in the base class objects in the tree.

Chapter 10 discusses the use of NList and UImport for disaster recovery and building UImport data files using information extracted from DS with NList to rapidly recover from large-scale mistakes. Administration on a large scale is just as effective as disaster recovery. UImport can actually serve as a tool for fast single-object modification as well.

Many people know how to write quick programs in C/C++ or Visual Basic, or even how to use Perl scripts to create and manipulate text files. Rather than learn the NetWare API so you can create or modify users, you can cut a lot of time just by writing a script (using awk, for example) or develop a program to create the data file and use UImport (or ICE or JRBImprt) to make the changes for you. You can even create a single user very rapidly by using UImport, if you have a tool to create a standardized data file for the object creation.

Suppose you have a need to make a quick change to your own personal login script. You could start NETADMIN, locate your object, and maneuver through the different tabs to find the login script. If you followed the advice earlier in this chapter, you probably already have NETADMIN or one of your preferred management utilities running, so you’ve saved some time. You might even have the context your user is in open or use the built-in search feature.

For many people, using the keyboard is more natural and faster than using the mouse. Zipping out to a DOS prompt, using the CX utility (shipped with NetWare) to change to the context your user object is contained in, and starting NETADMIN to make that script change will still be faster than mousing around using a GUI-based application such as NetWare Administrator or ConsoleOne, particularly if you can type quickly.

For most administrators, management of single objects takes more time than any other task they perform. This is the best place to start with trying to find ways to save time by standardizing how you do things. After you standardize single-object management, you can apply the same techniques to multiple-object management.

Unlike other systems, NDS and eDirectory allow for a fairly long name length: The login ID has a maximum distinguished name (DN) length of 256 characters. This means the username and all contexts back to the [Root] context must be fewer than 256 characters. This should be more than adequate for any environment; if it is not adequate for your environment, you need to rethink your naming conventions.

However, in some systems, you or another department might use login names that have different limitations. The AS/400 platform running OS/400, for example, has a maximum login name length of only nine characters. Many Unix/Linux limit you to eight characters. In situations where you want to use the same login ID across platforms—even if the user information is not shared—you want to keep the maximum login name lengths in mind for all operating system platforms concerned.

The next challenge in multiple-object management is to determine a way to handle name clashes. A naming clash occurs when the following occur:

For example, suppose you opt for an eight-character naming convention that uses up to the first seven characters of the last name and the first initial. This would result in the name Jim Henderson generating the login name HendersJ. The name John Henderson, however, would also result in the login name HendersJ.

Resolving this type of name clash ahead of time in your naming convention—particularly if you’re using an automated system—can be difficult. Some companies using this naming convention have opted to use the first six characters of the last name and the first and middle initials. If no middle initial is present, they replace the initial with an uncommon letter—say the letter X. So, Jim Henderson would now become HenderJS, and John Henderson might become HenderJX. If your organization is small enough, this sort of change in the convention might be sufficient.

For larger environments—such as the university environment described earlier in this chapter—the naming scheme just described might not be sufficient. You may want to use some other unique identifier in conjunction with part of the user’s name—for example, the user’s initials and the last four digits of his or her student number; thus, John Henderson’s login ID could end up being JXH1234. In an environment where thousands of users are being created at a time, you do not want to tie the user’s name to an arbitrary value. Such a value could be referred to as an “instance number”—the first user being JXH01, the second being JXH02, and so on. Automating the creation of accounts in this manner can become quite complex fairly quickly, depending on the type of constraints you face. The idea is to use the data provided to create a unique key to be used as the user login name.

In smaller environments, it may be sufficient to use first name and last initial or the user’s first name or nickname.

Choosing a way to resolve name clashes very much depends on your environment and the politics involved. Whatever method you choose to handle it, you should always keep in mind that you may run into a clash, so you should decide ahead of time how you want to handle it.

Chapter 15, “Effectively Setting Up eDirectory Security,” discusses the need to keep administrative accounts separate from non-administrative accounts. Administrative accounts, by their very nature, have the capability to make changes that you may not want to a network during normal operation. For example, an administrative user might be able to make changes to default templates used by the Microsoft Office product suite or, worse, could accidentally delete part of a critical application.

The best solution to this is to create a separate non-administrative account for each user who has administrative authority. That way, these users can perform normal operational tasks such as preparing status reports and project plans by using the non-administrative account, without any risk to the software installations. Their administrative IDs should be used only for administrative tasks, such as creating users. This also gives you the ability to restrict a user’s rights if he or she leaves your information systems department (or at least leaves the role where he or she performed administrative tasks). You can simply disable the administrative account and modify the user’s non-administrative account to fit his or her new job role.

Using a separate non-administrative account for each user who has administrative authority works very well if the administrative staff has more than one computer to work on.

Administrative accounts should be named such that they are easy to identify at a glance—possibly as obviously as using a user’s regular user ID with a special modifier to show the administrative account. Such an identifier could be something obvious, such as the suffix _Admin (making John Henderson’s administrative account JXH1234_Admin), but something a little subtler might be called for if your environment is likely to have people attempting to hack into the system. Making the administrative accounts easy for anyone to identify removes a barrier to someone attempting to break into your system.

One variation of using a suffix on the account is to use a different middle initial—say Q—for the user. Searching for administrative accounts that are logged in then becomes a simple matter of searching for all accounts with a middle initial Q.

One other variation is to create two non-admin users and two admin users (other than Admin) and scatter them throughout the tree. This might seem like overkill, but if someone either tries to hack the tree or mistakenly creates a destructive policy with ZENworks, for instance, you always have at least one admin and one non-admin user that you can call on to copy a profile from or to log in without using a script, in order to bypass any issues.

ConsoleOne (and NetWare Administrator, too) has the capability to perform modifications on multiple User objects; the newer versions of ConsoleOne can also modify multiple non-user objects. To use this feature, you select multiple user objects while holding down the Ctrl key. Then you select either Object, Properties of Multiple Objects (it is called Details of Multiple Users in NetWare Administrator) or right-click the selected objects and then select Properties of Multiple Objects from the context menu. This brings up the dialog box shown in Figure 14.2.

FIGURE 14.2 Viewing password restriction details about multiple users.

As you can see in Figure 14.2, the dialog box looks nearly identical to the dialog box for a single-object modification. The primary difference is that in this case, you have the ability to set the values for multiple users or to leave values alone.

This particular method of changing multiple users is easy to use, but it can also create problems if it is not used properly. For example, if you change user group memberships on a large scale, the result is that the user group membership lists are the same, rather than just having the desired group memberships being added. A better approach in this case is to add multiple users to the group from the group perspective or to use UImport, ICE, or JRBImprt to make this type of mass change.

There are two types of guidelines you should follow when managing eDirectory. The first type of guideline, of course, is the eDirectory implementation guidelines published by Novell (for instance, the amount of disk space and RAM required for the server as well as the number of objects per container or partition). The hardware guidelines are there to help you to establish the minimum requirement, which means you should not only meet them but also exceed them.

Prior to NDS 8, the Novell-recommended number of objects per partition was a good rule of thumb to follow. However, with the advent of eDirectory, the limitation on the number of objects has practically been removed. The constraint now is mostly posed by the management utilities, such as ConsoleOne: The amount of time the utility will take to read and display the objects from a given container becomes a governing factor on how many objects you put in a container. Therefore, depending on your particular application requirement and your own patience (and this goes back to the earlier discussion in this chapter about saving time), you have to make a judgment call on the number of objects per container/partition, but you should use the Novell numbers as a guideline.

The second type of guideline you should follow when managing eDirectory has to do with procedures. You need to have a written set of rules and checklists for performing management tasks. The rules help identify how certain tasks should be done. For instance, there should be a rule that when a user calls the help desk to have his or her password reset, additional confirmation needs to be asked of and verified from the user. Otherwise, it would be easy for someone to impersonate a user, call the help desk to have the password changed, and gain unauthorized access to sensitive company information.

You should have step-by-step checklists and data forms for performing nontrivial management tasks. For example, you should have a list of steps to take when creating a new user account. The data form may look like this:

Having a form like this helps to ensure that all the required information is associated with the user object and that the required file system rights are properly assigned (through association of group memberships, for example). The most important items are the ID expiration date (in case the user is a seasonal appointment, such as a summer student) and the authorization signature of the user’s manager.

Every company (and even different divisions within the same company) works differently. Having written rules and procedures helps new staff members to quickly learn what is expected of them and can dramatically reduce the learning curve. Also, having these rules and procedures in writing makes it easier to spot errors and to make improvements.

When creating data files for a mass import, regardless of whether you are using the files for a single object or multiple objects, you should have a standardized way of mapping fields from one file to another. For example, if the new user information you receive contains the full name (consisting of the first and last name of each user), middle initial, employee number, and telephone extension for each user, you should ensure that the data is always presented in a consistent way in the data file. For instance, the fields should always appear in the same order in the data file, perhaps in the same order as the information that you are provided with, to make cross-checking between the two lists easier.

Also, you should ensure that your data conversion program performs the conversions in a consistent manner. Regardless of the programming language you use—or if you use something like Excel to generate the data from another spreadsheet—you need to ensure that the conversion process handles exceptions such as commas in the data fields and the use of special characters.

When using UImport (or ICE or JRBImprt) to create new user objects, you have the option of setting the initial password for the user. The initial password should be fairly easy to remember but should also have a requirement to be changed when the user first logs in. Creating long initial passwords can be difficult to manage; you have to remember that not all platforms support long passwords the way DS does. Whereas DS’s password algorithm enables a maximum password length of 128 characters, Windows platforms typically enable 15 characters.

Another standard to consider is the default rights given to the user for his or her home directory. Depending on which utility is used for creating the accounts, you will have different rights granted to the home directory.

If you use a batch procedure to create the accounts, you can use the RIGHTS.EXE program (shipped with NetWare) to set the default rights to what you want them to be. Many administrators prefer that users not be able to grant rights to other users for their home directory; unfortunately, creation with many utilities grants the user Access Control rights for the user to his or her home directory, thus allowing the user to grant trustee rights to other users.

In addition, disk space management is also important: If your environment permits, you should set space restrictions on the home directories and shared data directories. This will save you problems down the road when space starts to get a little thin.

As a rule of thumb, you should create user home directories on a volume other than the SYS: volume. On NetWare, DS uses the SYS: volume exclusively, and if that volume fills up and you have home directories on it, you will run into synchronization problems that will be compounded by not being able to attach to the server to delete unnecessary files from the volume.

When partitioning a DS tree, you need to use common sense and try to keep partitions from crossing multiple WAN links. Part of the reason for partitioning a tree is to cut down on traffic over the WAN. If you have only two sites, however, partitioning does not make a lot of sense because you still want to maintain three to five copies of each partition in an ideal fault-tolerance setup. If you have only two servers, you should leave just a single partition and keep two copies of the DS replicas.

When removing replicas from a NetWare server, you might receive the following error message:

The way to fix this problem is to decrease the maximum number of transactions by using the SET MAXIMUM TRANSACTIONS console parameter. The default for this parameter is 10,000, but for systems with smaller amounts of memory, this can cause a problem. Decreasing the maximum number of transactions causes the Transaction Tracking System (TTS) backout file to grow more because the transactions are queued, but the server will not run out of memory while trying to process the transactions.

With regard to your SYS: volume’s free space on a NetWare server, there are frequently several categories of files on the SYS: volume that you can delete to free up space. These include the following:

By deleting these files, you can get by with a smaller SYS: volume or at least free up space for larger NDS partitioning and replication operations where the extra disk space would be of use.