BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 528

20 Zen and the

Art of Network Support
“Primum non nocere”
(“First, do no harm.”)
—ATTRIBUTED TO GALEN OF PERGAMUM
(131–201 A.D.), GREEK PHYSICIAN

In this chapter, you will learn

how to
■ Describe troubleshooting tools
H ave you ever seen a tech who walks up to a network and seems to know
all the answers, effortlessly typing in a few commands and magically
making the system or network work? I’ve always been intrigued by how they
■ Explain the troubleshooting do this. Observing such techs over the years, I’ve noticed that they tend to
process
follow the same steps for similar problems—looking in the same places, typing
■ Analyze troubleshooting
scenarios the same commands, and so on. When someone performs a task the same way
every time, I figure they’re probably following a plan. They understand what
tools they have to work with, and they know where to start and what to do
second and third and fourth until they find the problem. This chapter’s lofty
goal is to consolidate my observations on how these “übertechs” fix networks.
We’ll look at the primary troubleshooting tools, formulate a troubleshooting
plan, and learn where to look for different sorts of problems. At the end of the
chapter, we’ll apply this knowledge to some common troubleshooting scenarios.

528
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 529

Test Specific

■ Troubleshooting Tools
While working through the process of finding the cause of a problem, you will
need to use many tools. Some of these tools are difficult to quantify—including
things like asking questions, referring to your network baselines and docu-
mentation, and synthesizing your network knowledge. Other tools are eas-
ier to describe; these are the software and hardware tools that provide
information about your network. Many of the tools that fall into this cate-
gory have been described already, such as hardware or software loopback
testing devices, utilities like PING and TRACERT, and hardware tools like
tone locators. The trick is knowing when and how to use these tools to solve
your network problems.

“Touchy” Tools
No matter what the problem,
The tools that are the most difficult to quantify, because they are mostly always consider the safety of
within you, are what I call touchy tools . An example of a touchy tool is ask- your data first. Ask yourself this
ing questions of the person who has the problem. This is touchy because question before you perform
there’s no predetermined set of questions to ask—your background knowl- any troubleshooting action: “Is
what I’m about to do going to
edge and intuition must tell you which questions are the right ones. The
potentially damage data?”
types of questions you should ask can be grouped into a few categories:
■ Questions designed to find out exactly what steps the user took that
may have caused the symptom. This information can help you re-create
the problem. In addition, these types of questions can provide insight
into whether the problem was caused by user error or improper
procedures. Note from the Geek Central Human Relations Department:
be careful how you phrase these sorts of questions. An annoyed,
“What did you do this time, you pinhead?!” tends to cause people
to clam up. Your goal, remember, is to extract information.
■ Questions designed to find out exactly what any error messages said and
the context of the error. This information can be critical when you
need to search manufacturers’ knowledge bases and support lines.
■ Questions designed to find out what the user has tried to do to fix the problem.
This information can help you determine whether you are dealing
with multiple layers of problems. Many users will try to fix things,
but won’t think to write down what they’re doing. When at some
point in the process they reach a standstill and can’t get back to
where they started, they will come crying to you for help. Be gentle!
Your goal is to get the user to remember most, if not all, of the steps
they tried, so you can backtrack to the original problem rather than
troubleshooting a multilayered one.

Another touchy tool you can use is to compare the current situation to
the baselines and documentation you created for your network. When users
complain of slow connections or downloads, for example, you should com-
pare the bandwidth and connection speeds from your baseline to what you

529
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 530

are able to test while the problem

Try This! exists. You may find that the diffi-
culty lies more with the user’s ex-
Roleplay
pectations than any real network
You can try out the touchy skills with a partner (classmate, friend, fam-
problem. You can then decide
ily member—any of these will do nicely) pretty easily by roleplaying.
whether to upgrade your systems
Ask your partner to come up with a computer- or technology-related
and connectivity, or explain to
problem, and then ask them questions. Try to focus your questions by
your users the limitations of the
using the touchy skills. Don’t accuse your partner of breaking whatever,
network.
for example, but rather figure out whether it worked in the past or not.
The most complicated touchy
Run through several sessions of roleplay with the same partner so you
tool to describe and quantify is the
can get a good sense of how to create scenarios (my PC is dead, I can’t
network knowledge you have that
access the network, and so on) that are fully developed.
you can apply to your network’s
problems. The Network+ exam contains many network troubleshooting
questions that you should be able to answer, not from reading this chapter,
but from reading the rest of the book. Troubleshooting often comes down to
applying prior knowledge in a new way. You know, for example, that an IP
address, a subnet mask, and a default gateway are all necessary if your net-
work is to communicate with the Internet using the TCP/IP protocol. Edgar
complains that he cannot connect his Windows XP client to the Internet. His
hardware seems to be functioning correctly (link lights are on and he con-
nects to the server) and the proxy server is up. At that point, you might
check his TCP/IP configuration by using the IPCONFIG utility. If you no-
tice that he has no default gateway, you have solved the problem. The
knowledge to solve this problem came partially from understanding how to
troubleshoot by eliminating possibilities, but it also came from your knowl-
edge of the elements required to connect a machine to the Internet. As you
prepare for the exam, and for administering your company’s network, ask
yourself how each thing you learn about networking could be applied to-
ward troubleshooting the network. This prepares you for the time when you
have to make that leap.

Hardware Tools
In Chapter 8, “Installing a Physical Network,” you read about a few hard-
ware tools you use when configuring your network. These hardware tools
include cable testers, protocol analyzers, hardware loopback devices, and
toners. These tools can also be used in troubleshooting scenarios to help you
eliminate or narrow down the possible causes of certain problems. In addi-
tion, there are other pieces of hardware which, although they can’t actively
be used for troubleshooting, can pro-
Cross Check vide clues to the problems you face.
A cable tester enables you to de-
Connecting to the Internet termine if a particular cable is bad.
This chapter assumes you have the tools needed by PCs to connect to Bad can be defined in a variety of
the Internet pretty much nailed down in your mind, so now is a good ways, but it essentially means that
time to cross-check your memory! Turn to Chapter 11, “TCP/IP,” and the cable is not delivering the data
see if you can answer these questions. What’s the purpose of the default for whatever reason—perhaps the
gateway? How does this gateway manifest on a network? Why do you cable is broken, crimped badly, or
need an IP address? Wouldn’t a MAC address suffice? And what’s the sits too close to a heat or electrical
point of a subnet mask? source. In most troubleshooting

530
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 531

situations, you will use other clues to determine if you have a hardware or
software problem. Then, if you have narrowed down the problem to a hard-
ware connectivity issue, a cable tester can help you determine if the cable is
good or bad. Another option, if you are without one of these tools, is to re-
place the cables (one at a time) and test the connectivity. In the “I can’t log
on” scenario, for example, if you have determined that everyone else in the
area can log on, and that this user can log on from another location, you have
narrowed the problem to either a configuration or hardware issue. If all net-
work activity is broken (in other words, nothing is available in Network
Neighborhood or you cannot ping the default gateway), you may choose to
test cables connecting the PC to the server. This is not the only option, but it
is one variable that can be tested and eliminated.
Protocol analyzers come in both hardware and software flavors. Most of
the hardware analyzers have an additional software component. These
tools enable administrators to determine what types of traffic are flowing
through their networks. Most analyzers translate the packets flowing over
the network to provide destination, source, protocol, and some information
about content. In a situation where you have a network slowdown, you
might use a protocol analyzer to determine what types of packets are pass-
ing over your network, and where they are originating. In some cases, a dy-
ing network card can produce large numbers of spurious packets, which can
be detected by using a protocol analyzer and noticing that all of the packets
are coming from one location. Once you have narrowed your problem
down to a particular machine, you can concentrate on that rather than
blaming your servers, bandwidth, or other elements.

