IT documentation and a set of jumper cables share a similarity: You don’t think much about them until you need them—but when the need arises, it’s critical to have them. Although IT documentation plays an important role in disaster recovery and finding security vulnerabilities, the time and resources required to properly document a network are often shortchanged.

IT certification provides the justification you need to recommit yourself to documenting and analyzing your network. Microsoft’s Windows 2000 Network Security Design test (exam 70-220) tests candidates on their ability to properly evaluate technical environments. I recommend that as you prepare for this exam, you implement the best practices for documentation that the 70-220 test covers.

Begin by taking inventory
You should create a record of all the client systems and servers that exist in your organization. You should also catalog the brands and model numbers of switches, routers, printers, and other devices and keep a list of which OS versions and patches have been applied to each network node. Be sure to collect all the settings possible, including protocol, network address, and adapter and binding information.

Your licensing paperwork should get you up to speed on which operating systems are installed, as well as the programs, applications, and third-party utilities your organization has purchased and authorized specific employees to use. You should include service pack deployment information as well.

You can employ Microsoft’s Systems Management Server to collect this information, along with details about the systems and devices in use on your network. Even third-party tools, which leverage the capabilities of Windows Management Instrumentation, are available to help. Many of them can automate the gathering of this information using software discovery mechanisms.

Review your network infrastructure
When planning for security or other upgrades, you must have a solid understanding of your current network. Using information collected from your inventory, you should record your network’s actual physical structure. Documenting the location of critical resources in different sites can prove invaluable, especially if disasters occur or you have to quickly rebuild a failed system. For this reason, it’s also important to note the location of DHCP, DNS, proxy, VPN, and other servers when creating physical network diagrams.

In addition to creating a physical network diagram (using a tool such as Microsoft Visio) that pinpoints the location of clients, servers, routers, firewalls, and other devices, you should create a logical network diagram. While a physical network diagram specifies the network address information associated with each client, server, and device, a logical network diagram should be broken down by sites and include such data as the number of primary and backup domain controllers at each location and the number of users that specific site supports. WAN links between each site should be recorded, along with the capacity of each WAN connection.

Evaluate bandwidth issues
Your network’s performance capacity deserves its own category. It’s one thing to know the types of LAN and WAN links you have in place; it’s another to know the load level each carries.

Obtaining baseline measurements is critical in documenting a network’s bandwidth. Without knowing average utilization metrics, it’s next to impossible to tell how new installations or changes impact performance. Implementing security measures almost always affects a network, so having baseline measurements becomes that much more valuable.

Windows NT/2000 includes several tools you can use to create these baseline averages. Performance Monitor and Network Monitor can both collect valuable information about the amount and type of traffic traversing your network.

More documentation assistance

The following articles can also provide valuable tips and best practices for network documentation:

Eckel’s take
Documenting a network is an intimidating task, even for veteran IT pros. One of the biggest challenges is knowing how to start. Once you’ve completed the three steps I discussed (and which Microsoft considers to be key to evaluating an existing network before larger security concerns can be addressed), you’ll not only be well on your way, but you’ll also have documentation that can be used to immediately help identify and eliminate performance bottlenecks and security threats.