1. Ten steps for Network Documentation:
JUSTIFICATION
Although network documentation is always a good idea, it's especially important
for technicians (service providers) to document your customers' networks to 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.

2. TOOLS
There are a number of network documentation
products available that can assist with the
documentation process.
Some of the more well-known network documentation
applications include:
SmartDraw
QonDoc
LAN Surveyor
NetZoom
ConceptDraw
Microsoft Vision 2007

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. Document hardware components
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?

9. Document the Active Directory
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.

10. 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.
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.

11. Label everything
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.

12. 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.