Software Tools
Throughout the book, you have read about software tools for configuring
your network that can also be applied to troubleshooting. Because most of
these have been described in previous chapters, I’ll just review the basic
purposes of these tools here. Key software troubleshooting tools include the
following:
■ Software-Based Protocol or Network Analyzers These include
applications such as the Network Monitor (NetMon) provided
with most versions of Windows. Also called packet sniffers, such as
the popular Ethereal, included with the CD in this book, network
analyzers collect and analyze individual packets on a network to
determine bottlenecks or security breaches. Use these tools when
you have unexplained slowdowns on your network, to help determine
which machines are sending packets. This enables you to determine
if there is too much broadcasting in general, or if you are the victim
of some more sinister event like a hacker attack.
■ System Logs Applications like Windows NT/2000/XP/2003’s
Event Viewer create system logs that display any errors or problems
that have occurred in your system. If a user repeatedly fails at his logon,
for example, this might be recorded in the appropriate view in the
Event Viewer tool. That information could be the clue you need to
determine that the user is locked out, either because he forgot his
password or because someone has been trying to hack into that

531
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 532

account. Logs also provide information on services or components of

the operating system that won’t start or are receiving errors. This is
a good way to troubleshoot system crashes on a particular machine.
■ Performance Monitors Tools like the Performance Monitor
mentioned earlier in this chapter can provide clues to the utilization
pattern of a particular machine. When users complain of slowdowns
or logon problems that can be traced to a specific system or server,
this tool can often give you clues as to what’s happening on that
system that could be causing problems. For example, if a system is
going to 100 percent memory utilization when a particular application
is started, it may mean that you need more RAM, or perhaps that
you need to put that application on a dedicated server. Use this
tool for troubleshooting when you have tracked the problem to a
particular machine and now must determine where in that machine
the bottleneck exists.

Your Toolbox
It always amazes me when a person calls and asks me what tools they need
to become a network tech. My answer is always the same: just your brain—
everything else will pretty much appear when you need it. There is no such
thing as the correct network tech’s toolbox, full of hardware and software
tools you haul around to get networks fixed. I certainly don’t haul around
cable testers, toners, or Time Domain Reflectometers (TDRs). I may bring
them along if I suspect a cabling problem, but I normally won’t dump them
in my backpack until after I suspect a problem.
Software tools all come with the network operating systems themselves.
I don’t need a floppy disk with PING, for example, because it’s on every PC
in the house! The software tools you need to fix a network are sitting there,
ready for you to use. Your task is to know how to use them. It’s the know-how
you need to bring, and in most cases, little or nothing else!
My lack of dependence on a toolkit makes some customers unhappy—
they just can’t reconcile in their minds that I can get their networks up and
running without some big toolbox. At times this has become so much of an
issue that I have brought along a toolkit just to look good! Seriously! I call
that box full of stuff my prop because it’s of no more real use than a rubber
stage sword.
Now that we’re no longer obsessing on carrying the right tools, let’s in-
stead concentrate on the real toolbox—your brain. In an amazingly brazen act
of self-confidence, I have taken the liberty of quantifying the many mental
processes you should use when fixing networks into the following section.

■ The Troubleshooting Process

Troubleshooting is a dynamic, fluid process that requires you to make snap
judgments and act on them to try and make the network go. Any attempt to
cover every possible scenario would be futile at best, and probably also not
in your best interests, because any reference that tried to list every trouble-
shooting problem would be obsolete the moment it was created. If an

532
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 533

exhaustive listing of all network problems is impossible, then how do you

decide what to do and in what order?
Before you touch a single console or cable, you should remember two
basic rules: as the Greek/Roman physician Galen wisely admonished,
“First, do no harm.” If at all possible, don’t make a network problem bigger
than it was originally. This is a rule I’ve broken thousands of times, and you
will too. But if we change the good doctor’s phrase a bit, it’s possible to for-
mulate a rule you can live with: “First, do not trash the data!” My gosh, if I
had a dollar for every megabyte of irreplaceable data I’ve destroyed, I’d be
rich! I’ve learned my lesson, and you should learn from my mistakes: Al-
ways make good backups! The second rule is to create baselines (that is,
data on how the network runs when nothing is broken). Backups enable you
to rebuild a trashed system. Baselines enable you to compare your net-
work’s current performance to how it behaves when all is well. Both of these
steps should precede any actual troubleshooting activity on your part.
Once you’ve done your backups and baselines, and it’s time to start typ-
ing commands or yanking cable, you need a plan. You need to know what
steps to take and in what order. These steps are pretty much universal to all
network problems, and you should learn them well. You also need a guide
to where you should look in the network for problems. For that job, I will
gift you with what I modestly call Mike’s Four-Layer Model . As in trouble-
shooting, so in this chapter—first, backups and baselines, and then you can
start taking troubleshooting steps with my model to guide you.

Backups
Think about how much work you have done to create nice, stable servers,
responsive workstations, and overall network wonderfulness. Imagine how
many hours your users have spent creating data and storing it on those serv-
ers. Now imagine a virus deleting critical data or configuration files—not a
good situation, for either your blood pressure or your job security. Simple
common sense dictates that you create backups of your data. Repeatedly.
Backups are useless unless they are current. Your users won’t thank you for
restoring a three-week-old copy of a file that gets updated daily. You should
therefore create a backup schedule for your data that ensures it’s backed up
often enough that a useful copy can be restored easily. Your backup plan
should include the following details:
■ When the backups will occur and what the tape rotation schedule
will be
■ What types of backups will be done at each time
■ Where the backups will be stored

Perhaps the most important details are the types of backups and the
schedule, or strategy, for the backups.

What Are the Types of Backups?

The goal of backing up data is to ensure that when a system dies, there will
be an available, recent copy you can use to restore the system. You could
simply back up the complete system at the end of each day—or whatever in-
terval you feel is prudent to keep the backups fresh—but complete backups

533
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 534

can be a tremendous waste of time and

materials. Instead of backing up the entire
system, take advantage of the fact that all
the files won’t be changed in any given pe-
riod; much of the time you only need to
back up what’s changed since your last
backup. Recognizing this, most backup
software solutions have a series of options
available beyond the old complete (usu-
ally called Full or Normal) backup.
The key to understanding backups
other than the full backup is a little fellow
• Figure 20.1 The archive bit called the Archive attribute. All files have
little 1-bit storage areas called attributes.
The most common attributes are Hidden (don’t show the file in My Com-
puter or when DIR is typed at the command line), System (it’s a critical file
Tech Tip for the system), Read-Only (can’t erase it), and the archive bit. These attrib-
Customizing utes were first used in FAT-formatted drives in the DOS era, but they are
Explorer in Windows XP still completely supported today by all file formats. The archive bit works
Windows Explorer / My basically like this: whenever a file is saved, the archive bit is turned on. Sim-
Computer in Windows XP by ply opening a file will affect the current state of the archive bit. Backup pro-
default does not show much grams will usually turn off a file’s archive bit when it’s backed up. In theory,
about files in any view, even if a file’s archive bit is turned off, it means there’s a good backup of that file
when you select Details from the on some tape. If the archive bit is turned on, it means that the file has been
View menu. The Details view is
changed since it was last backed up (see Figure 20.1).
highly customizable, however,
Archive bits are used to perform backups that are not full backups. The
and can reveal a phenomenal
amount and variety of informa-
following backup types are most often supported:
tion about files. To customize ■ A normal backup is a full backup. Every file selected will be backed
your view, alternate-click (right- up, and the archive bit will be turned off for every file backed up.
click) the column bar (the gray This is the standard “back it all up” option.
bar that says Name, Size, Type,
Date Modified, and so forth) to ■ A copy backup is identical to a normal backup, with the important
look at the default choices. You’ll distinction that the archive bits are not changed. This is used
see everything from Attributes, (although not often) for making extra copies of a previously
Owner, Author, and Title, to file- completed backup.
type specific information such as
■ An incremental backup includes only files with the archive bit
Genre, Duration, and Bit Rate (for
turned on. In other words, it copies only the files that have been
music files). If the 15 default extra
view options don’t get your motor
changed since the last backup. This backup turns off the archive bits.
revving, selecting the More option ■ A differential backup is identical to an incremental backups, except
brings up a menu offering 32 view that it doesn’t turn off the archive bits.
options! For the purposes of this
■ A daily backup , also known as a daily copy backup , makes copies of
section, click the Attribute box to
display file and folder attributes.
all the files that have been changed that day. It does not change the
archive bits.

