| Previous | Table of Contents | Next |
After looking at the new chart, it became apparent to me that although the PCs all had components-du-jour and had been built with whatever pieces and parts the vendors had lying around, they all, oddly enough, had the same video card.
Just because it was reasonably easy, I swapped out one of the problem workstation’s video card with a different video card. As I continued to log problems, it became apparent that the workstation with the new video card was no longer having a problem. I switched another workstation’s video card, and the problem went away there as well. Although I tried to update the video drivers on the remaining problem workstations, this did not make the problem go away. The final solution was to replace all the problem workstations’ video cards.
Obviously, getting a lot of workstations whose components tend to change on a regular basis isn’t a good foundation for being able to easily troubleshoot workstation problems. Because fewer differences equals less time trying to figure out which of these things is not like the others, it makes good sense to practice proactive troubleshooting by attempting to keep all components—software, hardware, and otherwise—to a standard, particularly within the same department or workgroup. See Hour 16 for real-life information from the trenches on how to homogenize your heterogeneous network.
A heterogeneous network is one in which the components are all different; it’s more difficult to be a Sesame Street troubleshooter on a network like this. On the other hand, the components used in a homogenous network are pretty much all the same. This is a Sesame Street troubleshooter’s dream.Are there really totally homogenous networks in which everything is always identical? Probably not. Like most things in life, the truth lies somewhere in the middle. However, in this case, the key is to keep as many things the same as possible.
If you have something that is broken, comparing it to something that works can be a quick way to establish what exactly is broken. Although it’s difficult to compare the configuration of seminally different servers and routers, comparing their overall revision levels and file versions can help to rule out a “difference” problem.
This technique works particularly well when you’re considering other objects on your network, such as user setups and workstation configurations. Sometimes, if you’ve troubleshot the problem down to a particular configuration, you can replace it wholesale (or shotgun it) with a known “good” configuration. This allows you to avoid dealing with complex issues that you may care nothing about.
For complex problems with multiple complainants, you should keep a troubleshooting log that contains the specifics of how users’ workstations and configurations are different. This can help to establish a pattern of how the complainants’ configurations are the same.
Q How can I tell whether a problem workstation is similar enough to a known “good” workstation to compare apples to apples?
A You need to have a good sense of when a workstation was installed, who installed it, and so on. Your site’s detail documentation will come in handy for determining this. Even documentation in the way of receipts can determine whether a workstation was purchased (and therefore configured) at the same time as another. If you work for a large organization, your purchasing department most likely has asset tags on the PCs. Also, the date of purchase can probably be found somewhere in a database.
Q How do I shotgun a known “good” user setup?
A Most network operating systems have some sort of template feature (for example, IntranetWare’s NWAdmin), or at worst, they have a feature where you can copy one user to another (NT’s User Manager).
| Previous | Table of Contents | Next |