If the building that houses your network were destroyed tomorrow, your network documentation should be adequate to assist you or someone else in completely rebuilding the network from scratch. The chances of such a cataclysmic event occurring are slim, of course, so wouldn't it be nice to get some kind of use out of the documentation that you’ve worked so hard to create?
You’ll be happy to know that a well written network diagram can be used to troubleshoot a variety of network problems. For example, if your Internet firewall were hit by lightning, it would take some time to install and configure a new firewall—unless you had all of your firewall settings documented.
The physical network
The first step that I recommend is to make a map of the main network segments in your building. This may include wired and wireless segments. Use a tool such as Autocad or Visio to create a diagram of the building (if such a diagram doesn’t already exist). Next, plot the location of all hubs, routers, and wireless access points on the map. Finally, draw in the network cables that connect each device.
Should network connectivity fail for a portion of the mapped building, you could look at the map to see which areas were affected by the problems and see if those areas share a common network segment. This could help you to quickly pinpoint other potential points of failure.
If your office is very big, it might be worth your while to document which port on a hub or switch is wired to which network jack (in which office or cubicle). The idea is that, by knowing which hub or switch and which port feeds each office, you will be able to troubleshoot connectivity problems on individual PCs much more quickly.
At one of the places where I used to work, each wiring closet contained one or more switches. What made these switches unique was that they were expandable. Any time the switch filled up, you could add another card for 24 more ports. Each switch could support almost 200 PCs.
One day we had a failure in which a bunch of PCs dropped offline. The thing was that the PCs were scattered all over one floor. Since some PCs on that floor were working, we could confirm that the main Ethernet segment servicing the floor was functional. Normally, a seemingly random failure would be a nightmare to troubleshoot. However, when we checked our network documentation, we were able to confirm that all of the failed PCs were connected to two specific cards within our switch. We replaced the failed cards and the PCs came back online. Since the lights on the bad cards were still on, there were no obvious things that we could have looked for. Our network documentation prevented hours of downtime for the users.
As you document the physical portion of your network, you will want to be sure to record the settings used by each network device (switches, wireless access points, routers, and firewalls).
After you map out your network, turn your attention to the individual servers on the network. Begin with a good hardware inventory, and note not only what physical components exist within your server, but also what version of each driver you are running. For example, your documentation might say something like, “server is using a NeoMagic 128ZV graphics adapter and NeoMagic graphics driver version 46.2.1134.”
If your server uses plug and play, then you really don’t have to worry about documenting individual hardware settings, such as which DMA, IRQ, or base memory address each individual hardware component uses. On the other hand, if your server uses an older technology such as ISA, EISA, VESA, or Micro channel, then it might be a good idea to go ahead and document individual hardware settings.
If your server is multihomed (contains multiple NICs), then you will definitely want to do some additional documentation. You will need to know which NIC is connected to which network segment and which IP address has been assigned to each NIC.
Even if your server isn’t multihomed, you will want to document the server’s TCP/IP configuration. Specifically, you’ll need to document the server’s IP address, subnet mask, default gateway, and WINS and DNS server references.
Another thing that you will want to be sure to document is any applications that might be running on your servers. Note which partitions and folders are used to store the various databases and transaction logs. Also document the name of the Exchange organization and the name of the administrative group that the Exchange server belongs to.
High-level server applications such as Exchange aren’t the only server applications that should be documented. You will also want to make note of which servers are acting as DNS servers. Remember that Active Directory won’t function unless a properly configured DNS server is available, so document not only which server is running the DNS services, but also all of the DNS settings. Do the same for WINS, DHCP, and any other servers that you are running.
While documenting your servers, take the time to document the Startup status of each of the services that are running on the servers. One of the key steps to securing a server is to disable any unused services. Documenting which services are used and unused can help you reconfigure a server to its previous state.
Documenting Active Directory can be a complex process. I recommend getting your hands on a copy of Visio. Visio contains stencils that you can use for doing all different types of network documentations, but it is particularly good for documenting Active Directory.
First, document the Active Directory server roles. In an Active Directory environment, certain roles are assigned to domain controllers at the forest level and at the domain level. Active Directory can’t function if the servers that have been assigned these roles are down for very long.
After you have documented the server roles, document the domains, indicating which servers belong to which domains and any trust relationships that exist between domains within the main forest and external domains.
This is also a good time to document any sites that might exist within your forest. Make note of things like which servers are acting as bridgehead servers and which servers are on each side of the site link.
After you have documented which servers are performing various roles, you should make a list of which organizational units (OUs) exist within Active Directory. You can then list which users, computers, and groups exist within each OU.
The level of granularity that you use is up to you. I have seen several organizations that have tried to document individual user accounts (i.e., who has rights to what). Typically, I don’t recommend doing this because it takes a lot of work and I have never once seen an organization successfully maintain the user documentation for more than a few months.
Do, however, document all of the security groups, including which resources each security group has access to. You can also list which users are members of the group; but again, this is tough to keep up with.
There’s really no limit to the things that can be documented in regards to Active Directory. One thing that shouldn’t be left out of your documentation though is the security policy. Make note of what levels of Active Directory group policies are applied within. You should also make note of which policies are used at which levels and which group policy elements are used within each policy file.