The motivation for having both the incremental and differential backups
may not be clear at first glance—they seem so similar as to be basically the
Be sure you know the differ- same. Incremental seems the better option at first. If a file is backed up, you
ent types of backups, including
would want to turn off the archive bit, right? Well, maybe. But there is one
which ones change the archive
bits and which ones do not. scenario where that might not be too attractive. Most backups do a big
weekly normal backup, followed by daily incremental or differential

534
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 535

backups at the end of every business day. Figure 20.2

shows the difference between incremental and
differential backups.
Notice that a differential backup is a cumulative
backup. Because the archive bits are not set, it keeps
backing up all changes since the last normal backup.
This means the backup files will get progressively
larger throughout the week (assuming a standard
weekly normal backup). The incremental backup,
by contrast, only backs up files changed since the
last backup. Each incremental backup file will be rel-
atively small and also totally different from the pre-
vious backup file. Let’s assume that the system is
wiped out on a Thursday morning. How can you re-
store the system to a useful state? If you’re using an • Figure 20.2 Incremental vs. differential
incremental backup, you will first have to restore the
last weekly backup you ran on Monday, then the
Tuesday backup, and then the Wednesday backup before the system is re-
stored to its Thursday morning state. The longer the time between normal
backups, the more incremental backups you must restore. Using the same
scenario, but assuming you’re doing differential instead of incremental
backups, you’ll only need the weekly backup, and then the Wednesday
backup to restore your system. A differential backup will always require
only two backups to restore a system (see Figure 20.3). Suddenly, the differ-
ential backup looks better than the incremental! On the other hand, one big
benefit of incremental over differential is backup file size. Differential
backup files will be massive compared to incremental ones.
Choosing between incremental backups and differential backups is only
one factor in choosing how you back up your data. You must also consider
your business, your data, your backup hardware, your operating systems,
and other factors to create a backup strategy.

Backup Strategies
One of the issues you must address to successfully answer questions on
backups and recoverability is how to choose strategies that meet your needs
for doing backups and restores in your actual network environment. Your
goal is to be able to back up, and then easily restore all the nec-
essary information from all the necessary machines. This can
include both servers and workstations. Decisions about back-
ing up multiple machines can revolve around both hardware
and time factors. Another issue to consider when planning
your backup strategy is what to do with the all-important
tapes. Recognize that you are protecting your network not
only against viruses and other computer-related disasters, but
also against fire, flood, and man-made catastrophes. Let’s look
at a typical network and see how to create a backup strategy.
Shannen works at a small company that has never had any
form of reliable backup. The network consists of a single Win-
dows Server 2003 system that acts as a file server for the entire
network. The file server stores an Access databasea single
.MDB fileconstantly updated during the course of the • Figure 20.3 Restoring from backups

535
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 536

business day by almost every user on the network. Each of the client sys-
Tech Tip tems also stores a number of mission-critical Word documents.
Shannen first determines what data needs backing up. She needs to back
Full System Backups
Ever wish you could back up your
up the entire server operating system—about 1.3GB for the operating sys-
entire system? Sure, Windows tem and applications. The Access database is roughly 45MB and hasn’t
has plenty of recovery tools, but grown much in the past year. She then goes through the many Word docu-
they’re not always perfect. Tools ments stored on each user’s system, creates a directory called \Home on the
such as System Restore and the file server with a subfolder for each user, and instructs the users to copy
recovery console are useless if their Word documents to their individual subfolders. Combined, the Word
your hard drive dies. In some documents take up roughly 100MB.
companies, entire systems are This is an interesting side effect of backups. Creating a backup strategy
backed up using a number of often forces network administrators to change the way their network stores
products. These backups are often data. Shannen will also have to enforce a policy (lots of finger wagging and
stored on optical media or on
reminder e-mails) for users to save their work to the server. Perhaps a bit of
massive server drives on the net-
training might also be in order!
work. Although full system back-
ups can be complex to use and
Shannen didn’t have to force the users to copy their data to the server
challenging on your network just for backing up. Many companies sell superb, powerful backup software
bandwidth, the ease of system re- that will enable the administrator to back up multiple systems in almost any
covery makes this approach popu- way he or she might imagine. A single backup job can back up entire sys-
lar for those “I need my computer tems or selectively back up only certain folders on each system. This type of
back NOW!” situations. online backup is popular today. You can even find companies that will back
up your systems over the Internet for a monthly charge.
Now that Shannen has a grasp on the data to back up, she turns her at-
tention to her backup hardware. She has a DLT tape drive with 30-GB capac-
ity tapes—far more than her needs of less than 2GB with plenty of room for
future expansion. This also tells her that a single tape will hold multiple
backupsa handy thing to do to save on tapes! Shannen chooses to use a
differential backup method. She’ll need two tapes: one for the weekly full
backup and one for the daily changes.
Shannen has two more issues to deal with: offsite backups and tape wear
and tear. Backup strategies require some method of rotation of tapes to en-
sure that one backup is offsite in case of a serious disaster, to prolong tape
life, and to retire older tapes. This is called a tape rotation method or a tape
backup scheme. Shannen chooses to use a tape rotation method called Grand-
father-Father-Son. This tried-and-true method has many variations, but the
one Shannen uses works like this. The tape she uses for backup on the last
Friday of each month is called the grandfather tape. She stores this tape
offsite. The tape she uses every Friday (except the last Friday of the month)
is the father tape and is also stored offsite. The tape used for the daily
backup (except on Friday) is called the son. Shannen keeps these tapes
onsite. If a fire wipes out the office,
Try This! she’ll have a complete server
backup that is always less than a
Tape Rotation Methods week old offsite.
Grandfather-Father-Son is only one of many tape rotation methods. Do
a web search for tape rotation methods such as Grandfather-Father-Son,
Tower of Hanoi, and Incremental. Don’t confuse Incremental tape rota- Baselines
tion with the incremental backups—they aren’t the same thing! What The best way to know when a
are the benefits and disadvantages of these different methods? Can you problem is brewing is to know
come up with situations where one tape rotation method might have how things perform when all’s
advantages over another? well with the system. You need to

536
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 537

establish a baseline: a log of performance indicators such as CPU usage, net-

work utilization, and other values to give you a picture of your network and
servers when they are working correctly. A major change in these values can
point to problems on a server or the network as a whole. A common tool
used to create a baseline on Windows systems is the Performance Monitor
utility that comes with Windows NT/2000/XP/2003. Conveniently, all net-
work operating systems come with similar tools, and you can also create
baselines using most network management utilities.

Windows NT/2000/XP/2003—Performance Monitor

