Channel Checklist: 10 steps for network documentation

More on network documentation Check out our top five tips on network documentation.

Although network documentation is always a good idea, it's especially important for service providers and value-added resellers (VARs). Documenting your customers' networks can make the troubleshooting process much more efficient when problems arise. These same network documents can also help you spot areas of your customers' networks that may need to be upgraded, giving you the possibility of earning extra revenue. Finally, good network documentation proves that you adhere to industry best practices, and could be your best defense should a customer ever file litigation against you for something network-related.

There are a number of network documentation products available that can assist with the documentation process, and Windows Vista also has mapping capabilities built in. Some of the more well-known network documentation applications include:

• SmartDraw
  
• QonDoc
• LAN Surveyor
• NetZoom
• ConceptDraw
• Microsoft Vision 2007

Create a network documentation policy

A network documentation policy should detail what aspects of a network need to be documented, especially each server. A documentation policy also communicates to each administrator exactly what is expected of them regarding the documentation process.

Create a network topology diagram

Ideally, you want this map of the network's topology to include each network segment, the routers connecting the various segments, and the servers, gateways and other major pieces of networking hardware that are connected to each segment. For larger networks, you may have to create a general segment map and make more specific maps of each individual segment.

Document server names, roles and IP addresses

While the information included in a network topology diagram is not necessarily specific, there is certain information that you should include for each server, even if that information has to be placed in an appendix. For each server, list the server's name, its IP address and the role that the server is performing (DNS, DHCP, mail server, etc.). Keep in mind that a server may be assigned multiple IP addresses or have multiple NICs, so you should document that information too.

Create a change log for each server

When a server fails, the failure can often be traced to a recent change. As a part of the network documentation, consider making a log book for each server for documenting changes such as patch and application installations and modified security settings. Not only will the log help you troubleshoot future problems, it can help you rebuild the server in the event of a catastrophic failure.

Document software versions and proof of licenses

Document the applications and their versions running on each server. You might also include a copy of the software license or a receipt within this documentation just in case your customer becomes involved in a software audit.

Document hardware components

I have talked about documenting individual servers, but it's equally important to document switches, routers, gateways and other networking hardware. The documentation should include information such as:

• How is the device connected to the network?
• How is the device configured?
• Does a backup of the configuration exist?
• What firmware revision is the device running?
• Is the device configured to use a password? (Don't include the actual password, but you can include a password hint or a reference to the password being written in a notebook that is stored in the safe.)

Document the Active Directory

I could probably write a book on Active Directory documentation, but here are a few things that you should consider documenting:

• The names of the domains in the forest.
• The Active Directory site structure.
• Where the various servers exist within the Active Directory hierarchy.
• The location and contents of each group policy.
• Any external trusts that may exist.

Document your backup procedures

Backup is your customer's best defense against a catastrophe, but it will do little good if nobody can figure out how to use it. Be sure to document the backup software used and its version (very important). You will also want to document the tape rotation scheme, a general description of what's included in each backup job and where the backup tapes are stored.

Label everything

I once had a client ask me to do a consulting project for them. They gave me a thorough and well-written copy of their network documentation to review ahead of time. But when I got on site, I realized that none of the hardware was labeled. All of the servers looked identical and there was no way to differentiate between them.

Get a label maker and label all servers, critical hardware components (gateways, routers, etc.) and the most important cables. This will make it easy to identify the various pieces of hardware listed in your network document.

Evaluate your documentation

The last step in the documentation process is to evaluate your network documentation to make sure that it's sufficient for you and your customer's needs. Think of your network documentation as a critical part of your disaster recovery strategy. When the first draft of your documentation is complete, you must ask yourself if it's good enough to help someone with no prior knowledge of the setup to rebuild the network from scratch in the event of a catastrophe. If the answer is yes, then you've done a good job on the documentation.

About the author
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.