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
Administrators are get-up-and-go type folks. They're not interested in
sitting around making phone calls or writing things down. They want to
be working with servers and software, desktops and wireless devices.
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
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.
My first networking job was for a small company in
Boulder. The previous administrator had left for a fast-paced
job in South Denver, I was a fresh newbie to Windows
NT and there was zero documentation with the exception
of the administrator logon and password. I had a problem
with the Gateway Service for Netware the very first
day and it stopped. People who needed Netware resources
could no longer access them.
I had to call the previous administrator and set up
an appointment for him to meet me at that evening (because
he couldn't just take off of work to come up and help
me fix the problem, nor did he have confidence that
I knew what I was doing). He drove up, assisted me with
the problem, then commenced to give me an hour-long
overview of a complex FreeBSD (Unix) SMTP mail transport
system that was hooked to our Microsoft Mail setup and
talked to other Mail postoffices in Japan and Germany.
There was no documentation for any of this and I wound
up writing quite a bit after that—talk about learning
things the hard way. I was always afraid that BSD box
was going to blow up and I'd have to figure out a way
to re-create a complicated e-mail system (this was back
before Exchange was even a gleam in Bill Gates' eye).
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
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.
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
- Each server's NetBIOS and DNS names
- IP configuration information
- Purpose of each server (file and print, e-mail, Web, systems management,
- Make and model of server, along with a physical description:
- Hard drives—their total space available and their currently occupied
- 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
- 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
- Disk quota information
- Miscellaneous information (e.g. Server has an Oracle installation
with 12 databases—DBA contact name is Mary Smith)
|There are some things that I don't think
represent adequate documentation. For example I don't
consider it adequate to run to the server and execute
the TREE C: /F > LPT1 command. This will spit out the
directory structure of the server's C: drive, but it doesn't
tell me a whole lot. Directory structures on servers are
prone to a lot of change, so simply printing out the directory
structure of your server, three-hole punching the printout
and then putting it in a ring binder does not qualify
as adequate documentation (thanks for playing; we have
some lovely parting gifts for you).
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?"
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
- Admin username and password for each switch and hub
- Type of backbone cabling (e.g. 6 pair fiber, Ethernet with redundant
- 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
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.
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
- 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.
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
- 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.
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
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
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
- 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
- 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
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.