Administrators use Performance Monitor (also called PerfMon ) to view the
behavior of hardware and other resources on NT/2000/XP/2003 machines,
either locally or remotely. PerfMon can monitor both real time and historical
data about the performance of your systems. To access the Performance
Monitor applet, choose Start | Programs | Administrative Tools | Perfor-
mance Monitor from any Windows NT machine. On a Windows 2000 sys-
tem, choose Start | Settings | Control Panel, and then double-click
Administrative Tools, and double-click Performance.
Once you access PerfMon, you need to configure it to display data—but
first, you must understand the concepts of objects, counters, and views. An
object , in Performance Monitor terms, is the component of your system you
want to monitor, such as the processor or the memory. Each object has dif-
ferent measurable features, called counters . Counters, in other words, are
the aspects of an object that you want to track. As you decide which object(s)
to monitor, you must also select at least one counter for each object. Per-
formance Monitor can organize and display selected counter information
using a variety of views , each of which provides different types of informa-
tion. The Log view, for example, enables you to store data about your system
for later review. This is the view you use to create a baseline. Although it’s
the only one I’m going to discuss here, the other views—Chart, Alert, and
Report—are useful for troubleshooting problems as they arise.
To access the Log view in Windows NT, either click the Log View button
or choose View | Log. To add objects to the Log view, either click
Add To (the plus sign) or choose Edit | Add To Log. In the Add
To Log dialog box, first select the computer you want to monitor.
You can choose either the local machine (the default) or a remote
machine. To monitor a remote machine, type the Universal Nam-
ing Convention (UNC) name of the computer in question. To
monitor a machine named HOUBDC1, for example, you would
type \\HOUBDC1 in the Computer field. You can also use the
Select Computer button (at the right end of the Computer field)
to view the available machines and select the one you want to
monitor, as shown in Figure 20.4.
Although it is usually easier to monitor a machine locally, it
is often more accurate to monitor a machine remotely. PerfMon
itself, as it runs on a machine, uses a certain amount of that sys-
tem’s resources to take the measurements and display the data
graphically. You can corrupt your results by monitoring locally,
especially when you need to troubleshoot problems with disk
performance, memory and paging, or processor use. There are • Figure 20.4 The Select Computer dialog box in
some cases where monitoring locally is preferred or required, Performance Monitor

537
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 538

however. If you are monitoring network access or net-

working protocol objects, for example, monitoring lo-
cally will affect the readings to a lesser degree than
monitoring remotely. Similarly, you must monitor a
system locally if you can’t access that system over the
network. Finally, when you monitor objects created
by a specific application, such as Exchange, you
should monitor locally, as the objects related to this
application are only created locally and will not be
available from another system.
Once you have selected a system to monitor, ei-
ther locally or remotely, you must select the object to
• Figure 20.5 Add To Log in Performance Monitor
monitor. Select one or more objects to monitor from
the list in the Object field. Note that the Log view is
somewhat different from the other views, in that you only add objects to the
view, not the specific counters for the objects, as shown in the Add To Log
dialog box in Figure 20.5.
After you select the objects for the Performance
Monitor to track and log, select Options | Log Op-
tions to save the data to a log file, and then start
logging by clicking the Start Log button, as shown
in Figure 20.6. This dialog box also gives you the
opportunity to select the update method and time.
After you have configured the log to save to a
particular file, you can see the log file name, status
of the logging process, log interval, and file size of
the log in the Performance Monitor dialog box. To
stop collecting data in a log, open the Log Options
dialog box again and click Stop Log. You can then
choose to create a new Log file and begin logging
again, if necessary. You can also view data from
one of these saved log files by selecting Options |
Data From. In the Data From... dialog box, shown
in Figure 20.7, you can choose to continue obtain-
ing data from the current activity, or obtain data
from a particular log file.
• Figure 20.6 Select a log file (1) and start logging (2) in Performance When you choose to obtain data from a saved
Monitor. log, you go back to that frozen moment in time and
add counters to the other views for the objects you
chose to save in the log. In our Log options, for example, we chose to
store data for the Logical Disk object. After we’ve loaded that par-
ticular log file, we can change to the Chart view, add counters there
for the Logical Disk object, and view a static chart for that moment
in time (see Figure 20.8). You may want to select a wide variety of
objects to save while in Log view, so that when you open the log to
display in any of the other views (Chart, Alert, and Report), you can
add a wide range of counters.
The Performance Monitor utility described here is specific to
Windows NT systems, but you should create baselines for what-
ever types of systems you have, and they should cover all aspects of
• Figure 20.7 The Data From... dialog box in
your network. Be certain to create multiple baselines, to show the
Performance Monitor

538
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 539

• Figure 20.8 Viewing a static chart in Performance Monitor

systems both at rest and in use, using the Performance Monitor as well as
other systems management or network sniffer tools.

NetWare—Console Monitor
On a NetWare server, most of the critical information you might need to see
and document to establish your baseline can be obtained by loading the
Console Monitor application (see Figure 20.9) on the server itself. You can
view the program remotely on a client PC, but it only runs on the server.
Novell NetWare calls a program that runs on the server in this way a

• Figure 20.9 The NetWare 5 Console Monitor general information screen

539
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 540

NetWare Loadable Module (NLM) . You issue the command LOAD

MONITOR at the server’s console prompt to start the program.
The Console Monitor NLM can display a wide range of information,
from memory use to individual statistics about the network interface cards
(NICs) installed in the server. Many system managers leave Console Moni-
tor running all the time so they can keep an eye on things. It can also be used
to kick users off the server and see which files they’re accessing!

Using Baselines
Using baselines requires a serious commitment. Not only do you need to
create them in the first place, you need to monitor them continually to know
when changes take place. Be careful not to be fooled by a bad baseline
make a number of baselines at first to get an idea as to when your network is
most quiet and when it’s most busy. Many administrators like to make dual
baselines: one for when the network/server is at rest and another when the
network/server is at its busiest. This is a matter of personal choicetry both
the single baseline and the dual baseline to see which you prefer.

Troubleshooting Model
No matter how complex and fancy, any troubleshooting model can be bro-
ken down into simple steps. Having a sequence of steps to follow makes the
entire troubleshooting process simpler and easier, because you have a clear
set of goals to achieve in a specific sequence. The most important steps are
the first three—they help you narrow down the cause of the problem to a
specific item. The reason this matters so much is that figuring out what’s
wrong will also probably tell you how to fix the problem, and how to pre-
vent it from happening in the future.
The basics of any troubleshooting model should include the following
steps:

1. Establish the symptoms.

2. Isolate the cause of the problem (identify the scope of the problem).
3. Establish what has changed that might have caused the problem.
4. Identify the most probable cause.
5. Implement a solution.
6. Test the solution.
7. Recognize the potential effects of the solution.
8. Document the solution.

Establish the Symptoms

If you are working directly on the affected system and not relying on some-
body on the other end of a telephone to guide you, you will establish the
symptoms through your observation of what is (or isn’t) happening. If
you’re troubleshooting over the telephone (always a joy, in my experience),
you will need to ask questions based on what the user is telling you. These

540
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 541

questions can be close-ended, which is to say there can only be a yes or no

type answer, such as, “Can you see a light on the front of the monitor?” You
can also ask open-ended questions, such as, “Tell me what you see on the
screen.” The type of question you use at any given moment will depend on
what information you need, and on the knowledge level of the user. If, for
example, the user seems to be technically oriented, you will probably be
able to ask more close-ended questions, because they will know what you
are talking about. If, on the other hand, the user seems to be confused about
what’s happening, open-ended questions will allow him to explain what is
going on in his own words.

Isolate the Cause of the Problem

One of the first steps in trying to determine the cause of a problem is to un-
derstand the extent of the problem—is it specific to one user or is it network-
wide? Sometimes this entails trying the task yourself, both from the user’s
machine and from your own or another machine.
For example, if a user is experiencing problems logging in to the net-
work, you might need to go to that user’s machine and try to use their user
name to log in. This will tell you whether the problem is a user error of some
kind, as well as enable you to see the symptoms of the problem yourself.
Next, you probably want to try logging in with your own user name from
that machine, or have the user try to log in from another machine. In some
cases, you can ask other users in the area if they are experiencing the same
problem, to see if the problem is affecting more than one user. Depending on
the size of your network, you should find out if the problem is occurring in
only one part of your company, or across the entire network.
What does all of this tell you? Essentially, it tells you how big the
problem is. If nobody in an entire remote office can log in, you may be
able to assume that the problem is the network link or router connecting
that office to the server. If nobody in any office can log in, you may be able to Eliminating variables is one
assume that the server is down or not accepting logins. If only that one user of the first tools in your arsenal
in that one location can’t log in, it may be a problem with that user, that ma- of diagnostic techniques.
chine, or that user’s account.

