Tackling a network documentation project

I recently started a new position for a catering company as an IT Manager only to find that the documentation on the network infrastructure was so out of date that I had to literally start from scratch. To help me figure out where to start I followed the three step rule to any network documentation project.

 - Determine what network information to document.
 - Gather the information you need.
 - Present that information.

Some of you may be wondering why it is at all that I needed to document the network infrastrcure in the first place. Well the fact of the matter is that there are a number of compelling benefits to having a well-documented network. It can:

• Aid in troubleshooting - When something goes wrong, the documentation will serve as a handy reference to guide the troubleshooting effort. It will save time and money.
• Aid in training new personnel - If a new person comes on board, there is no better way in explaining a network infrastructure than with a printed reference.
• Aid contractors and consultants—These people are expensive. If they need to know the details of the network infrastructure, they will proceed much faster if documentation is available.

Documenting a network infrastructure is basically trying to take technical information about a given network and present it to someone less familiar with that network in a way that allows that person to learn about what you know.

Considering I was taking over the network for the first time, and didn't know much about it I had to sit down and really think about what it was that I needed to know about the network infrastructure and what it was that I needed to document.

Although every network has its own unique features, many common elements are candidates for documentation. These include:

• Network topology - This is usually done in the form of a diagram that shows the major network nodes, such as routers, switches, firewalls, and servers, and how they are all interconnected. Normally, printers and workstations are not included.
• Server information - This is all of the information on servers that you will need to manage or administer them, such as name, functions, IP address, disk configuration, OS and service pack, date and place of purchase, warranty, and so forth.
• Router and switch port assignments - This includes detailed information on WAN configuration, VLANs, or even the assignment of a port to a network node via the patch panel.
• Configuration of network services - Network services, such as DNS, WINS, DHCP, and RAS, are critical to the operation of the network. You should describe in detail how they are structured. Although it would be possible to derive that information by inspecting the servers, the point is to save that time by having it documented in an easy-to-decipher format.
• Domain policies and profiles - You can restrict the capabilities of network users with the Policy Editor in Windows NT or with Group Policies in Windows 2000. You can also create roaming profiles that are stored on a server rather than on local machines. This kind of configuration, if used, should be documented.
• Mission-critical applications - You must document how these are maintained, as well as what typically goes wrong with them and how you resolve problems.
• Procedures - This in itself can be a major undertaking. Procedures are basically the means by which we carry out policies, and they can be quite extensive. For instance, a policy can state, “The network shall be secure against unauthorized users.” However, it takes a great deal of effort to implement that policy. There are procedures for the firewall, for network protocols, passwords, physical security, and so forth. You would probably also have procedures for dealing with problems that are reported by users and for routine maintenance of the servers.

Documenting a network that I'm administering should have been easy considering my administrator rights however as I'm relatively new to the position with no prior knowledge the task at hand seemed more daunting than ever before. The easiest way for to gather as much information about any given network is to either try and contact past administrators or dig through their old documentation. If you fail on both accounts the best although longest solution is to seek the information from the network itself using tracing cables, accessing server configurations, routers and switches.

Once I had all the information needed it was time to start communicating this information and there seems no better way than through graphical diagrams and well presented tabular forms. Either way the point is to communicate this type of information as effectively as you can, using whatever tools necessary.

One of the most effective tools for graphically presenting network information I have found is Cacoo. A web based user friendly drawing tool which allows you to create a variety of diagrams such as site maps, wire frames, UML and network charts.

Although it can be a time-consuming job, documenting your network is important and necessary. Take the time to properly plan your documentation project. Consider not only what aspects of your network you will need to document, but also in what priority. Carefully plan how you intend to acquire the information you need and how you are going to present the information once it is gathered. You'll realize the payoff for your hard work when the time comes to troubleshoot problems, train new employees, and outsource tasks.