Is It a Virus, Doc?

After getting a cup of coffee, you briefly think about the possibility of one of those viruses that “go off” at 8:00 a.m. on a certain day, but you dismiss it—you have pretty good virus protection. What’s more, you used a different workstation that you’re sure is virus free when you tested the different segment. Good guess, because things like this have happened—even viruses that don’t do anything until a certain day at a certain time in the morning can interfere with system operations every day while it checks to see if it’s the “right” day to ruin you.

So, it’s back to the drawing board.

Getting a Consultation

This is the crucial part, because you’re frustrated, and you think you can’t possibly solve this problem. It’s tempting to give up. Guess what? Pros feel that way, too. The difference, however, is that the successful troubleshooter takes a break and looks at the facts again. Then, much like a doctor, the troubleshooter might “get a consultation” and go right back at it.

Do you have to get a consultation from a pro? Not necessarily. You get a consultation because you’re too close to the problem, and you already have preconceptions as to what’s going on. Let’s say you ask somebody—anybody—what goes on at 8:00 a.m. every day. The answer is going to be “everybody turns their PCs on” or “everybody gets into work” or some variation on this. That turns on a light bulb for you—because everybody is turning their PCs on and logging in at 8:00, might this be the computer equivalent of rush hour on the network?

The answer, of course, is yes, there is a network rush hour. How do you verify this? Well, it’s sort of tough. There are two ways:

•  Actual measurement (relatively difficult unless you’ve already read Hour 21, “Tell Me About Your Network”)

•  Changing the situation (moving the workstation to a place where traffic will be quieter)

Even though you’ve already moved the workstation to a different segment, you hadn’t considered that the segment you were moving to might also be problematic. You can think of this as the equivalent of moving from the Long Island Expressway to the Grand Central Parkway—it doesn’t do you a lot of good at rush hour (you’ve been treating the situation as though there was construction or an accident on one but not the other). Now, your SOAP looks like this:

S: The problem might be network congestion.

O: The problem occurs at the same time on different major network segments.

A: Login congestion is likely on major segments, but not as likely on a segment with fewer users.

P: Check maps and try the applet on a “low traffic” network segment (perhaps nearer to the Internet segment and away from segments with server login traffic on them).

You deploy your plan: You temporarily set up a workstation at point C on the map. When you try the applet at 8:00, it works! You have now pointed the finger squarely at network congestion. The next question is, whose problem is this? In other words, is this something that the applet vendor is responsible for, or is this your problem for having a network that’s too busy?

Your response to this problem may vary. On one hand, it may be practical to move this person to a less busy segment. However, this might not work, because you can see from your physical maps that the network segments near PCs tend to have a lot of PCs on them and are smack in the middle of the servers. In other words, physical constraints might prevent you from putting this person on a segment without other PCs, because the only hubs near her probably are being used for other users. A hub with less traffic might be in your data center or in another building, outside of her physical reach. (The smart aleck might ask, “Why not ask this person to stop doing her work process at 8:00 in the morning?” Not a great solution—the network is supposed to work, darn it!)

At this point, if you really needed to have this person’s workstation live on a busier segment, you have to start application troubleshooting. Why is it that this person doesn’t have any other problems, say, with local applications? As you’ll see in Hour 19, “Internet/Intranet Troubleshooting,” comparing a local application to an Internet application isn’t a good idea; using Internet applications is like taking an international flight versus hopping in your car to go to the store. Lots of things can happen between here and Paris. You write down your SOAP again:

S: Applet is not working; other applications are.

O: The applet is the only Internet application in the mix.

A: Internet applications are not local applications.

P: Try a different Internet application during peak hours.

You’ve now done five SOAP lists. Long and tedious, isn’t it? Yet, as you can see, SOAP is a powerful process for refining what you know, as well as a way to take guesses and turn them into fact and a way to keep you moving forward.

You try a different Internet application at 8:00 the next morning, and it works like a champ. Even though it doesn’t do exactly the same thing, at least you’re now comparing apples to apples—that is, a firewall-dependent wide-area application to another firewall-dependent wide-area application. You try yet another Internet application, just to make sure, and it, too, works just dandy. Here’s your latest SOAP:

S: The application itself seems to be at fault.

O: Only have tried two other Internet applications.

A: Measurement of congestion and delay might help but would still lead to vendor.

P: Contact supplier of the applet and relate all notes that led to this conclusion.