Establish What Has Changed That Might Have Caused the Problem
After determining the extent of a problem, the next step is to eliminate all
the extra variables, that is, all the incorrect possible causes of the problem. If
you have determined that the problem is specific to that user on that ma-
chine, you have already learned a great deal. First, you have learned that
this isn’t a user account problem, because that user was able to log in from
another machine. You have also determined that it isn’t user error, because
you’ve tried it yourself. By having other users at other machines success-
fully try the task, you eliminated the possibility that the server is down.

Ask Isolating Questions

The goal of this step is to isolate the problem to a specific item (hardware,
software, user error, and so on), or to identify what has changed that might
have caused the problem. You may not have to ask many questions before
the problem is isolated, but it can sometimes take quite a bit of time and

541
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 542

involve further work behind the scenes. Isolating questions are designed to
home in on the likely cause of the problem. Here are some examples:
■ “Tell me exactly what you were doing when the problem occurred.”
■ “Has anything been changed on the system recently?”
■ “Has the system been moved recently?”

Notice the way I’ve tactfully avoided the word you, as in “Have you
changed anything on the system recently?” This is a deliberate tactic to
avoid any implied blame on the part of the user. Being nice never hurts and
it makes the whole troubleshooting process more friendly.
You should be asking some isolating questions internally of yourself,
such as, “Was that machine involved in the software push last night?” or
“Didn’t a tech visit that machine this morning?” Note that you will only be
able to answer these questions if your documentation is up to scratch. Some-
times, isolating a problem may require you to check system and hardware
logs (such as those stored by some routers and other network devices), so
make sure you know how to do this.

Identify the Most Probable Cause

This step comes down to experience—or good use of the support tools at your
disposal, such as your knowledge base. You need to select the most probable
cause from all the possible causes, so the solution you choose fixes the problem
the first time. This may not always happen, but whenever possible, you want
to avoid spending a whole day stabbing in the dark while the problem snores
softly to itself in some cozy, neglected corner of your network.

Implement a Solution
Once you think you have isolated the cause of the problem, you should de-
cide what you think is the best way to fix it, and then try your solution,
whether that’s giving advice over the phone to a user, installing a replace-
ment part, or adding a software patch. All the way through this step, try
only one likely solution at a time. There’s no point in installing several
patches at once, because then you can’t tell which one fixed the problem.
Similarly, there’s no point in replacing several items of hardware (such as a
hard disk and its controller cable) at the same time because then you can’t
tell which part (or parts) was faulty. As you try each possibility, always doc-
ument what you do and what results you get. This isn’t just for a future prob-
lem, either—during a lengthy troubleshooting process, it’s easy to forget
Remember these problem exactly what you tried two hours before, or which thing you tried produced
analysis steps:
a particular result. Although it may take longer to be methodical, it will save
■ Establish the symptoms time the next time—and it may enable you to pinpoint what needs to be
■ Isolate the cause done to stop the problem from recurring at all, thereby reducing future call
■ Establish what has changed volume to your support team—and as any support person will tell you,
■ Ask isolating questions that’s definitely worth the effort!
■ Identify the most probable
cause Test the Solution
■ Implement a solution This is the part everybody hates. Once you think you’ve fixed a problem, you
■ Recognize potential effects should try to make it happen again. If you can’t, great! But sometimes you
of the solution
will be able to re-create the problem, and then you know you haven’t finished
■ Document the solution
the job at hand. Many techs want to slide away quietly as soon as everything

542
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 543

seems to be fine, but trust me on

this, it won’t impress your cus-
Try This!
tomer when their problem flares Mnemonic for Troubleshooting
up again 30 seconds after you’ve How will you remember these eight troubleshooting steps? Create a
left the building—not to mention mnemonic for the steps that you can use to cement them into your brain.
that you get the joy of another two- Pick a theme, such as food or colors, and make the mnemonic—the
hour car trip the next day to fix the memory tool—work. Don’t be afraid to be silly or funny, just go for
same problem, for an even more something memorable!
unhappy client! In the scenario
where you are providing support to someone else rather than working di-
rectly on the problem, you should make them try to re-create the problem.
This will confirm whether they understand what you have been telling them,
and will educate them at the same time, lessening the chance they’ll call you
back later and ask, “Can we just go through that one more time?”

Recognize the Potential Effects of the Solution

Okay, now that you have changed something on the system in the process of
solving one problem, you must think about the wider repercussions of what
you have done. If you’ve replaced a faulty NIC in a server, for instance, will
the fact that the MAC address has changed (remember, it’s built into the
NIC) affect anything else, such as the logon security controls, or your net-
work management and inventory software? If you’ve installed a patch on a
client PC, will this change the default protocol or any other default settings
that may affect other functionality? If you’ve changed a user’s security set-
tings, will this affect their ability to access other network resources? This is
part of testing your solution to make sure it works properly, but it also
makes you think about the impact of your work on the system as a whole.

Document the Solution

It is vital that you document the problem, symptoms, and solutions of all sup-
port calls, for two reasons. First, you’re creating a support database that will
be a knowledge base for future reference, enabling everyone on the support
team to identify new problems as they arise, and know how to deal with them
quickly, without having to duplicate someone else’s research efforts. Second,
documentation enables you to track problem trends and anticipate future
workloads, or even to identify a particular brand or model of an item, such as
a printer or a NIC, that seems to be less reliable or that creates more work for
you than others. Don’t skip this step—it really is essential!

Troubleshooting as Art—
Mike’s Four-Layer Model
Troubleshooting is not something that can be definitively described in a nice
neat list of ten easy steps. It is more of an art—an ability to become “one with
the network” and intuit where the problems are hiding. The best trouble-
shooters are those who have a huge amount of knowledge about every ele-
ment of the network—hardware, software, connections, and so on. These
people can then synthesize all that knowledge into good guesses about where
to start looking for problems. All of the previous steps give you a theoretical
concept of where to look and how to proceed when troubleshooting your

543
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 544

own network. The theory, however, is easier to implement in real life if you
know where (and where not) to look within the network to find the problem.
The troubleshooting model does a great job of describing the steps nec-
essary to get a network problem fixed, but it doesn’t tell you where to look in
the first place. So how do you figure out where to look for problems? Some
might think to use the OSI seven-layer model, but while the OSI seven-layer
model provides a superb tool for those who create network hardware and
software, it doesn’t do a lot for the folks who need to work on a network ev-
ery day. Instead, I use a model that I modestly call Mike’s Four-Layer
Model. The Four-Layer Model concentrates on the main components of the
hardware and software you need to deal with to make a networking system
work, while ignoring the parts of the hardware and software over which
you have no control. The core idea behind the four layers of my model is that
you can access, change, remove, install, troubleshoot, and fix every layer—
unlike most of the layers of the OSI seven-layer model.
The Four-Layer Model breaks all networks into—surprise!—four major ar-
eas: Hardware, Protocols, Network, and Shared Resources. No matter what
specific networking hardware or software you use, every one of these four lay-
ers exists—although some network operating systems like to hide them! If you
The layers of Mike’s understand Mike’s Four-Layer Model, you should have no problem fixing just
Four-Layer Model are about any network, any time. By using the Four-Layer Model when you have a
1. Hardware problem with a network, you’ll never find yourself saying, “I have no idea why
2. Protocols this is happening to my network! What do I do?” Instead, you’ll find yourself
3. Network
saying, “I know why this problem exists. I just need to figure out how to fix it!”
Trust me, figuring out how to fix a known problem is a lot easier than trying to
4. Shared Resources
troubleshoot a mystery problem on your network.
Mike’s Four-Layer Model also ignores the function of the layers and con-
centrates instead on what you need to do to make the layers function (that is,
what you do to verify that a particular layer works correctly or needs diag-
nosing). For example, if you’ve installed the hardware correctly, then the
hardware layer works. To determine this, you run a certain type of test (like
pinging another system), and if you’re successful, you in essence check off
the hardware layer as good and move on to the next one.
Some of my critics suggest that if diagnostic success is the goal, then my
Four-Layer Model is by definition not a true model; they argue that it’s
nothing more than a diagnostic procedure. These people do have a point—if
you get technical about it, my Four-Layer Model is nothing more than a di-
agnostic procedure. Here’s what I have to say to those critics: “Well, it’s the
best darn totally-universal, easy-to-understand, 100-percent-accurate, prac-
tical diagnostic procedure you’ll ever meet! Six weeks after the Network+
exam, you’ll probably have forgotten most of the seven OSI layers, but
you’ll never forget my model!” Why? Because you’ll use it every day!
I once had a reader e-mail me about the Four-Layer Model. She said I
should change its name to Mike’s Four-Doors Model. Her suggestion for the
name change came from the fact that the four layers of my model seemed to
her like doorways to the innards of the network, rather than a true definition
of all network functions. In a way, she was right—my model does not define
all the functions of a network, like the OSI seven-layer model does. I ignore
or blend most of the OSI layers into my model because I want to deal with
things I can touch in the network. So, I guess the doorway analogy is a decent
way to think about my model, but I’m too lazy to change all my work so I’m
sticking to the name Four-Layer Model. Let’s look at each of its layers.

