Documenting Your Network

Mapping your hardware, devices and network connections will help you pinpoint your troubles, so don't put it off. Here's what you need to document.

• By Bill Heldman
• June 01, 2002

Does that describe you? If so, then you're not alone. The reason most people get into server administration centers around their love of all things having to do with computers coupled with their dislike for going to meetings, sitting around writing documents and making phone calls. (OK, you still have to make the phone calls, but usually it's to the Microsoft support desk.)

So you're probably very hesitant to document your network, aren't you? My guess is that "Document the network" is probably the task on your list of things to do that you've been moving it forward from month to month. If it makes you feel any better, you're not alone. In fact, you're probably in the majority.

But consider this: What would happen if you got that really high-paying job you'd applied and interviewed for a month ago? What if your ship came in? (Mine did, but I was at the airport at the time.) Someone else would have to fill your shoes, probably a contractor at first until your boss had time to find just the right individual. And that person would have to really struggle to figure out how you managed the network, what servers performed which activities, what the policies were that had been put in place, how the user and mailbox accounts were set up, and so forth. In fact, when you stop to consider it, there's quite a bit of information about the network—data that probably only you know—in that head of yours.

Maybe you work on a team with several other administrators. Each of you has a job to do—one person administers the Exchange servers, another the file and print boxes, still another manages security and so on. Consider again: The Exchange administrator goes on an extended three-week vacation and you're elected to take her place while she's gone. You've sat with her from time to time in order to digest all of the activities she's involved in on a daily basis, but hey, you're all busy there and well, you just don't have that kind of time to spend with her hour upon hour. So now the day has arrived and here you sit, riffling through the scant notes you took, wondering why she didn't document her systems more carefully—OK, why she didn't document them at all.

The fact is that the most overlooked—yet one of the most critical—elements of server administration centers on the idea of documenting how your network is set up. It's not that difficult an activity to perform, it's just that it's such a monotonous activity and often very time-consuming. But it's something you have to do. So, the next time you have some free time, sit down at your PC and knock out some of your network's documentation. Following are some of the elements I would document, if it were me, and how I'd document them.

The Where to Go to Find Things Doc
(AKA, the Start Here Document)

You should start with a little word processor document that outlines where things are kept. The person taking your place needs to know where you keep your software DVDs, CDs and diskettes; the drive location in which you store your system documentation; where keys are hidden; usernames and passwords and other critical information that's usually quickly required. You could type this up and leave it with your supervisor in a sealed envelope. That way, if it was needed, you'd find comfort in knowing that your supervisor would give the info to the person requiring it and people wouldn't be rifling through your drawers. Try to think of all the things your replacement might need to know right away, then put that in your Start Here document for easy retrieval.

Server Farm
The most important thing to begin documenting is your server farm. There are several key elements that you should consider documenting. You can easily formulate a fill-in form that captures the kind of information required to fully document your servers (and all other documentation listed herein). You could keep the information in almost any form; a Word or Excel document, perhaps an Access database, even an intranet HTML page. Whatever form you decide will work for you is fine—as long as you document how to get to your documentation for the person taking your place! Following are some suggestions for server farm elements that you should keep track of:

• Each server's NetBIOS and DNS names
• IP configuration information
• Purpose of each server (file and print, e-mail, Web, systems management, database, etc.)
• Make and model of server, along with a physical description:
  • Hard drives—their total space available and their currently occupied space
  • RAM
  • Processors
  • Fault tolerance features (e.g., RAID card?)
  • NIC configuration information (e.g. 100Base-T, full-duplex)
  • Network operating system (NOS) and current service pack level
  • Any miscellaneous information (e.g. Server has the FSMO role of PDC Emulator)
