Documenting our clients networks can make the troubleshooting process much more efficient when problems arise. These same network documents can also help you spot areas of our clients networks that may need to be upgraded. Network documentation proves that your organization is adhering to the industries best practices, and could be your best defense should a unforeseen event ever take place.
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.
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
Backing up our clients critical information is the 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.
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 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.