544
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 545

Hardware
Hardware is probably the most self-explanatory of the four categories. This Mike’s Four-Layer Model is in
layer covers the many different ways data can be moved from one PC to an- fact nothing more than this one
other, from copper to fiber to wireless signals. It includes the Physical and tech’s opinion of how best to fix
Data Link components of the OSI model, but concentrates on the parts that a network. It is neither an industry
standard nor that well-known—
make this all work, like hubs, cables, and connectors. It also includes items yet. It is not part of the Network+
that the OSI model does not directly address, like NICs, device drivers for test in any way, but it will help
NICs, and how you install and test them. you on the test by providing a
framework you can use to analyze
Protocols the many scenario questions
on the exam and quickly generate
I should call this section “Network Protocols,” but I don’t want you confus- correct answers.
ing it with the next one. Protocols are the languages of networks. As you’ve
learned, these languages have interesting names such as NetBIOS/
NetBEUI, IPX/SPX, and the ever-popular TCP/IP. A protocol is a highly
standardized language that handles most of the “invisible” functions on a
network, like determining which computer is SERVER1, or disassembling
and reassembling data passed over the network. Here we concern ourselves
with installing and configuring the protocol so that a system can communi-
cate with other systems on the network. We’re not too interested in how this
all works in great detail—the point here is that if you install the right
protocol and configure it properly, it will work.

Network
Once you install the hardware and the protocol, you need to make two criti-
cal determinations. First, you need to decide which systems will share re-
sources and which systems will only access those shared resources. In other
words, you must determine which systems will act as servers and which
will act as clients, and then configure them accordingly. Second, you need to
name the systems, so they can see each other, usually something like Server1
or Mike’s PC. In this layer, the concepts of client/server, peer-to-peer, and
domain-based networks come into play. Different network operating sys-
tems use different methods to name their systems and to determine which
systems share and which do not. This layer requires that you appreciate the
differences among programs like Windows, NetWare, and Linux.

Shared Resources
The entire reason we network is to share resources, so this final layer encom-
passes all the steps required to enable a system to share a resource, and to al-
low and enable other systems access to that shared resource. This layer
includes a number of steps, and unlike the earlier layers, these steps often
need to be done fairly frequently, because by their nature, shared resources
and the users who access them change pretty much continuously. This layer
includes most of the day-to-day administration of networks and tends to be
the place we spend the majority of our time.

Using the Four-Layer Model

The secret to using the Four-Layer Model to diagnose network problems is
to use it to structure your analysis when problems occur, and to proceed
through the layers as you diagnose the problem. Let me show you how I use
it by giving you a scenario.

545
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 546

I recently replaced an ancient router that had an ISDN Internet connec-

Tech Tip tion, with a new SOHO gateway DSL router, in a Windows 2000 network.
The Windows network had DNS, WINS, and DHCP servers for all the cli-
WINIPCFG
ents on the network. I configured the new router to use the same IP ad-
If you have Windows 9x/Me,
you can run the graphical dresses as the old router. When I went to a system to test the setup, I popped
utility WINIPCFG in place of right up on the Internet, no problem. I then fired up IPCONFIG and released
IPCONFIG. It accomplishes and renewed the IP address to make sure the new router worked. I got a new
the same goals, but like all good IP address and everything looked okay. Then I decided to browse the net-
GUI tools, it gives you buttons work—and I couldn’t see any other system! Not good. Time to use the Four-
to click instead of command Layer Model.
strings to type. To run the appli- First, the Physical layer—was I disconnected from the network, or was a
cation, go to Start | Run and piece of hardware broken? Not likely, given the fact that I could still get on
type WINIPCFG; click the OK the Internet. But I used PING to test the router—no problem. Then I pinged
button and you’re off!
the server and didn’t get an answer. Hmm, was there a cable problem be-
tween me and the server? I checked and saw good link lights all around.
Plus, everyone else was still hitting the server just fine. Time to assume the
Physical layer was okay.
On to the second layer, Protocol. I’m running TCP/IP, and it’s unlikely I
could get to the Internet if I had a problem there. But I still checked the sys-
tem with IPCONFIG. Wait a minute! A quick look reveals that my IP ad-
dress is 192.45.15.10, but the network ID I want is 192.168.4.0! This is
weird—where did this strange IP address come from? Well, I set up the
router for DHCP—maybe there’s a problem with the DHCP server. The net-
work admin checks and tells me it’s up and running. I want to verify this so I
go to another system and do a release/renew there. Lo and behold, sud-
denly IT has an IP address of 192.45.15.11! What’s going on here? I ask my-
self the million-dollar question: “What has changed on this network that
might have caused this?” The answer was easy: the only recent change to
the network was the new router. A quick examination reveals the problem:
The router was set up to do DHCP. I quickly shut off the router’s DHCP, and
then do another release/renew on the two systems with the bad IP ad-
dresses, and voilà, problem solved, and I’m on to the next job!
By using the Four-Layer Model, I could quickly remove physical issues
from the possible problems and move on to examine protocol issues, where
I found the problem. Try my Four-Layer Model for yourself—it works!

■ Troubleshooting Scenarios
I want to end this chapter and the book with some good troubleshooting sce-
narios. Take some time and think about these situations and how you would
handle them. What questions would you ask? What tests would you do
first? The Network+ exam absolutely loves to ask scenario questions. The
knowledge from the previous chapters combined with the methods you’ve
learned in this chapter should enable you to fix any network!

“I Can’t Log In!”

One of the most complex troubleshooting issues is that one set of symptoms,
in this case a user’s inability to log in, can have many causes. Suppose Woody
has called complaining that he cannot log in to the company’s intranet. Tina

546
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 547

Tech first tries accessing the intranet site from her workstation, and finds she
has no problem. Tina might also want to have other users try to log in, or con-
firm that other users are not having the same problem. Next, Tina should
have Woody try to log in from another machine. This will help Tina deter-
mine whether the problem lies with Woody’s user account’s capability to log
in, or with Woody’s Windows 98 workstation or connectivity.
If Woody is unable to log in from another machine, Tina should proba-
bly check to be sure Woody is using the correct login ID, password, and pro-
cedure when he logs in. On the other hand, if Woody is able to log in from
another user’s workstation, Tina should probably focus on determining
whether Woody’s workstation is working properly and connecting to the
network. One step she could try here is pinging Woody’s workstation. If
Tina is able to ping Woody’s machine successfully, she knows that the ma-
chine is up, the TCP/IP protocol is configured correctly, and the system is
connected to the network. Tina might then check the configuration of the
network client on Woody’s workstation. If Tina is not able to ping the work-
station, however, she might need to test the cables and NIC using cable test-
ers or loopback devices, and verify that TCP/IP was correctly configured
using WINIPCFG.