• How the server connects to the network (fiber, Ethernet, etc.)
• Where the server connects to the network (e.g. East IDF)
• Shares on the server, along with share permissions
• Backup information (e.g. Server has an incremental backup performed on it Monday-Friday, and a Full backup performed on Saturday. All backups are performed at 2:00AM)
• Security information (e.g. Server runs McAfee Anti-virus, and automatically downloads its DAT file every Thursday afternoon)
• Vendor support information
• Home drive and shared drive information (Often users have as their home drive some space on a server. Additionally, many companies have a large volume of disk space where anyone who wants to can place information. This is typically called the "shared" drive and it's a pain for administrators to maintain.)
• Disk quota information
• Miscellaneous information (e.g. Server has an Oracle installation with 12 databases—DBA contact name is Mary Smith)

In order to fully document your servers, you should ask yourself this question: "If I were new to this job, what information about this server would I need to know to fully support it, in the absence of anyone else who can give me information about it?"

Infrastructure Layout
It's also key that you document the infrastructure of your network. By that I mean that you sit down with your Visio software and actually draw out the MDF and IDF(s) and their connectivity. Suppose that you have a fairly straightforward layout of one MDF. In that MDF you keep your servers in racks, there is a T1 demarcation point where the telephone company has terminated your T1 to the outside world, there is a router and there are some switches. Wiring runs out from this MDF to the various offices and cubicles around your company.

A good infrastructure document wouldn't necessarily have to show each wire running from the MDF to its destination office. You might include some Visio pages later on in your infrastructure documentation, but it's not all that necessary when first beginning your documentation efforts. You can read the patch panel and (hopefully) match it to its destination wall jack to find what you need there.

Infrastructure documentation should include the following elements:

• Location of switches and hubs (e.g. MDF and IDF[s])
• Make and model of switches and hubs (e.g. 3Com Superstack 3000)
• Current firmware version level of each switch and hub
• Configuration detail for each switch and hub (including individual port settings)
• Admin username and password for each switch and hub
• Type of backbone cabling (e.g. 6 pair fiber, Ethernet with redundant backup, etc.)
• Support phone numbers for infrastructure gear (e.g. switch manufacturer support desk phone number, cabling contractor phone number)
• Miscellaneous information (e.g. Location of TFTP server for firmware uploads)

Most infrastructure documentation should include a good quality, frequently reviewed and updated network diagram done in Visio or some other product that's widely available. You should also note where to find these drawings so your replacement doesn't have to go hunting all over the place for your carefully placed files.

Note: The reason the firmware version is so important to track is that when you begin talking about switches, it's usually very important that all of the switches are up on the same version of firmware. If they're not, erratic things could potentially happen and you'd have a hard time troubleshooting what's going on. Call a switch vendor's support desk and one of the first questions you'll be asked is what the switch's firmware version is. So the moral of the story is to document each switch's firmware version and to keep the documentation up to date so you know which switches are behind and need to be updated.

Application Information
Very important to include in your documentation efforts are the applications that you have running on various servers. Applications can be strange and wonderful things requiring unusual information. When considering the documentation of your applications, you should include the following information:

• Name of the application
• What the application does
• Version and service pack (if applicable) level of the application
• Server(s) the application is/are installed on
• Service account names and passwords
• Administrative account names and passwords
• Drive and directory the app is installed in
• Applicable application configuration information
• Special instructions regarding the application
• Troubleshooting tips
• Additional info (e.g. Exchange organization name)

Perhaps you have an Exchange system running in your company. You'd want to document the servers that are running Exchange, along with the version and service pack level of the Exchange computers. Because pre-Exchange-2000 servers utilize an internal administrative user account, you'd also want to include that information as well as the service account name and password. You'd also want to talk about special services each Exchange server might be running (Internet connector or Key Manager, for example) and how to troubleshoot if things go awry.

In installations where you have application servers that connect to one another and share information (such as a SQL Server, SMS or Exchange, for example) you would want to also provide a Visio diagram that graphically shows the way the servers are laid out. A visual such as this goes a long way in helping system newbies understand how it's set up.

Note that your regular non-application network servers don't need to be included in this section. Here we're interested in specific applications so that in the case there's a problem with one, we can quickly figure out what needs to be done to fix it.

Printing Infrastructure
The way the printers are set up can be a very confusing thing to new or substitute administrators. You might know your way blindfolded to every one of the three hundred printers in your company, but your replacement won't. Nor will they know whether the printer is connected by HP Jet Direct or another network device, what the printer's IP address is, or any other configuration information. Following are some things that you should consider when setting up a printing infrastructure document:

• Server hosting the print device
• Printer make, model
• Amount of RAM in printer
• Duplex-equipped?
• Type of printer (e.g. laser, desk-jet, plotter. etc.)
• Name, share name and permissions utilized on the server for this printer
• IP address and other crucial configuration information
• Type of network device connecting the printer to the network (e.g. HP Jet Direct)
• Firmware version of network device
• Data transfer rate with which the printer is connected to the network (e.g. 10 Mb/s)
• Types of paper supported
• Ways to remotely manage the printer (e.g. HP Jet Admin, telnet, etc.)
• Is there a local super user who can assist in troubleshooting this printer? Name and phone number.

Again, a Visio diagram of your printing infrastructure can be useful here. It might be beneficial to jot down who the users are that have local printers (devices that are connected to their PC so that they print locally rather than to a network-attached printer). Sometimes local printers are shared out and it's helpful to note those instances in which people are printing to local printer shares.

Security Infrastructure
Networks are interesting dynamic entities that grow and shrink and change on a daily, if not hourly, basis. As such, you might put a system in place, and without documenting it, others will be completely confused as to how you've set up something. Particularly, so is your security setup. For example, perhaps you've done a really great job in making sure that all of your PCs are "level-set" with the same software version of your favorite anti-virus program and that each PC is obtaining new virus signature files as they come out. Good for you! But how is your replacement supposed to know that unless they find it out by actually visiting a PC and discovering how the anti-virus software is configured? Furthermore, how would your replacement know that all PCs in the kingdom are equally configured without visiting them all? They wouldn't and this could present problems the very first time there was a virus breakout, because you wouldn't have any way of knowing who's current and who's not. (OK, this is a little skewed. Most corporate anti-virus software editions today support a network management component that allows you to view which PCs have which versions of the various software components installed. However, your replacement going in cold into a new environment may have as much trouble figuring out the management software as they do the individual computer user's setups.)

Mapping the DMZ and Perimeter Documenting your DMZ and perimeter network is critical in the documentation game. The DMZ is that unprotected area between your private network and the Internet. DMZs can have a firewall in front of them (facing the Internet), behind them or both. The perimeter network is the grouping of firewall, intrusion detection, VPN and Web filtering servers that make up the entry point to your private network (see Figure 1). Figure 1. The perimeter network and DMZ. You'll want to make good Visio diagrams of your DMZ and perimeter, noting the kinds of computers the various software components are running on, what the software is that they're running and what the server's purpose in life is. For example, you might have a perimeter network in which you have the following servers: Sun Solaris server running CheckPoint—Firewall Sun Solaris server running CheckPoint—redundant firewall for fault tolerance purposes Sun Solaris server running RealSecure—Intrusion Detectin Sun Solaris server running WebSense—Web filtering Dell Windows 2000 server running Microsoft Internet Security and Acceleration (ISA) Server—VPN The DMZ might contain the following servers: Dell Windows 2000 Advanced Server 4-node cluster running IIS Dell Windows 2000 Advanced Server DNS computer It's critical that your replacements know the usernames and passwords, IP addresses and functions of each of the servers on your perimeter and DMZ networks. The DMZ typically uses a different TCP/IP subnet and isn't connected in anyway with the internal network, so careful—and closely guarded—documentation of this information is a must. I can't think of a more (negatively) challenging assignment than to ask a new administrator to figure out on their own the way that the DMZ is set up.

Security infrastructure documentation should include any components that you consider paramount to the security well-being of your network. You'll include your anti-virus methodologies, perimeter and DMZ, as well as security policies, sniffing methodologies, and other things that you need to be put into your documentation. Be sure to include all information that may be privy to a person's understanding of how your network is set up so that important pieces aren't missing. You might be tempted to leave out key elements due to the sensitive nature of your subject, but you can't. You've got to document this stuff, then figure out a way to keep it from prying eyes.

Miscellaneous elements
Finally, you should document things that you think are routine, but will be important to someone taking your place. Phone numbers; e-mail addresses; support phone numbers, account names and passwords and other items such as this should be documented so that people subbing for you have a place to start.

It's also a good idea to train your substitutes how to do what you do so they don't feel helpless when the time comes.