The System Log
This log file tracks just about every event that occurs on that computer. It is similar to NetWare?s SYS$LOG.ERR file. However, whereas the SYS$LOG.ERR file tracks many categories of errors, the System Log tracks only three main types of events:
Note Two other types of events (Audit Success and Audit Failure) normally appear only in the Security Log (discussed later in this chapter).
This list contains several categories of information, including the date and time the event occurred, the source of the event (which process the event came from), which user (if applicable) initiated the process, the name of the computer the event happened on, and the Event ID number (in the Event column). The Event ID number is the unique error type of a particular event. For an explanation of each Event ID number, check the Help file, or go to www.microsoft.com/technet/ and search for Event ID.
The note in the Description box indicates that Windows NT found a bad disk block. Even though this is an error event, it is not serious. One bad block is not a problem, unless several disk blocks start going bad at once. The Data box lists the exact data the Event Viewer received about the error condition. This may be useful in determining the source of the problem. More than likely, if you have a serious problem that you can?t fix, this is the information that you will send to the vendor (or to Microsoft) to help troubleshoot the problem.
The Application Log
This log is similar to the other two logs, except that it tracks events for network services and applications (for example, SQL Server and other Back-Office products). It uses the same event types (and their associated icons) as the System Log.
To access the Application Log, in Event Viewer, choose Log - Application. The Sources column indicates which service logged which event.
All together, the log files present a picture of the general health of a Windows NT server. Generally speaking, if you see an error message, open Event Viewer and check the System Log. If you don?t see the event here, check the other two logs.
The Security Log
This log tracks security events specified by the domain?s Audit policy. The Audit policy is set in User Manager for Domains and specifies which security items will be tracked in Event Viewer. To set the Audit policy, follow these steps:
The Security Log displays two types of events:
This log is especially useful in troubleshooting when someone can?t access a resource. If your domain security policy has been set to log Failures of Use of User Rights, you can see every instance of a user not having enough rights to access a resource. The username appears in the User column of the Failure Audit event for the resource the user is trying to access.
Manufacturers? Troubleshooting Resources
In addition to viewing log files, you can use several types of troubleshooting tools that manufacturers make available for their network operating systems. You can use these resources to augment your own knowledge, as well as to solve those pesky problems that have no pattern or few recognizable symptoms. Each type of resource provides different information or different levels of support (some of which have been discussed in previous chapters, but their importance to troubleshooting necessitates discussing them again here). Let?s examine the most popular, including:
README files contain information that did not make it into the manual. The latest information released about the software can often be found in the README files. Also, they may contain tips, default settings, and installation information (so you don?t have to read the entire first chapter to install the software).
When troubleshooting application or networking software, check out the README file before you try any of the other manufacturers? resources. It is usually found on the first installation disk or CD.
Many people prefer telephone support over other forms of support. You actually get to talk to a human being from the software manufacturer about the problem. Most, if not all, software manufacturers have toll-free support numbers. The people on their end of the line can provide anything from basic how-to answers to complex, technical answers.
Unfortunately, because of their popularity, technical support phone lines are often busy. When the line is finally free, you might, however, find yourself in ?voicemail hell.? We?ve all been through it: Press 1 for support for products A, B, and C. Press 2 for Products D, E, and F, and so on and so on. Most people don?t want this and hang up. They prefer to speak with a human being as soon as the call is answered. Today, phone support is often not free (the number to reach support might be, but the support itself is not), but must be purchased via either a time-limited contract or on an incidentby-incident basis. This is particularly true for network operating system software support. To solve this problem, companies have devised other methods, such as the technical support CD-ROM and website, which we will discuss next.
The Technical Support CD-ROM
With the development of CD-ROM technology, it became possible to put volumes of textual information on a readily accessible medium. The CDROM was, thus, a logical distribution vehicle for technical support information. In addition, the CD was portable and searchable. Introduced in the early 1990s, Novell?s Network Support Encyclopedia (NSE) CD-ROM was one of the first products of this kind. Microsoft?s TechNet came soon after. Both companies charge a nominal fee for a yearly subscription to these CDs (anywhere from $100?$500).
To be sure, the first editions of these products (as with the first editions of most software products) left much to be desired. Search engines were often clumsy and slow, and the CDs were released only about twice a year. As these products evolved, however, their search engines became more advanced, they included more documents, and they were released more often. And, probably most important, manufacturers began to include software updates, drivers, and patches on the CD.
The Technical Support Website
The technical support CDs were great, but people started to complain (as people are wont to do) that because this information was vital to the health of their network, they should get it for free. Well, that is, in fact, what happened. The Internet proved to be the perfect medium for allowing network support personnel access to the same information that was on the technical support CD-ROMs. Additionally, websites can be instantly updated and accessed, so they provide the most up-to-date network support information. Since websites are hosted on servers that can store much more information than CD-ROMs, websites are more powerful than their CD-ROM counterparts. Because they are easy to access and use and because they are detailed and current, websites are now the most popular method for disseminating technical support information. As examples, you can view Novell?s technical support website at http://support.novell.com/ and Microsoft?s technical support website (Tech-Net, a monthly subscription) at http://support.microsoft.com/servicedesks/technet/.
Hardware Troubleshooting Tools
In addition to manufacturer-provided troubleshooting tools, there are a few hardware devices we can use to troubleshoot the network. These are actual devices that you can use during the troubleshooting process. Some devices have easily recognizable functions; others are more obscure. Four of the most popular hardware tools (that the Network+ exam tests you on, by the way) are:
Sometimes also called a cross cable, a crossover cable is typically used to connect two hubs, but it can also be used to test communications between two stations directly, bypassing the hub. A crossover cable is used only in Ethernet UTP installations. You can connect two workstation NICs (or a workstation and a server NIC) directly using a crossover cable.
A normal Ethernet (10BaseT) UTP cable uses four wires?two to transmit and two to receive.
The standard Ethernet UTP crossover cable used in both situations has its transmit and receive wire pairs crossed so that the transmit set on one side (hooked to pins 1 and 2) is connected to the receive set (pins 3 and 6) on the other.
Tip Be sure to label a crossover cable as such to ensure that no one tries to use it as a workstation patch cable. If it is used as a patch cable, the workstation won?t be able to communicate with the hub and the rest of the network.
You can carry a crossover cable in the tool bag along with your laptop. If you want to ensure that a server?s NIC is functioning correctly, you can connect your laptop directly to the server?s NIC using the crossover cable. You should be able to log in to the server (assuming both NICs are configured correctly).
The Hardware Loopback
A hardware loopback is a special connector for Ethernet 10BaseT NICs. It functions similarly to a crossover cable, except that it connects the transmit pins directly to the receive pins. It is used by the NIC?s software diagnostics to test transmission and reception capabilities. You cannot completely test a NIC without one of these devices.
Usually, the hardware loopback is no bigger than a single RJ-45 connector with a few small wires on the back. If a NIC has hardware diagnostics that can use the loopback, the hardware loopback plug will be included with the NIC. To use it, simply plug the loopback into the RJ-45 connector on the back of the NIC and start the diagnostic software. Select the option in your NIC?s diagnostic software that requires the loopback, and start the diagnostic routine. You will be able to tell if the NIC can send and receive data through the use of these diagnostics.
Tone Generator and Tone Locator
This combination of devices is used most often on telephone systems to locate cables. Since telephone systems use multiple pairs of UTP, it is nearly impossible to determine which set of wires goes where. Network documentation would be extremely helpful in making this determination, but if no documentation is available, you can use a tone generator and locator.
Note Don?t confuse these tools with a cable tester that tests cable quality. You use the tone generator and locator only to determine which UTP cable is which.
The tone generator is a small electronic device that sends an electrical signal down one set of UTP wires. The tone locator is another device that is designed to emit a tone when it detects the signal in a particular set of wires. When you need to trace a cable, hook the generator (often called the fox) to the copper ends of the wire pair you want to find. Then move the locator (often called the hound because it chases the fox) over multiple sets of cables (you don?t have to touch the copper part of the wire pairs; this tool works by induction) until you hear the tone. A soft tone indicates that you are close to the right set of wires. Keep moving the tool until the tone gets the loudest. Bingo! You have found the wire set.
Warning Never hook a tone generator to a cable that is hooked up to either a NIC or a hub! Because the tone generator sends electrical signals down the wire, it can blow a NIC or a hub. That is why tone generators are not usually used on networks. Cable testers are used more often. We?ll discuss cable testers later in this chapter.
Software Troubleshooting Tools
In addition to these hardware troubleshooting tools, you can use software programs to gain information about the current health and state of the network. These tools fall into two main categories:
Any software that can analyze and display the packets it receives can be considered a protocol analyzer. Protocol analyzers examine packets from protocols that operate at the lower four layers of the OSI model (including Transport, Network, Data Link, and Physical) and can display any errors they detect. Additionally, most protocol analyzers can capture packets and decode their contents. Capturing packets involves copying a series of packets from the network into memory and holding the copy so that it can be analyzed.
You could, for example, capture a series of packets and decode their contents to figure out where each packet came from, where it was going, which protocol sent it, which protocol should receive it, and so on. For example, you can find out:
In addition to protocol analyzers, many network operating systems include tools for monitoring network performance and can display statistics such as the number of packets sent and received, server processor utilization, the amount of data going in and out of the server, and so on. NetWare comes with the MONITOR.NLM utility, and Windows NT comes with Performance Monitor. Both monitor performance statistics. You can use these utilities to determine the source of the bottleneck when users complain that the network is slow.
Note To start the MONITOR.NLM utility in NetWare, simply type LOAD MONITOR at the console prompt. To start the Performance Monitor program in Windows NT, you must first be logged in as Administrator (or a member of the Server Operators group). Once you are logged in, choose Start - Programs - Administrative Tools - Performance Monitor.
Now that we have covered the basics of network troubleshooting, we should go over a few troubleshooting tips. These tips will give you more ?ammo? while you?re hunting for network problems and using the various steps of the troubleshooting model discussed earlier.
Don?t Overlook the Small Stuff
If you?ll remember, the first thing we discussed in this chapter was small stuff. Often a problem is caused by something simple, such as a power switch in the wrong position, a card or port not functioning (as indicated by a link light that?s not lit), or simply operator error. Even the most experienced administrator has forgotten to turn on the power, left a cable unplugged, or mistyped a username and password.
Finally, make sure that users get training for the systems they use. That may seem like an extra bother, but an hour or two of training goes a long way toward preventing problems. The number of incidents of EEOC will decline with a little user training.
Prioritize Your Problems
It is unlikely that as a network administrator or technician, you will receive problem calls one at a time. Typically, when you receive one call, you already have three people waiting for service. For this reason, you must learn to prioritize.
You start this process by asking some basic questions of the person reporting the problem so that you can determine its severity. If the current problem is minor and you have two more serious problems already facing you, your priorities are obvious.
You establish priorities to ensure that you spend your time wisely. The order in which you attempt to solve your networking problems, from highest priority to lowest, might look something like this:
Remember also that some simple problems may take more effort than larger problems. You may be able to bring up a crashed server in a matter of minutes, but a user who doesn?t know how to make columns line up in Microsoft Word may take up to an hour or longer to train. The latter of these problems might get relegated toward the bottom of the list because of the time involved. It is more efficient to solve problems for a larger group of people than to fix this one user?s problem immediately.
Some network administrators list all network service requests on a chalkboard or a whiteboard. They then prioritize them based on the previously discussed criteria. Some larger companies have written support-call tracking software whose only function is to track and prioritize all network and computer problems. Use whatever method makes you comfortable, but prioritize your calls.
Check the Software Configuration
Often, network problems can be traced to software configuration (as with our DNS configuration example earlier in this chapter). When you are checking for software problems, don?t forget to check configuration, including the following:
Additionally, in text configuration files, look for lines that have been commented out (either intentionally or accidentally). A command such as REM or REMARK or the asterisk or semicolon characters indicate comment lines in a file.
Tip The HOSTS file uses a # (pound sign) to indicate a comment line, as does NetWare?s NCF files.
Don?t Overlook Physical Conditions
Don?t Overlook Physical Conditions
You want to make sure that from a network design standpoint, the physical environment for a server is optimized for placement, temperature, and humidity. When troubleshooting an obscure network problem, don?t forget to check the physical conditions under which the network device is operating. Check for problems such as the following:
Don?t Overlook Cable Problems
Don?t Overlook Cable Problems
Cables, generally speaking, work fine once they are installed properly. Rarely is the cabling system the problem, unless someone has made some change to it. If you suspect that the cabling system is the problem, try replacing the patch cables at the workstation and hub first. These are easiest to get to (and replace). If that solves the problem, you know the problem was related to the patch cable. It was either faulty or the wrong type.
If the patch cable isn?t the problem, use a cable tester (not a tone generator and locator) to find the source of the problem. Wires that are moved can be prone to breaking or shorting. A short can happen when the wire conductor comes in contact with another conductive surface, changing the path of the electrical signal. The signal will go someplace else instead of to the intended recipient. You can use cable testers to test for many types of problems, including:
Check for Viruses
Check for Viruses
Many troubleshooters overlook virus scanning because they assume that the network virus-checking software should have picked up any viruses. We?re reminded by the network virus-scanning software of the bio-filters in the transporter on Star Trek: The Next Generation. They work great as long as the computer has the latest information on what the virus is and how to eliminate it. On many occasions, though, the ship?s doctor or engineer had to reprogram the bio-filters to recognize some new virus that the crew of the Enterprise had come across.
The same thing happens with network virus-scanning software; to be effective, it must be kept up-to-date. Updates are made available almost daily. As we Guide 9 - ?Fault Tolerance and Disaster Recovery,? you must run the virus definition update utility to keep the virus definition file current.
If you are having strange, unusual, irreproducible problems with a workstation, try scanning it with an up-to-date virus scan utility. You?d be surprised how many times people have spent hours and hours troubleshooting a strange problem, only to run a virus scan utility, find and clean one or more viruses, and have the problem disappear.
In this guide , you learned about the proper methods of troubleshooting-network problems. In the first section, you learned the proper method to start to fix any network problem by eliminating what the problem is not. You learned how to narrow the problem down to its essentials and therefore further define it.
Next, you learned a systematic approach to troubleshooting, using an eight-step troubleshooting model to troubleshoot almost any problems you may encounter on your network. After that, you learned about several resources that you can use to help you during the troubleshooting process. You learned about the websites and other support tools available for most vendors? products.
Finally, you learned a few troubleshooting tips that will help make the troubleshooting process go more smoothly. As you venture out into the ?real world,? keep these tips in mind, as they will help make you an expert troubleshooter.
|Tags: guide, networking, troubleshooting|
|Thread Tools||Search this Thread|
|Similar Threads for: "Networking Guide 9 - Network Troubleshooting"|
|Thread||Thread Starter||Forum||Replies||Last Post|
|The Darkness II Troubleshooting Guide and PC Fixes||spookshow||Guides & Tutorials||4||22-03-2012 10:23 PM|
|Dragon Age 2 Troubleshooting Guide||OptimuS PrimE||Guides & Tutorials||22||27-01-2012 03:26 PM|
|Networking Guide 7 - Network Access and Security||mindreader||Networking & Security||26||28-08-2010 02:09 PM|
|Wireless Networking for Businesses Guide||Richard B Rufus||Guides & Tutorials||0||29-04-2008 07:15 PM|
|Networking Guide Part 3 - TCP/IP Fundamentals||mindreader||Networking & Security||26||12-11-2004 09:07 AM|