“I Can’t Get to This Web Site!”

Reaching external web sites requires that a variety of components be config-
ured correctly. Some of these components are within your company’s inter-
nal control; many of them are not. When Fatima calls and tells Tina Tech that
she cannot reach www.comptia.org, Tina’s first step is to try to reach that
site herself. In this case, Tina was also unable to get a response from the
comptia.org site. One of her next steps is to ping the site, first by name, and
then by IP address. In this case, she gets no response by name, but she does
get a normal response when she pings the site by IP address. This immedi-
ately indicates to her that the problem is name resolution, in this case: DNS.
On the other hand, had Tina been unable to ping successfully using ei-
ther the IP address or host name, she should consider two possibilities. First,
if her company uses a firewall or proxy server to reach the Internet, she
should ping that machine. This machine usually has the same IP address as
the default gateway TCP/IP setting. If Tina can successfully ping her de-
fault gateway, she can be almost certain that the problem is not something
she or her company has any control over. To verify this, Tina should attempt
to reach some other external sites, both by pinging and using a web browser.
If she can reach other sites successfully, the problem is most likely with the
comptia.org site or the gateway.

“Our Web Server Is Sluggish!”

Slow response from a server can be related to a variety of things. Usually,
however, the problem can be traced to a connection to the server, or to the
server itself. When Wanda calls in from working at home and tells Tina Tech
that she is getting a slow response from the company’s web site, Tina Tech
leaps into action. Tina tries to reach the offending server and is immediately
connected; this indicates a connectivity problem for that user. She asks
Wanda to execute a TRACERT command from her workstation to the slow

547
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 548

server. This reveals to Tina that the slowdown stems from one of the inter-
mediate steps through which Wanda’s system connects to the server. Be-
cause of this, the problem is out of Tina’s hands, unless she can offer a direct
dial-up option for Wanda.
If Tina finds she cannot reach the offending server quickly when she
tries from her workstation, then the problem may lie with the server itself.
Tina checks the Change Log for the web server, to see if anyone has changed
anything recently. She discovers a new anti-virus component was recently
added, so she checks the vendor’s web site to make sure there are no known
problems or patches for that piece of software. She also uses the Perfor-
mance Monitor to compare the server’s current responses to the baseline
that she previously recorded. This shows her that the bottleneck is related to
excessive paging, indicating that the server may need more physical
memory, or RAM.

“I Can’t See Anything in

Network Neighborhood!”
When a user is completely cut off from the network, the problem is usually
limited to that user’s workstation or network connection. When Tina gets a
call from Johnny saying his Windows 98 machine is on, but that he can’t log
in and can’t see any other machines on the company’s TCP/IP network,
Tina goes to Johnny’s office to run some tests. The first test Tina runs is to
ping an external machine. She doesn’t expect it to work, but tests just to be
certain. Next, she tries to ping Johnny’s machine using either ping localhost
or ping 127.0.0.1 (remember the loopback address?). When this ping doesn’t
work, Tina guesses that the problem is in the TCP/IP configuration. To view
the machine’s TCP/IP configuration, Tina uses WINIPCFG, and notices the
IP address is blank. After checking her network documentation to verify
what IP address Johnny’s machine should have, she adds the IP address and
he is able to connect to the network.
If Tina’s ping 127.0.0.1 had worked, she would have had to assume the
TCP/IP and networking configuration of Johnny’s machine was correct.
She should then check the hardware, using a network card utility to verify
that the NIC itself is working correctly, and a cable tester to verify that the
cable from Johnny’s workstation is operating properly. In this case, the cable
tester shows that the cable is bad, so she replaces the cable between Johnny’s
workstation and the patch panel, and he is able to connect.

Troubleshooting Is Fun!
The art of network troubleshooting can be a fun, frolicsome, and frequently
frustrating feature of your network career. By applying a good trouble-
shooting methodology and constantly increasing your knowledge of net-
works, you too can develop into a great troubleshooting artist. This takes
time, naturally, but stick with it. Begin the training. Use the Force. Learn
new stuff, document problems and fixes, talk to other network techs about
similar problems. Every bit of knowledge and experience you gain will
make things that much easier for you when crunch time comes and a net-
work disaster occurs—and as any experienced network tech can tell you, it
will, even in the most robust network.

548
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 549

Chapter 20 Review
■ Chapter Summary
After reading this chapter and completing the establishing just how much data the organization is
exercises, you should understand the following willing to risk versus how much time and storage
about networking. it’s willing to devote to backups.
■ Baselines create a benchmark or standard
Describe troubleshooting tools measurement of when everything is working
■ Network troubleshooting tools can be separated correctly on your network. Consider this to be a
into three categories: software tools, hardware snapshot of your systems. In Windows NT/2000,
tools, and “touchy” tools. The touchy tools include the Performance Monitor (PerfMon) watches
knowing what questions to ask end users, in a Windows NT/2000/XP/2003 machines, either
thoughtful way, regarding their computer locally or remotely. Know the concepts of objects
problems. Hardware tools include cable testers, (like CPU, memory, or disk drives), counters
protocol analyzers, hardware loopback devices, (which do the actual tracking), and views (which
and toners. Software tools include protocol allow real-time or historical arrangements of
analyzers, network analyzers, system logs, collected data). Novell NetWare servers have a
performance monitors, and system management loadable Console Monitor application. Although
software suites. The best “toolbox” to carry with Console Monitor can be viewed on a remote
you at all times is your brain. system, it only runs on the NetWare server. These
are called NetWare Loadable Modules (NLMs),
Explain the troubleshooting process and this particular one is started with the LOAD
■ The troubleshooting process is a dynamic fluid MONITOR command at the server console prompt.
process that requires quick decisions to get the ■ Any troubleshooting model should include the
network going again. Be conservative in your following simple steps: start out by establishing the
approach—protect your network’s data with two symptoms, isolating the cause and scope of the
basics—keep regular backups, and create baselines problem (this includes asking end users the right
for later comparisons. Be aware that each file on kinds of isolating questions), and determining
your systems has an associated archive bit, which what has changed that might have caused the
indicates that a file has changed. Know the problem. Then you can identify the most probable
different type of backups, as well as which backups cause, implement a solution, test the solution, and
clear and which backups set the archive bit on. recognize the potential effects of the solution.
■ A full (or normal) backup copies everything and Wrap things up with proper documentation during
clears the archive bits. A copy backup is a true your troubleshooting—this will help you keep
copy of an earlier backup, and does not affect the track of all that you’ve tried, and also come in
archive bits. An incremental backup (basically, a handy in the future. Those who do not document
copy of all files that have changed since the most now have no right to complain about lack of
recent backup) copies only those files that have the documentation in the past!
archive bit set, and then clears the archive bit on ■ “Mike’s Four-Layer Model” approaches
just those files. A differential backup (capturing troubleshooting as an art form. The four layers
those files that have changed since the last full suggested are hardware, protocols, network, and
backup) is like an incremental backup, except it shared resources. Mike’s hardware layer involves,
doesn’t affect the archive bit. Finally, a daily (or obviously enough, making sure the right hardware
daily copy) backup makes a copy of all the files that is in place, powered on, and connected. Mike’s
have changed that day, and does not change the protocol layer involves making sure configuration
archive bit. Frequency, storage, and type of settings are correct. It’s always best to fully test out
backups performed are major decisions that any changes in equipment to avoid being called
involve careful planning and analysis— back to the scene to finish things off properly.

549
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 550

