Now that your Windows NT Server is up and functioning perfectly, it is time to get into the topic of administration. I like to think of this chapter as the "care and feeding" of your new server. It requires a number of skills that go above and
beyond those needed for the installation process (for example, time management). This chapter also covers those subjects that take a fully functional operating system and turn it into a productive server environment.
I have taken a divide-and-conquer approach in this chapter. After presenting an overview discussion of system administration, I go into each of the specialty areas. You may or may not use some of these specialty areas. For example, remote access to your
server may be completely forbidden by your local security policies, or it may be the sole reason that this particular server was installed. Also, there are so many possible uses for your server (and therefore so many possible administrative topics), I had
to limit my discussion to those that I thought were most likely to be needed by a wide range of administrators. Also, the administration of each of the other BackOffice components is discussed in a chapter located in the appropriate section of the book.
The topics that I chose for this chapter include the following:
Ongoing system administration can be as much of a challenge as the initial server installation. It is not usually as much of a technical challenge. After you have all of those drivers working, things tend to stay working well (at least until the next
upgrade). However, I find that it is usually harder to get the time to keep up with user accounts and disk-drive utilization than it is to allocate that day or two it takes for the special project of installing a new server. Also, it can be quite a
challenge to find the time to perform system maintenance after it goes into production. Most users, I have found, become quite dependent on their computer systems and do not want to live without them for a few hours while you rearrange files on disks or
perform hardware upgrades. Most administrators do not like the idea of having to work in the middle of the night (in addition to their normal work day) to get these maintenance tasks accomplished.
So there are challenges to system administration that go far beyond the standard technical competencies. You have to work to solve these problems based on your individual situation. What I can do in this chapter is offer discussions on the technical,
Windows NT tasks that the administrator needs to perform to keep servers working properly. These tasks are actually a combination of technical knowledge, planning, and policy making that comes together to form a workable system of doing business.
The unfortunate thing is that I cannot offer one simple task list and schedule for every administrator. Windows NT is a flexible operating system that is designed to meet a number of needs and work in a number of environments. I have sketched out just a
few ideas on environments in Figure 11.1. You need to keep in mind the overall system goals when you are planning your administrative routine. For example, security may be a trivial concern or a matter of national security for your server. Also, certain
production environments cannot ever lose a scrap of data, whereas other environments would prefer to avoid losing data but cannot afford mirrored disk drives or other reliability-enhancement technologies.
FIGURE 11.1. Different administrative environments.
Ideally, some of the administrative requirements were factored into the overall system design. This usually happens when you have experienced system administrators participating in the overall system design. However, you may find that others have
designed a system lacking, for example, a tape drive (or have installed a very low-capacity tape drive on a server with a lot of disk storage in order to save money). At any rate, you have to review your environment against your administrative needs.
Sometimes you have to adapt your administrative procedures (for example, back up data to writable CD drives) or adapt your system configuration (get that high capacity tape drive) to enable you to accomplish your goals. Ideally, you have had the chance to
read this chapter and plan out your administrative tasks before the system configuration was completed. If not, perhaps you have some additional budget for the little extras that you think of while reading this chapter.
As I go through the tasks, you will note a large number of things that need to get done, and it may seem overwhelming. This is especially true if you are just a part-time NT administrator who has another main job (engineer, for example) that is supposed
to be your primary focus in life. There are two components that you have to balance to fit your administrative tasks within the available time. The first is that you have to select which tasks you are going to perform. Some things may not be that important
in your environment, and therefore you may not have to perform them. Perhaps there is another person or group who will do that job for you. The other option, though, would be not to completely ignore a given task, but to alter how often you do it. For
example, if you are working on a system that has plenty of disk space and the users do not use the system for a lot of data storage (that is, they are accessing some relatively small Web pages that do not grow radically over time), you might perform
capacity-planning tasks only every six months or even annually. The key here is to ensure that everyone understands what they are getting when it comes to service so that they do not get upset if they have to wait for something to get done. Another key is
that if other people or groups are performing some of the common administrative tasks, it is important to ensure that both your users and those other people are clear as to the assignments.
???Author: Perhaps add a sentence about checking the event log regularly for the `heads-up` on any unusual errors/notices.. - BH
I wanted to emphasize the setting of levels of service. I do cover the event log checking later in the chapter.-- Joe
Chapter 5, "Administrative Environment," went over most of the tools that will be used to accomplish the tasks discussed in this chapter. Please refer to that chapter if you wish to refresh yourself on the details such
as which pull-down menu enables you to activate a particular needed function. This chapter focuses more on figuring out what needs to get done. You can then use the tools provided in Windows NT to actually get the job done.
One final note about tools and tasks. You may choose to extend the tools provided with Windows NT, or you may wish to use alternative management tool sets. There are a number of third-party vendors who provide management tools for Windowsmuch written
about them. The tools that come with the operating system are fairly complete and work well. I have, on occasion, automated certain repetitive tasks with a series of batch files. I will discuss this later in this chapter, but the basic concept is that you
can build scripts that use the basic NT tools in a fixed combination. They can be run either from the command line or through tools such as the Remote Command Server provided in the Windows NT Resource Kit. Again, I have a section on scripting coming up in
just a little bit.
???Author: Would probably remove the `, although I have not used them or found much written about them`. They are out there and are advertised and sold with documentation... -BH
See redlines.-- Joe
Why spend a long time in the overview section? There are a number of practical tasks to discuss in the sections that follow. That is where you will find the real value in this section. I inserted this section merely to focus your attention on a few
issues that you should keep in mind as you are working through the following sections.
User administration is one of the strengths of the Windows NT operating system, especially under version 4.0. It is easy to work with, and you have a powerful, graphical tool in the User Manager tool (see Figure 11.2) to get the job done. Version 4.0 is
an improvement on the 3.51 release in that Microsoft has enabled you to access those few user administration functions (for example, remote access setup for users) from the User Manager tool. It is now pretty much the one place you have to go and the one
tool you have to learn to keep your user accounts properly configured.
FIGURE 11.2. The User Manager tool.
The first issue that you have to deal with regarding user administration was actually decided for you when you installed your Windows NT Server operating system. That issue is whether you are operating as part of a workgroup or domain. Again, I
recommend the domain option for BackOffice users because several products (for example, Exchange Server) are configured to work only in the domain environment. It does not cost extra to be a domain as opposed to a workgroup (both sets of software come as
part of NT), and your clients can deal with both systems of government equally well. The key is that the domain environment has a number of security enhancements that BackOffice developers wanted to take advantage of when implementing their products. Their
decision can force you to make your decisions towards domains also.
So what does this domain environment mean to the average, overworked system administrator out there in the field? If you have more than one server, it means that it will usually reduce the amount of work you have to do. It also means that if you are
used to workgroups, you will have to spend a little bit of time learning about and getting used to the domain environment. It took me only a day or so to adapt to this environment, so you should have little trouble doing it. The only real recommendation
that I would put forward is to have a backup domain controller if at all possible. This ensures that people can log on to the network even if your primary domain controller is down for maintenance.
In line with this, I always recommend at least a basic Uninterruptible Power Supply (UPS) for your servers. There are expensive ones that can keep you going for days in the event of a power failure, but you can also get some very simple units good
enough to keep your system from going down in the event of short outages (such as those that are common with lightening strikes). Windows NT does a number of fancy things with disk drives and memory to improve performance. It may take you some time to
recover if your system goes down with even a brief power outage and NT has to clean up the files that it was working with when the power went out. These basic units sell for under $100, although you might consider a bigger unit if you want to remain
operational during extended power outages. Remember to consider UPS devices for your network equipment also (I have seen servers that are functioning well, but no one can get to them without a network).user administration.
???Author: The by-the-way nature of the previous paragraph suggests making it a note. If not, I suggest deleting the last sentence. -David
See redlines.-- Joe
Your decision on domain versus workgroup will determine whether you have to create user accounts on each server (workgroup) or create one account for each user that is valid throughout the domain. The domain security system is really quite good. Do not
decide to use workgroups just because you feel someone will hack their way through NT security and access information they are not supposed to on a server if they have an account that is valid on it. NT gains a lot of security by enabling you to prevent
people from having access to the command line or main GUI interface on the remote computer. Instead, you have resources accessed through common utilities that enforce security.
If you have decided on the domain architecture, you next need to consider setting up trust relationships between domains. If you do not have connectivity to other domains, you can skip this step. However, if there are other domains, you should at least
consider setting up a global group on your computer that matches those set up from the other domains. Again, you have to coordinate the trust relationships with the other domain administrators, because a two-way permission grant is needed to make a trust
relationship work. After you have the trust relationships and global groups set up, you have a way to control access by these outsiders into the resources of your system.
The next issue that you have to deal with is establishing your user groups. Unless you are working on an extremely small server, it is impractical to grant all accesses on a user-by-user basis. It becomes even more difficult to try and remove selective
accesses if the user changes jobs. What you must plan out now is which groups make sense for your environment. This comes from an analysis of who will be given access to different types of information. You look for patterns in this permission scheme (for
example, every user has access to some things, all accountants have access to others), and you make a group to represent each of these patterns. You can make changes to group membership easily over time, but changing your group structure can be quite time
consuming later on. It is worth a little extra effort up front to at least get close to the ultimate group structure for your environment. Also, note that grouping applies just as much to workgroups and it does to domains. If you use workgroups, it might
be a whole lot easier for you to at least keep your group names straight across your various servers. It would be a real pain to have to remember that a group is called HR on one server and HumanRes on another.
An important point to keep in mind is that you can still give individual permission grants on top of this group structure. The group structure is designed to make the bulk of your permission grants easier. It is all right if you have a few special users
who need special privileges that are granted on an individual basis. For example, say you have a large number of users who need access to a common corporate-policies directory. You could grant read access to the general users group and then assign all
users to that group. They all have access to that directory for read purposes. Someone has to maintain that directory, though. Perhaps you have two people in human resources who are allowed to change policies. You can give change permissions to these two
accounts individually, and you are done.
One thing that can be useful in larger systems is a map of your groups to hang up on your wall. I have included Figure 11.3 to stimulate your thoughts. You can arrange groups from top to bottom, in order of who has the most privileges, and from left to
right, corresponding to your various departments. You could also pick another arrangement scheme that matches your own way of thinking. The key is that having this map, even if it is hand drawn on the back of an old printout, can help you see the security
scheme in a visual format. It also comes in handy when you are on vacation and someone has to fill in for you who does not instinctively understand the way you think.
FIGURE 11.3. A sample of group mapping.
You now have buckets in which to place your users. What does that mean to them? Actually, very little until you start sharing some resources on the network that they want to have access to. They rarely appreciate computers for their technical or
artistic merit. You now need to come up with some names for your resources. I have seen a number of different resources and system-naming conventions, ranging from planets visited by the original "Star Trek" television series to detailed naming
conventions that show location, equipment version, and other technical details. The key is having names that convey what the resource is and give the user enough information to actually use it.
First, a few thoughts on conveying what the resource is as part of the name. In small shops, in which everyone knows that the only printer is an HP Laserjet 3si, you can come up with a simple, cute name that everyone can remember. However, if you have a
vast network of printers (some color, some duplex, and so on), it can be difficult for people to remember that Babel is the duplex and Deneb is the color printer. Therefore, you might want to come up with names such as Duplex or Color. If you have a
network with multiple printers on each floor, you might consider adding a floor or department designator to the name (for example, 3Color or MktgColor). Remember, they do not have to type in a long resource name under the NT environment. Instead, they pick
the resource from a list of resources. You can go a little bit longer with the resource name unless you have some old DOS workstations (where the share-name limit is 8 characters). Otherwise, you are free to convey much more information to your users.
???Author: Probably one of the most important necessities which is not adhered to or given enough weight is the design of naming conventions. Corporations (IS/Network groups) need to sit down and come up wiht naming conventions for everything from router ports to servers to network printers to shared drives. Once done and documented, this list becomes invaluable for both adding future components and referencing existing components. The name can be a combination of several informatory items (ie. NT_LA_APP_01 for NT application server 1 in LA). Sometimes the name needs to be broken out by corporate group (ACCT, IS, MGT, FIN) etc.. Whatever the breakout - a solid convention that is documented and adhered to (and where the current active list is always available) is both invaluable and impressive. - BH
See redlines which reference the points that I made in chapter 9.-- Joe
FIGURE 11.4. A sample resource diagram.
The final step is mapping access privileges for resources to groups and users. This could be a very generous scheme, for those places that believe everyone should have access to knowledge, or a very stingy scheme, in places where data
security is important. You will have to decide what those rules are, but I thought that I would leave you with Figure 11.5 as an example of a tool that can help you to keep these access grants straight.
FIGURE 11.5. A resource access table.
So much for theories of user management. An example of this process for a mystical small group of users might be useful. This small group needs to access several common directories and one of two printers (based on their location). They have not wanted
the printer in the other location to be available to users ever since the day one user sent a huge print job to the wrong location when a manager wanted to get out a big proposal.
You have configured all workstations to be members of the BrandX domain. Your analysis indicates the need for the following groups:
You add these groups to your domain configuration using the User Manager tool, as shown in Figure 11.6. Obviously, larger networks would have a larger number of groups. Typical reasons to classify employees into various groups include projects worked
on, job title within the company, or group that you work in. The scheme presented here reflects a knowledge of the organization of BrandX and what the Windows NT servers are going to be used for.
FIGURE 11.6. User groups in the BrandX example.
Your next step is to map the resources that will be shared on your domain. This is probably easier for computer types to deal with than the organizational structure issues. Although it is sometimes a challenge to get users to describe how they plan to
use information or even which information they plan on storing, you should be aware of the hardware and shared directories on your servers. Also, because it should take an administrator to share server resources, that means you will stay in the loop. IN
light of this, the following is a list of shared resources for the mythical BrandX example:
I'm sure that you can imagine a dozen other possibilities, but this is enough to illustrate my point. What you have to do next, after you have made up the names, is to actually share the resources. Again, you would use a tool such as File Manager or
Windows Explorer to share directories on the network and Print Manager or Printers on Control Panel to share printers. Figure 11.7 shows a sample sharing of the Corporate directory on the network.
FIGURE 11.7. A sample directory sharing.
Figure 11.8 is an example of a more detailed chart of shared resources. The users care only that they have to find a shared directory or printer with a certain name. You however, often need to know a few more details. You might want to draw such a
chart(even by hand) for yourself.
FIGURE 11.8. A sample shared resources chart.
An important task when sharing resources is to designate who has access to those resources (groups and individuals). This is controlled by selecting the permissions button on the panel that you are using to share the resource (printer or
directory/folder). Figure 11.9 shows a typical sharing display panel. What you have to do for this resource is add a series of users or groups to the list of those that have the access. You also have to designate the type of access (read only, changes
allowed, or full control are the most common ones) for file systems. After this is completed and you have exited from this panel, the users and groups designated will have access to those resources. It does not take a server reboot for these changes to
take effect.
FIGURE 11.9. A typical resource-sharing panel.
Your final task is to create user accounts and assign the appropriate group privileges to the users. Figure 11.10 shows the easy-to-deal-with user interface in Windows NT 4.0. To create a user, you select add user, type in the basic information (as
shown in Figure 11.10), and then add group privileges for the user by selecting the groups button. This will give you the groups display shown in Figure 11.11. For this example, I have added user Bsmith who works at the East Street location of BrandX and
is the manager or the ProjectY team. After you have completed this display, you can exit. One small note: if you add or remove group privileges from a user who is currently logged on to the system, that user will have to log out and log back in again for
the privilege changes to take effect.
FIGURE 11.10. Adding a sample user.
FIGURE 11.11. Sample group associations.
Hopefully this section has given you a feel for the basic user-management process under Windows NT. You may have to go through additional steps for various BackOffice and third-party applications. The section on client-server user administration later
in this chapter will speak to some common third-party application needs. Also, there are chapters on administration in the sections on each of the BackOffice components that will cover the tricks needed to make these applications work well for the users.
There is much more that could be said about user administration (there are several chapters on the subject in various NT books, such as Windows NT Server 4.0 Unleashed from Sams Publishing), but there are other topics we need to cover.
A topic very near to my heart is backup and recovery. I cannot tell you about all of the really big mistakes and disasters I have seen as an administrator that turned out to be not that big a deal due to the existence of good backups. It has saved me so
many times that I do not consider this to be an option on a server—it is a baseline feature. I have actually written long lectures on the subject of why backups are great, but I will spare you that discussion in this book.
What I hope you have done is get a backup device with your server when you were making that initial configuration. If not, why not go out and order one? There are a number of tape and disk drives that can be used for backup with NT (see the Hardware
Compatibility List on the Microsoft Web page or TechNet CD to be sure) that vary in capacity and, of course, cost. You should find one that matches your needs and budget.
Let's say that you have a tape drive that is just right for your particular needs. You have it installed and it works just fine. The question now is, what do you do with it? There are a lot of backup utilities and scenarios out there that you need to
consider. I want to take just a few moments to bring up some of the factors that you might want to consider for your system.
The first choice, after choosing your hardware, is the backup utilities that you will use. Windows NT provides a really convenient backup utility that I have always used (see Figure 11.12) on the NT boxes that I have cared for. It has an easy-to-use
interface and works with all of the common tape drives that I have used. You can even write scripts to automate the backup process, as I will discuss in the scripting section towards the end of this chapter.
FIGURE 11.12. The Windows NT backup utility.
However, there are third-party backup utilities that you may want to consider. Several of the larger tape-drive manufacturers have written their own backup tools. They perform additional functions such as automating the backup process similar to my
scripts. Others may be more closely tied to the particular hardware and be able to access some of their advanced features. If your tape drive comes with some of these other backup utilities, you may want to take a look at them. This is especially true if
you standardize on a single tape-drive family for your entire organization. The only time the non-Microsoft tools become a problem is if you have a number of them on different servers that you have to learn and maintain.
You may want to consider a number of different backup schemes for your server. You may also implement a combination of these backup schemes to ensure that you are doing the best that you can given your system needs. The basic schemes that you should be
aware of include the following:
Let me throw out an example of how these schemes can be mixed. Imagine you have a server with only two disk drives. Drive C:\ contains the operating system and applications that have been loaded. Drive D:\ contains all of the user data. You have a tape
drive that is not big enough to back up both drives at once. Your solution might be to do a complete system backup whenever you install or upgrade a software package on your system. You then perform nightly backups of only the D:\ drive. If drive C:\
fails, you restore from the last complete backup. If drive D:\ fails, you restore from that backup. You have to be careful to ensure that your applications do not write critical log or configuration files on the C:\ directory, but if need be you can just
add these files to your nightly partial backup of the D:\ drive. Finally, you might perform an incremental backup at noon to ensure that you do not lose data from the morning's processing run if you were to have a failure in the afternoon.
An important point to consider when backing up applications is whether or not they have to be stopped for the backup to be useful. Many applications, such as older versions of the Oracle database and Exchange Server, require that you stop them before
completing the backup to ensure that you have a time-consistent data set in your backup. Imagine that you are backing up a large Oracle database that is receiving a stream of transactions. It takes a finite amount of time to back up the various data files.
Therefore, a table in the last data file that you back up may contain a number of changes not reflected in a key table that is related to the first table, but is physically stored in the first data file that was backed up. As you can see, this could cause
a great deal of confusion with the database and lead to useless backups. Many of these applications have options in which you can back up the system while the database is running, but you have to ensure that you set the right options and always test that
these procedures are working correctly by verifying that a restore of the data is usable.
A final point is that many Windows NT installations may not have evening-shift operators to perform backups. Because it is difficult to get system time and perhaps even shut down applications during the business day, administrators have trouble backing
their systems up during the day. Now, for those of you who actually like 16 hour days, it is not a problem. You simply do the backup at midnight, right before you go home. The rest of us need to consider building scripts to automate the backup process. The
section on scripting shows you a few simple backup scripts. I build a script to perform the backup that I want (I have one to perform a partial backup, and another to back up the rest of the system) that I store on the system and then run using the AT
utility described under scripting. My only responsibilities after this are to ensure that there is a tape in the drive before I go home and check that the backup completed successfully in the morning.
The next administrative area for users who allow people to dial in to their computer systems via the telephone lines is the Remote Access Service (RAS) administration. In the Windows NT setup process, you would have configured in the details of what
type of modem that you have and what its settings are. You would also have to configure the network protocols that you are going to use and whether users who dial in can access just the computer that has the modem or the entire network.
With that configuration being taken care of as part of the setup process, it is time to let users actually start using the dial-in service. The first thing that you have to do is grant access to the users of the dial-in services. Under Windows NT 4.0,
you are able to use either the RAS Admin tool or the User Manager tool, both of which are located under the Administrative Utilities menu. Under 3.51, you have only the option of using RAS Admin. Figure 11.13 shows the RAS options panel under NT 4.0.
FIGURE 11.13. The Remote Administration Access setup.
There is one key option after you have indicated that you want to allow a user to use the dial-in services. You have to indicate whether the user has direct access to the system, an optional call back, or a mandatory call back. The optional call back
enables you to save employees telephone charges if they dial in and work from home. The mandatory dial-back feature is a security option that enables you to control which remote telephones (that is, the known home phones of your employees) can access your
server.
The nicest feature about RAS is that it is fairly automatic and easy to set up. When users dial in to the server and network, they use the same interface as when they are on the local network and have the same privileges as they would otherwise. You do
not have to set up special dial-in privileges. If you want to limit access for people coming in through RAS, you can create special, limited-access accounts and assign them limited access privileges (that is, read to only nonsensitive directories).
Another routine task for many system administrators is auditing. Auditing is a form of monitoring that is focused on what people and applications have done (as opposed to performance monitoring, which is focused on the usage of system resources and
speed). It is nicely integrated with the rest of the Windows NT environment in that you find the logged events using the same Event Viewer tool you use for other forms of monitoring—for example, application events and routine system messages such as
those generated at startup.
Auditing has a number of different flavors under Windows NT. Some examples of things that might be interesting to you include the following:
Certain people view auditing strictly as something designed to detect and potentially stop hackers and other security risks. Certainly that is the focus of several classified government agencies, and rightly so. Audit trails that are carefully reviewed
can enable people to detect new ways users are probing the information in a computer that have never been used before. Hackers are just like virus writers—they sit up all night thinking of new ways to hack.
However, I would like you to also consider a broader use for auditing that might interest even those of you who implicitly trust everyone who has access to your server. The first audit records were not written by people trying to stop Internet hackers.
Instead, they were people dealing with early computers that just halted in the middle of executing a program. Because there were no fancy computer monitors back in that era (or any monitors, for that matter), people had little idea where their program
halted. After many frustrating attempts to solve problems by trial and error, people started to record progress that was being made in their applications to output devices such as printers (or paper tape). When applications crashed, they simply traced the
progress through these checkpoints to determine where the problems occurred.
As operating systems grew and become more capable, the auditing capabilities were built into the operating system. This is especially important for multiuser operating systems, where you need to know who caused the problem and what they were doing at
the time to prevent it from happening again. Eventually, auditing was expanded beyond the "finding who caused the crash" stage to provide additional helpful information. It became a tool to record usage of the computer and its various resources.
It was also extended to perform the security-monitoring tasks mentioned earlier.
A general-purpose operating system distributed to a large number of users now has to support a wide range of auditing. It has to cover the security angle to meet the needs of those super-secret environments, but also provide usage metering for people
concerned with efficiently using their resources and planning for the future. Others might be concerned with only a light level of security (for example, who is using system administrator privileges). Windows NT has to meet this wide range of challenges
and also enable the users to pick from various forms of auditing to suit their individual needs.
Let me discuss auditing as it is implemented under Windows NT. I like the way Windows NT implements auditing for the following reasons:
For smaller server environments, it is often difficult to get a lot of formal training on your operating systems. What basic training you do get does not emphasize the finer features of the operating system, such as auditing. Therefore, I thought it
would be useful to go over the auditing options that are available to you. The first set of events that are audited deal with operating system events:
The second area you can monitor involves system-security events such as these:
Finally, the most expandable area involves Windows NT's capability to audit events within applications on the system:
Because the first thing you would want to do if you were trying to do something illegal is cover your trail, the auditing information in Windows NT is fairly well-protected inside the operating system (it doesn't have
even the old, relatively obvious auditing registry keys you had in NT 3.51). The bad guys can't just delete a file and be done with it. You can, however, make a copy of the current log file to save error conditions or document unauthorized activity. This
is especially important when you use the automatic overwrite features in the Windows NT auditing system.
Now that I have covered the "what to do" discussion of auditing, it is time for the "how to do it" discussion. The truly practical among you can rejoice that I am now leaving the theory world and getting down to business. A good
place to start would be what I consider to be the heart of auditing under Windows NT—the Event Viewer. You access the Event Viewer through the Start menu, as shown in Figure 11.14.
FIGURE 11.14. Accessing the Event Viewer.
The system-audit events are pretty clear as to what you would want to record (you almost always want to know if your serial port has an interrupt conflict). The same goes for application events, because you would have to add them to your applications to
get anything to go in there other than a few of the BackOffice products that are currently using this portion of the auditing system. However, the security-logging mechanisms need finer control to accommodate the wide variety of environments that are out
there. If you were to audit everything imaginable in security, your log file would be so large that you would have to write an application just to filter out the events that might possibly be of interest (which would not be all that difficult, actually).
However, some groups that I work with do not even want to waste the disk space for security auditing because everyone has full access to all resources and therefore these records have no meaning (small software development environments can be fun in this
regard).
NT's auditing system accommodates this wide range of needs through the User Manager utility. This is another of the administrative tools that are available to you (refer back to Figure 11.14). I guess it was a toss up as to whether to put all auditing
controls in the Event Viewer or to put all the features involved with user security in the User Manager. Microsoft chose the latter option. To access the controls for security auditing, choose the Audit option from the Policies menu in User Manager (see
Figure 11.15).
FIGURE 11.15. Selecting the Audit option in User Manager.
The Audit option displays the Audit Policy dialog shown in Figure 11.16. The radio buttons are important because they make the basic selection as to whether you perform any of these detailed security-auditing functions. If you select to perform these
security-auditing actions, you are given two basic choices for auditing. The first column of checkboxes enables you to audit when users perform the functions listed successfully (such as logging on with the correct user ID and password). The second column
of checkboxes enables you to audit when users fail when trying to perform a function. You can greatly reduce the number of events recorded if you look only for failures. This catches hackers or people trying to access a resource for which they lack
permission. However, if you are trying to gather statistics on usage or logging all (legal) access to a resource, you would want to use the first column's checkboxes. Of course, if you really want a lot of information, you can audit both successes and
failures.
FIGURE 11.16. The Audit Policy dialog box.
Splitting the security-auditing features into these seven categories enables you to pick the items that meet your needs and ignore the others, which can also reduce the number of log-file entries you have to review. The categories you have to choose
from are as follows:
As you can see, you can set up a lot with NT auditing. The interface that controls and reviews the auditing information is also a clean and simple one. The challenge is often to make the time to review the log. In summary, your steps in setting up
auditing on an NT Server should include the following:
We live in a world in which everyone wants you to do more with less resources. System administrators in charge of a Windows NT server are no exception to this rule. As a matter of fact, they often feel more pressure in this regard because a lot of NT
servers were designed to replace much larger computer systems to help the organization save money. These organizations often forget about the increased load placed on computer systems when users actually start to use the newer, more convenient
applications. Therefore, it is in the best interest of administrators to understand performance tuning.
I like the subject of performance tuning so much, I decided to devote all of Chapter 13, "NT Integration with Netware and UNIX," to the subject. It is a somewhat challenging discipline in that you have to really
understand how your hardware, operating system, and applications are interacting to affect your overall performance. You also have to deal with the concept of the bottle neck. What this means is that you can have tons of resources on your system, but if
you are shy of just one little resource it can drag down system performance severely. After Chapter 13, you should be able to understand enough of the basics to track down your performance problems and get the best amount of
performance possible for your resources (sometimes you have to tell your boss that the best-tuned 60 MegaHertz Pentium cannot be made to outperform a multimillion dollar Cray computer).
Before leaving this chapter, though, I wanted to give you a basic understanding of the two key concepts that relate to performance management. The first of these is that of resources on your system. What this discipline involves is breaking down the
hardware, operating system, and applications into logical components that affect performance. Examples of the more commonly used resources include central processing units, physical memory, and disk capacity. These fundamental resources are broken down
into things that can actually be measured that affect performance. Examples of this include the number of bytes that are transferred per second to a specific disk drive, or the number of processes that are waiting to access a particular disk drive. These
are the things you measure when you are conducting performance monitoring that will tell you when your system is having a problem.
The other key concept that I want to discuss related to performance monitoring is the capacity of the various system resources. This is very difficult to measure in absolute terms. It often depends on a number of factors, such as how your system is
being used, which model of disk drive is installed, and so on. With the exception of a few parameters (for example, CPU capacity) that have absolute numbers (which can be provided by the vendors), you are often left to measure the performance of your
system when everything is working properly to provide a baseline for comparison when your system starts to exhibit performance problems. Absolute numbers would be nice, but there are just too many variables between all existing installations to make such
numbers readily available.
Presented here are a few key concepts related to performance tuning, to be considered along with the overall administrative picture. Windows NT is described as a self-tuning operating system. This means that the operating system works to adjust its
internal system parameters to get the most that it can out of given resources. However, it does not mean that you can expect to have good performance if all of your commonly used files are on a single disk drive and it happens to be the slowest drive on
your system. Chapter 13 goes into this subject in more detail.
The BackOffice family of products integrates quite nicely into the Windows NT security and administration scheme. There are products out there that do not fit into this scheme, so I want to make sure that you are aware of these cases. The most difficult
to control as a system administrator are those applications that access your server via client-server applications. The basic concept of many of these applications is that you have a server application that is accessed via a direct connection from the
client via Windows Sockets or some other mechanism, as shown in Figure 11.17. You have to have server permission to start your database (this example shows an Oracle database on your NT server), but all access to that database is controlled internally to
the database. You can shut down the access mechanism (in this case the SQL*Net communications service that runs under NT), but you cannot monitor and control the users who are using this communications channel.
FIGURE 11.17. An example of client-server access for Oracle.
This is a valid access mode, and it works quite well for most such applications. However, there are a few things that you as the system administrator need to consider:
One point to note before leaving this section is that one of the BackOffice products can be configured to enable general access to your computer bypassing user ID and password validation. Before you get too nervous, remember that access through this
tool is limited to those directories you designate. The tool is the Internet Information Server product. The World Wide Web service is designed to enable anyone on the network who can find the Web server to access specified Web pages. As a matter of fact,
you have to do some pretty fancy page design to restrict access to certain Web pages. The other tool is the File Transfer Protocol service when configured to allow anonymous FTP access. Again, in the case in which you enable anonymous FTP, you are trying
to let anyone from the general population access the data you place in the FTP directories. The key with these two products is understanding that the general public can access the specified directories and making sure that you do not put any sensitive
information in them.
One topic that an administrator has to consider in light of the client-server discussion above is the fact that many other, purely server-based applications may also need special attention. Classic examples of this are applications that require certain
batch jobs to be run every so often, or applications producing log files that need to be cleaned out on a routine basis. This book cannot anticipate all of the possibilities. Instead, I recommend that you check for this every time a new application is
loaded on your server and put it into your task list.
Just as a reminder, here are a few other tasks that you need to factor time into your schedule for as an administrator. I will break these other tasks down into four general areas:
In some ways, upgrades to operating systems or other BackOffice components can be trickier than installations on a new system. For example, let's say that you really mess up when installing a new server. You can generally start from scratch. You may
have trouble making deadlines, but no one has lost any data. On an upgrade, though, the system is in production. You usually get only a limited time window to perform the upgrade, and you also have live user data that must be preserved. The pressure is on.
A few suggestions that I always try to follow when performing upgrades include the following:
Another task system administrators generally need to allocate some time for is customer support. There are many forms of customer support such as adding user accounts, but what I want to focus on here is all of those calls where users have questions
about how to do something or are having problem with something. No matter how good the system documentation is, these calls are going to come up and you will have to make the time to deal with them. Perhaps you have a help desk to field the initial calls,
but some are usually going to be beyond the help-desk level and filter down to you.
Another thing you need to make time for as an administrator is keeping your level of knowledge up to date. If you were an experienced OS/2 version 1 administrator who did not update his skills, you would be pretty useless in today's market. The computer
industry changes quickly. You need to make time to keep up on these changes, or else you will be unable to give the right advice and keep your systems up to date. There are some antiquated systems that are running fine out there, but all computers
eventually get retired. Hopefully the system administrator will not get retired with the computer.
One final thought: problem solving is a major job for most administrators. The time required for user administration and backup have decreased. The good news is that Windows NT servers are very reliable once set up. I spend very little time tweaking
them, and that is pretty impressive considering that I work in an ever-changing development environment. However, hardware fails and software has problems. The only thing I can offer is that you need to learn as much as you can about your system before the
problems start and combine that knowledge with a logical problem solving methodology to figure out the problem. Some of the discussions on monitoring in Chapter 13 might be useful when you are trying to figure out exactly where the
problem lies.
I want to throw this section in here even though many of you will not want to batch files (sometimes called scripts for ex-Unix types) to automate system functions. I typically try to build a script for any repetitive task I have to perform that
requires a fair amount of time at the keyboard and requires me to issue a number of operating-system commands (as opposed to those long-running jobs that are kicked off by running a single command). Batch files enable you to perform a number of routine
system functions. Batch-file programs take the commands that you enter at the DOS command line and store them in an ASCII text file, which usually ends with the BAT or CMD extension. You then can execute these files from the command line. You usually can
put together batch files quickly, making it easy for you to automate common administrative tasks. You may even want to create a directory of your common scripts that has some form of protection (ownership and access privileges for only administrators, for
example).
Although you can use a local command prompt or remote procedure call to execute these scripts on an as-needed basis, there is a more interesting use for your administrative batch files. The best form of remote processing is that taking place
automatically, without your involvement. To accomplish this, create a script and store it in a batch file. The following is a portion of a script that would stop an Oracle database, stop its services, and perform a backup of the C:\ drive.
net stop "OracleServiceORCL" >> c:\scripts\backup.log ntbackup backup c: /d"Daily Backup" /b /l"C:\daily_bk.log" /tape:0 net start "OracleServiceORCL" >> c:\scripts\backup.log
Using the preceding code, you have saved the complete listing of the script in a file called BACKUP.BAT, which is located in the protected C:\SCRIPTS directory. Suppose that you also want to perform your nightly backups at 2 a.m. every morning of the
week. (Hopefully, someone else will come in and change the tape that is in the tape drive on weekends.) To schedule a job to run at a time you specify (either once or on a recurring basis), use the at command. In this command, you specify the time and then
the script to run. It is similar in concept to the UNIX cron utility. To set up your backups, at the DOS command prompt, type the following:
at 2:00 "c:\scripts\backup.bat"
The graphical administrative tools provided in Windows NT are easier to deal with than batch programs. Batch files, however, provide a tool that enables you to perform tasks that graphical tools cannot. You can use batch programs rather than GUI tools
to more easily meet special needs or perform simple tasks. For example, I have a simple batch file on my computer at work that copies the contents of my six data-holding directories to my directory on the server drive about an hour before the nightly
backup kicks off. This way, my workstation (which lacks a tape drive) has its user data backed up nightly. Although I could set up the server to back up my local hard disk through the network as part of its backup job, I like to do it this way because if I
mess up a file, all I need to do is copy it from my server, without restoring from tape.
You might be surprised at the number of NT command-line applications that enable you to specify a remote computer name for execution. One of the biggest is probably the shutdown command. You use the UNC name for the computer to specify which computer is
to be shut down. An example of this command (for shutdown and reboot) is the following:
shutdown \\joe /R
You might want to consider these concepts when it comes time to automate some of your routine tasks. I want to mention, before leaving this section, the Remote Command Server and Executable program found on the Windows NT Resource Kit from Microsoft.
You load and start this service on the server of interest. Then you load the Rcmd.exe program into the system directory of a client workstation (like the one located on your desk in your office). You can then send commands to the server via the Rcmd
utility. All you have to do is specify the command name (for example, c:\scripts\backup.bat) and the server name as parameters to this command and you get a window in which you are executing a program using the CPU and other resources of the remote
computer while displaying the results on your computer. You could take this to higher levels and set up a rather nice remote-administration system going beyond the remote-administration tools provided as part of Windows NT.
This chapter has covered a rather broad topic that is very important to system administrators. It involves a series of skills and tools that are used to keep the NT operating system functioning. I will go into the performance-tuning topic in more detail in the next chapter. I separated this out because it goes beyond routine administration and gets into some low-level details. Many Windows NT administrators do not have to worry about tuning. They have sufficient resources and their user demands are reasonable. Others, however, will have to crawl inside the guts of their system using performance-monitoring tools to help squeeze some additional performance out of a disk drive or perhaps justify the procurement of additional disk-storage space.
