Undocumented networks are extremely common. Many times this is related more to the difficulty of keeping the documentation up to date rather than to the difficulty of the documentation process itself. Many LAN Administrators had big dreams at one time of keeping elaborate drawings detailing every last aspect of the network. However, networks tend to change too frequently for such drawings to stay current. In spite of the difficulty, having a well documented network can help you solve problems quickly when they arise and is vital to the overall security of your network. In this article, we’ll discuss some alternative documentation methods that are more practical in the ever changing world of networks.
Label Everything
Perhaps the most important part of a good network documentation plan is to label everything. You should create the labeling scheme with the idea that the structure of the network will be constantly changing as will the people who use the network.
Perhaps the most important thing to label is your network cables. If you’ve been networking for very long, you’ve probably seen way too many network closets that contain a massive web of tangled cable. Usually all of this cable looks alike, and it’s impossible to tell which cable connects to what without some extensive diagnostic work. Most of the network administrators that I know are way too busy to have time to fish through a million cables hoping to stumble upon the correct one every time that there’s a problem.
Because of this fact, you should label both ends of each cable as to what the cable does. This label should be written in such a way that in five years when you’ve moved on to another job or have totally forgotten all of the stuff that you did today that the labels will still make sense.
Although it may seem way too obvious, this means making the cable legible. Wrapping the cables in masking tape and writing on the tape is a bad idea. These sort of labels tend to fade or crumble to dust over the years. We recommend using a commercial label maker. Just make sure that what ever kind of labels you use have strong enough adhesive that they won’t gradually fall off of the cables. One way of preventing the labels from falling off is to wrap them around the cables.
We mentioned that the labels should still be useful several years down the road. Therefore, the network labels shouldn’t be based on building locations or on people’s names. For example, creating a label marked John’s office is a bad idea, because John could quit tomorrow. Likewise, creating a label marked Finance Manager’s Office is a bad idea. This is because five years down the road, the Marketing Manager could be using the office, or the office could be a conference room instead of an office. You should also plan on network growth. For example, a cable marked Manager’s Office could be misleading if in a few years there are ten network cables in the manager’s office.
Since creating labels by name or geographic location have drawbacks, you might be wondering what will work. We recommend using a numeric numbering scheme. For example, you might create a map of the building with a CAD program and document the location of each network outlet. You could then assign each network outlet a number. Once you’ve assigned numbers, mark both ends of each given cable with the number that you’ve chosen. You should then mark the network outlet on the map with the number. As more network outlets are added, simple add them to the map. The map should be posted on the wall in your network wiring closets so that at a glance you can tell exactly where any given cable goes.
Log books
Another issue to consider in network documentation is the configurations of your servers, workstations, and users. When it comes to creating this sort of documentation, one massive log just doesn’t get it. A single log tends to get to large and too difficult to locate information very quickly. Instead, we recommend creating several different logs.
The first thing that we recommend is having a log book for each server. This log book should be kept with the server. Any time that a change is made to the server’s configuration, detailed notes should be placed in the server’s log book. For example, if you add a service pack to the server, you might record the date and time of the upgrade, and the service pack number.
While such information may sound trivial, keep in mind that in many environments more than one person has administrative access to the servers. By keeping a complete history of any changes that each person makes to a server, it’s easy to see if one of your coworkers have made a recent change should a problem come along.
You could also keep a log book for each workstation if you wanted to, but this is often unnecessary in large environments. In large environments, the goal is to make each workstation as standard as possible. Therefore, you might keep one log book that documents the standard configuration and any changes that you might make to it.
Finally, you should keep a security log book. The security log should contain a record of every user account on the system along with information such as what groups the account is a part of, and any special access permissions that the account might have. Likewise, the security log should contain a list of groups along with the group’s members and permissions.
The security log book may sound like a lot of useless work when you consider that you can easily retrieve such information directly from the system. However, I’ve seen countless situations in which permissions were damaged during a server migration or other routine maintenance. In such a situation, you could always get the permissions back by restoring a backup, but doing so requires time and reverts users back to older file versions. If your permissions become damaged, it’s much quicker and easier to look them up in a log book and manually correct the problem than to deal with the hassles involved in a restore operation. A security log book is also extremely nice to have around should your boss hire a consulting firm to pull a surprise security audit.
Obviously, your security log book shouldn’t be limited to information on permissions. Your log book should contain detailed information about your security policies in general, such as how often you force password changes, and minimum password lengths. You can really use your imagination when creating a security book. Although some administrators consider it to be going too far, I’ve seen Administrators include legal documents in the security log book. These documents are signed by each user before they are given a network account and basically cover such issues as software piracy and Internet usage.
Brien Posey has written thousands of technical articles on a variety
topics. You can access many of them by signing up for a free membership
to Brien’s personal Web site at http://www.brienposey.com. Brien’s Web site
also contains a forum area where you can post your most difficult
technical questions and a live chat area where you can talk directly to
the experts!