Mike’s network layer involves making sure ■ Another common complaint from end users is that
network devices, especially servers, are server response times are slow. Comparisons
functioning normally. Finally, Mike’s shared against preestablished baselines, mentioned earlier,
resources layer involves checking for adequate will yield clues as to actual versus perceived
permissions/rights and shares on resources to slowdowns. The TRACERT command could also
provide appropriate access to network clients. reveal a slow hop along the data packet’s path.
■ A final problem mentioned by many end users that
Analyze troubleshooting scenarios involves solid troubleshooting is when Network
■ Some of the biggest and most complex Neighborhood/My Network Places does not show
troubleshooting scenarios involve having users other machines—a connectivity issue. Use the
simply log on. Trying to log on from other nearby PING command to ping the loopback address
machines will help to isolate and define the (127.0.0.1 or LocalHost), ping the system’s own IP
problem. Having yourself attempt to log on and try address, ping the default gateway (normally a
the PING command are further steps to help solve router), and then ping a remote machine. The
this situation. Another problem that pops up PING command helps you determine where the
occasionally is when a user cannot get to a certain connection drops off, enabling you to further track
web site. Have the user try to reach another web down the item at fault.
site like www.CompTIA.org and try to ping the ■ Remember as you practice the Art of Network
site as well. You may then be able to determine Troubleshooting to keep it fun, learn all you can,
whether DNS is functioning properly or not. Quite and have an “up” day! Good luck on your
simply it could be their server that is temporarily Network+ exam!
down, too.

■ Key Terms
Archive bit (534) Incremental backup (534) Protocol analyzer (531)
Backups (533) Mike’s Four-Layer Model (533) Software tools (531)
Baselines (533) NetWare Loadable Module System logs (531)
Console monitor (539) (NLM) (540) Touchy tools (529)
Copy backup (534) Network analyzer (531) Troubleshooting model (540)
Counter (537) Network Monitor (NetMon) (531) Troubleshooting process (540)
Daily backup Normal backup (534) Troubleshooting scenarios (530)
(daily copy backup) (534) Object (537) Troubleshooting tools (531)
Differential backup (534) Performance Monitor View (537)
Hardware tools (530) (PerfMon) (537)

■ Key Term Quiz

Use the Key Terms list to complete the sentences that 3. The best Windows NT/2000 software tool
follow. Not all the terms will be used. to use when trying to establish baselines is
__________________.
1. The term __________________ is used to describe
4. Another name for a full backup is a
knowing what questions to ask end users.
__________________.
2. Having access to __________________ is
5. A(n) ________________ backup copies only the
important, although you do not necessarily
files that have changed since the most recent
need to carry around a full toolbox.
backup and clears the archive bit on those files.

550
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 551

6. A(n) _________________backup copies only the 8. The __________________ is a NetWare server’s

files that have changed since the most recent equivalent of Windows NT/2000’s Performance
backup and does not clear the archive bits. Monitor.
7. The __________________ indicates that a file has 9. The LOAD MONITOR command will load a
been changed and no backup currently exists for ________________ onto a Novell NetWare server.
that version of the file. 10. Any __________________ will include initial
steps to define and isolate the problem.

■ Multiple-Choice Quiz
1. What should be done to establish normal 6. Julie has spent half a day troubleshooting a
operating conditions on your network? network problem and has isolated it to (most
A. Backups likely) configuration or hardware issues on a
single PC. The rest of the network works fine,
B. Baselines but Julie now has a frustrated computer user
C. Remote access who needs her PC networked to get work done.
D. Troubleshooting Which of the following offers Julie the best
chances of getting good information from the
2. Which of the following should you do first when
frustrated user? (Select two.)
troubleshooting a network problem?
A. When did you first notice your problem?
A. Isolate the problem
B. When was it working last?
B. Test the solution
C. Have there been any changes made to the
C. Implement a solution
hardware or configuration recently?
D. Document the solution
D. What have you done, you great oaf?
3. Which of the following would be an appropriate
7. Which of the following items should be done last
place to keep your hardware toolkit? (Select all
when troubleshooting a network problem?
that apply.)
A. Isolate the problem
A. In the server room
B. Test the solution
B. In the trunk of your car
C. Implement a solution
C. At home
D. Document the solution
D. None—you can get by without one
8. Where would DNS problems likely occur?
4. What should you keep in your hardware toolkit?
(Select all that apply.)
(Select all that apply.)
A. DNS server
A. Cable tester
B. Hosts file
B. Crimpers
C. Lmhosts file
C. Spare cable
D. WINS server
D. Games
9. What is required on a UNIX/Linux server when
5. Where could you find a list of problems that
logging on as root?
occurred on a system?
A. Password
A. DNS Server
B. Placename
B. Event Viewer
C. Rootname
C. User Manager
D. User name
D. User Manager for Domains

551
Chapter 20: Zen and the Art of Network Support
 BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 552

10. What must you have to log onto a Windows 2000 13. Which of the following are levels of “Mike’s
Server system as Administrator? (Select all that Four-Layer Model” to troubleshooting? (Select
apply.) all that apply.)
A. Password A. Hardware
B. Place name B. Protocol
C. Root name C. Network
D. User name D. Shared resources
11. You are called to assist a user who cannot access 14. What item can help isolate a bad NIC that is
any shared files on the network. You open the sending out too much traffic?
NIC’s properties to find that no protocols are A. Bus
installed. What should you do?
B. Hub
A. Format the hard drive
C. Protocol analyzer
B. Reinstall all programs
D. Router
C. Reinstall the operating system
15. Being able to ping a remote system by
D. Reinstall the protocols IP address, but not by FQDN, suggests what
12. Where should backup tapes be kept? type of error?
A. In the server room A. DNS
B. On a shelf in the storeroom B. Routing
C. In a locked cabinet away from the server room C. NetBEUI
D. In the boss’s car trunk D. Routing

■ Essay Quiz
1. Some students in class are discussing when tape 4. After a recent file restore fiasco at the nonprofit
backups should be performed. One student says organization you work at, management decides
daily, during nonpeak hours, while another to eliminate the concept of incremental backups.
student suggests weekly. A third student says You are asked to choose another backup method
both students are correct. The trio suddenly that would not involve restoring so many tapes.
looks at you for your definitive answer. Write Write down which method you would use and
down what you would say. give reasons as well.
2. You are the new network technician at your 5. You are on your way back from a call to
company working the Monday morning shift for unlock an end user’s account by resetting their
the first time. An end user calls in saying server password. On entering the server room you
response times are slow. Write down what you notice it feels a little warm. Then you notice that
should say to the end user, as well as what you a colleague has mistakenly left a soda on top
would do. of one of the servers. Which item should you
3. The IT group at your company has been told to tend to first—and why? Which item would
do nightly backups as quickly as possible. you address second—and why? Which item
Backup tapes are the backup method of choice. did you leave for last—and why? Document
Jot down the thoughts you would contribute to your findings and be prepared to share your
the discussion. thoughts with your class.

552
Mike Meyers’ Network+ Guide to Managing and Troubleshooting Networks
Color profile: Generic CMYK printer profile
Composite Default screen
BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 553

Lab Projects
• Lab Project 20.1
Use the Internet to find Network+ practice
questions. Try to locate as many troubleshooting
scenario questions in the time allowed. Share
your findings with classmates who have done the
same. The more practice questions you cover as
a group, the better prepared you will be handling
real questions on the Network+ exam.

• Lab Project 20.2

Use the Internet to research the cost of four hardware
tools used in troubleshooting mentioned in this
chapter. Be sure to include shipping charges to your
school’s ZIP code. Use the following spreadsheet as
a guide to tally your items.

Item: Cost
Model Web Site (Include S & H)
Cable tester:
$
Hardware loopback device:
$
Protocol analyzer:
$
Toner:
$

553
Chapter 20: Zen and the Art of Network Support

ch20p26.prn
P:\010Comp\BasTch2C\560-9\ch20.vp
Wednesday, June 30, 2004 12:59:08 PM
BaseTech / Network+® Guide to Managing & Troubleshooting Networks / Meyers / 225560-9 / Blind Folio 554