| Previous | Table of Contents | Next |
The “Sesame Street” method is more of a game than it is hard work. It’s one of the most gratifying and fun ways to troubleshoot (even if you don’t hum the song while you work). The principle involved is as follows: Given a group of two or more items on a network, all that’s required to troubleshoot the one item that isn’t functioning correctly is a comparison to an item that is.
Typically, the way in which items are different is also the reason the nonfunctioning item is broken. For example, if your children are twins and one of them—the one who eats Super Sugar Bombs instead of Wheaties for breakfast—is hyperactive, it doesn’t take a rocket scientist to figure out that you might want to align the twins’ diets to try to handle the hyperactive one. Assuming that the twins have identical activities, are in the same environment for their classes, wear the same types of clothes, and are for all intents and purposes physically identical except for their diets, it makes sense to try to align what they eat in order to rule out diet as a possible cause of hyperactivity.
The same principle applies to a misbehaving network appliance: If you find an identical item that happens to be working, changing the problem item’s configuration to be just like the one that is working can oftentimes fix the problem.
You can apply this principle to just about any object on your network, but it has limited use when troubleshooting devices such as routers and servers. Routers and servers are hardly ever really identical, although they may be similar in function. Sometimes, the similarity of function is enough to compare, but you need deeper knowledge to be able to compare servers that are “mostly the same.” It’s a lot harder than troubleshooting devices that are “twins.”
Servers and routers certainly have “device integrity” similarities—for example, a router that keeps crashing while others are doing just fine might show a different revision of its operating software (or firmware). Hardware routers don’t run Windows or DOS; instead, they run a “stock car” operating system, which is really pretty simple software (unlike Windows with its zillions of DLLs). The upside of this is that usually you only need to check one revision number; a difference in revision numbers might point out the difference between a working router and a problematic router.
Similarly, you might compare a problematic Windows NT server’s patch level and DLL versions to a known “good” server. In particular, NetWare servers have the Config Reader (see Hour 13, “NetWare Networking Basics”), which does a wonderful job of automating the task of comparing the dozens of crucial NLMs (NetWare loadable modules) and patches that live on a given server.
Because servers are all configured somewhat differently, it’s most useful to apply the Sesame Street principle to user objects that live on your network. By convention, user objects (user logins, associated security rights, and the user’s workstation itself) are typically configured at least somewhat the same—if for no other reason than your vendor found it easier to roll them out this way.
In its simplest form, finding out what’s “different” is pretty easy: You know that the group of users has been working reasonably well for awhile. Let’s say that one user reports that she can’t use a particular application; because others are working using their workstations and their logins, the first step is to figure out whether or not her problem resides in her workstation or her user login. You can rule out workstation problems by having her log into a different workstation. If the user is unable to run the application at another workstation, you immediately know that the problem is with her login, not her workstation. You can further prove this by having someone else login to the user’s workstation, proving that the application on this workstation does indeed work. You next must ask yourself how this user login might be different than the other user logins.
You need to compare apples to apples—in other words, if you try to run an application on a workstation that the application hasn’t been installed on, you’ll encounter problems. Also, some applications write user-specific files to a workstation, not to the network. Beware of these applications. You’ll want to perform a control experiment for each type of application—before you have problems—to see whether a user who can work with the application on one PC can also work with it on another PC. If so, you know that the application can “float” from workstation to workstation.
When only a few users in a workgroup report a problem, you should first review what has recently changed. If you come up with nothing (or even worse, if the change was mandatory and not undoable), it’s time to start thinking about how those few users are different than the rest of the pack.
Ruling out is a really effective troubleshooting technique that’s related to, but not identical to, the divide-and-conquer method. If you can start thinking about what a problem isn’t, you’re one step closer to figuring out what the problem is.
Ruling out is particularly effective when you find multiple things that are different between objects. For example, if two workstations have different video cards, network cards, and different amounts of RAM, you might give them both the same amount of RAM to rule out the problem as a RAM problem. Then you can move on to giving them the same network card, and so on.
| Previous | Table of Contents | Next |