Event logging isn’t limited to the operating system. Applications that are designed for Windows NT bring with them their own event sources and IDs. Also, security logging takes place when the server is a domain controller or when you have specified that certain actions, such as file accesses, be audited for later inspection.
Before I get too much farther into event logging, a discussion of the types of events and their characteristics is in order.
Windows NT Server events come in five flavors:
- Information. These events generally are recorded when a significant but successful event happens on your NT Server; a service starts successfully, for example. You will see several of these events each time a server is booted, as the services start themselves up. Information events are marked in the Event Viewer with a blue circle containing an “I.”
- Warning. These events are recorded when something happens on the server that may not be significant now but could spell trouble later. Low disk space is a good example of a situation that could cause a Warning event (see Figure 11-13). Warning events are recognized because they appear next to a yellow circle with an exclamation point inside.
- Error. This indicates that a serious problem has occurred on the server that could hamper its performance. Error events are most commonly generated when services fail to start, but they can be associated with such serious events as hard drive failures in a RAID array, or worse. Error events are marked with a red stop sign.
- Success Audit. These auditing events are recorded in the Security log when a successful security event takes place, such as a user logging on successfully or gaining access to a file or directory that is marked for auditing. The Success Audit’s icon is a yellow key.
- Failure Audits. These are generated when a user is unable to log on, or when the user attempts to access a file, directory, or privilege he or she does not have access to. Failure audits are marked with a gray padlock.
Windows NT events also contain several attributes, explained in Table 11-1.
At my business, checking event logs is a weekly task, unless something seems to be going wrong with one of the servers. In that case, we go right to the logs to look for information on any possible problems.
One thing that’s very important to remember about Event Viewer is that just because a Warning or Error event doesn’t sound too serious, or because you don’t know what it is, you shouldn’t just clear the log and ignore the event. Sometimes these “unknown” events can be precursors to a major system problem. If the error’s content or cause isn’t clear from the information in the event log, record the Event ID and jump into TechNet or Support Online to query on that ID. Often, these confusing events are caused by bugs in software or the operating system, and eight times out of ten, I’ve found a solution by searching TechNet and finding references to service packs or hotfixes that correct these strange events. (Service packs and hotfixes are discussed more thoroughly in Chapter 13.) On another occasion, my cohorts and I couldn’t identify the cause of a periodic serious error that was recorded in our event logs. After searching TechNet, we were able to determine that is was a precursor to a major SCSI device failure, and we were able to replace the failing device before it took down the server.
In short, Event Viewer is a tremendously powerful tool for Windows NT professionals: The NT event logs are like a continuous record of your server’s health, with possible problems recorded in real time throughout the day. By making proper use of Event Viewer, you can prevent server and network problems from rearing their ugly heads. Even if these challenges do get the best of your server, Event Viewer can assist you in diagnosing and correcting the problem.
STEP 8: VERIFICATION OF SERVERS AND APPLICATIONS
This task should be first and foremost on each administrator’s morning checklist. When you get into the office, take a few minutes to check out all the servers, applications, and databases. If they’re not working properly, it’s a lot better for you to find out about it before too many users get into the office than for your phone to start ringing off the hook while you sit in clueless bliss drinking your coffee. Also, if your schedule allows it, try to get into the office at least a half hour before the majority of the users. This way, if there is a problem, you have a little cushion of time to try to fix it. Even in 7 × 24 shops, most people still work 8 to 5, so getting in at 7:30 or earlier will help lower your stress level if one of your servers decides to go on vacation overnight.
First: Check on the servers and services
Many server hardware products come with Simple Network Management Protocol (SNMP)–based remote management tools that can tell you at a glance which boxes are running and which are not. Although these tools are good for ensuring that the hardware is on and the operating system (networking) is functional, they don’t really tell you anything about the services on the server. It is certainly possible for a Primary Domain Controller to be up and running, but if the Netlogon service has stopped, ain’t nobody logging on from nowhere. Thus, it’s a good idea to look at the actual services on each server using Server Manager or your favorite third-party utility (see Figure 11-14). This process takes a little while, but it definitely pays for itself in the long run. For instance, someday it could save you from having to explain to the boss why you didn’t check to make sure the Exchange Information Store was running on your Exchange server because your management tool said the machine was up.
If you do discover a problem during your morning check, now’s the time to fix it, before many more users come into the office and start hammering on the systems.
Second: Check applications and databases
After you’re convinced that your servers are up and healthy and the services are running, the next step is to actually log onto each application and do some test operations to make sure the apps themselves are working properly. This operation doesn’t have to be elaborate; a simple test query or two will do, but every Windows NT administrator should at least have the access and the know-how to log on and test each application on his or her servers. At my office, we have four main applications that reside on our NT servers, and we try to test them out each morning as soon as we get in. If we find something wrong and it looks like the server itself is up and running, we can report the problem to the appropriate applications group for resolution.
STEP 9: VERIFICATION OF LAN AND WAN CONNECTIVITY
Once you’re satisfied that your servers and applications are running and ready for the users, the next step in a Windows NT administrator’s daily checklist is to make sure everybody on the network is talking. This can be accomplished in a couple of ways, depending on the size of your network and the tools at your disposal. If you use an SNMP network management system like HP OpenView, Tivoli NetView, or Computer Associates Unicenter TNG, your SNMP console will tell you in an instant whether network links are up or down. However, if you’re in a smaller organization that didn’t budget for these rather expensive tools, you can still easily verify whether your network is intact each day. It’s a fairly simple task to write a batch file that uses the TCP/IP ping utility to attempt to reach all servers and network devices on your LAN and WAN and then write its results to a text file that’s available for your inspection (see Figure 11-15). If you’re still using IPX exclusively and do not have TCP/IP running on your networks, you can write a routine that connects to remote machines via RPC calls, such as attempting to map a drive on the remote machine.
A TCP/IP ping batch file might look something like this:
REM Testing network connectivity on LAN and WAN
ping server1 > conntest.txt
ping server2 > conntest.txt
ping server3 > conntest.txt
ping wan1server2 > conntest.txt
ping wan2server1 > conntest.txt
end
Once you have your text file available, you can inspect it and look for ping timeouts and excessive turnaround times that might indicate a problem with your network. In fact, it’s a good idea to automate this process with NT’s AT command so that you can schedule the connectivity test batch file to run a few minutes before you get into the office. That way, the results will be available when you arrive, and you can take action if necessary.
This method is the way we monitor connectivity at my office, and while it’s not as fancy as some of the network management tools, it is effective and gives us what we need and enables us to make sure our users in faraway branch offices stay as connected as the folks in the home office.
|
Secret: If you need a slightly more sophisticated approach than the “home grown” variety displayed previously, you should consider Ping Plotter, a low-cost shareware application from Richard Ness at Nessoft (www.nessoft.com). Not only does this application test ping connectivity, but it also enables you to observe ping performance across several WAN hops. The hop path is even mapped for you! MCSE consultant-types typically use this tool for testing telco/WAN performance. That is to say that Ping Plotter enables you to test the links and down the food chain on your WAN. This ultimately enables you to answer your questions regarding the subscribed bandwidth the telco sold you and the performance that you are actually enjoying. Important questions indeed to get answers to, might I say, on a daily basis. |
Tool like Ping Plotter are also great for keeping a green machine awake. Here is what I mean: Perhaps you’ve installed Windows NT Server on a truly low-cost workstation. But try as you might, you can’t disable the sleep function at the workstation’s BIOS level (it’s happened to me). To keep the workstation from “sleeping” and crashing Windows NT Server, you can use Ping Plotter to maintain a constant activity level that prevents, shall I say, napping. Problem solved.
Whatever your preferred pinging method is, the bottom line is that you are trying to verify connectivity. On your bad NT days, that becomes an end in itself. Otherwise, this step should just be second nature. And you can always count on your end users to be your connectivity eyes and ears. If they can’t connect, you’ll know.
Figure 11-16: Ping Plotter
STEP 10: NEW HARDWARE
As flaky as it is sometimes, the Plug and Play feature of Windows 95 and 98 is nice to have. Nothing beats buying a Plug and Play–compliant peripheral, throwing it into your PC, and having the operating system detect and set up the new hardware. Easy as pie, as long as you buy compliant hardware.
Windows NT Server doesn’t have this feature, at least not yet. Plug and Play functionality is coming in Windows 2000, but unless you’re a brave beta tester, you’ll have to wait several months or more for that version to hit the streets.
So how the heck do you add new hardware to a Windows NT 4.0 Server? It’s actually easier than it seems. When you buy a new piece of hardware for your server, it will come with a Setup disk or CD-ROM that contains drivers for the device. However, using the distribution software in the box should always be your second step; the first step is to check the hardware vendor’s Web site. Ninety percent of the time, the drivers on the Web are newer than those in the box, and with very few exceptions, you always want to use the latest driver.
Preparing for installation
Before you set about installing your new hard drive, network adapter, or whatever, you should take stock of the resources currently in use on the system (see Figure 11-17). You can do this by running Windows NT Diagnostics, the NT version of Microsoft’s good ol’ DOS MSD program. NT Diagnostics will enable you to inspect and print out the list of resources in use on your server, including interrupt request lines (IRQs), memory addresses, I/O ports, and direct memory access ( DMA) channels. This way, you can determine where the new hardware will fit in.
|
Note: In most cases, a device’s driver setup program will determine and assign free system resources, so the preceding step is only necessary when the setup program will prompt you to choose resource information. |
|
Page: 1, 2, 3, 4, 5, 6 |
next page  |
|
|
|
|
Windows IT Pro
Register
