A general rule of thumb on the minimum level of documentation you should keep is this:

Keep enough documentation that someone with your skills, but no 'inside' knowledge of the system, could rebuild the network.

Your documentation does not have to be a step-by-step instruction manual for rebuilding the network. Your goal is not to make it so a trained monkey could do your job. What you should document, though, are those things that meet the following criteria:

• Things an outsider couldn't possibly know. These are things like administrative passwords, important share names, arbitrary directory assignments for critical applications, selection of IPX network numbers, and other information.
• Anything that needs to be tracked. A perfect example of this is the assignment of static IP addresses inside your network. Which devices have which IP address? Which addresses are free? This is important to keep updated not only for others who come after you, but for you as well.
• Things hard to figure out. There are almost certainly some tricks you know that apply to your network. If this happens, just do this and it'll be fine. These should be documented in some form.

Why is it important to document your network? The reasons are many:

• Something could happen to you. Life is unpredictable. You could become unable to work, could end up having to take a long leave of absence, or any of a variety of other factors. Leaving good documentation is the responsible thing to do to help your organization survive this.
• You could leave the job. While some people view a lack of documentation as job security, the truth is that it seldom matters one way or another. In most cases, the question of whether documentation exists is not a factor in these decisions.
• For your own reference. It may be fresh in your mind now, but a year from now it might be hard to remember. Documentation gives you a chance to look up things rather than trying to re-derive them.
• Reduced training time. As your company grows, or simply maintains present staff, new IT employees or even consultants may work on your network. The presence of good documentation reduces the amount of work you need to do to get them up to speed.
• Disaster Recovery. If you're having to rebuild a server that has crashed, having documentation of what needs to be there can be priceless. Eventually, every network admin will face this daunting task. A little preparation can make all the difference between smooth restoration of functionality and hours of panic.

Regarding the whole 'job security' issue: while companies and jobs come and go, it's been my experience that the IT community is a smaller world than you might think. I personally continue to run into people that I worked with eight or ten years ago, and who remember me and my work. The better a legacy you can leave behind you, the better the reputation you'll have in the industry -- and you never know when that might be important.

• Administrative Passwords. This includes servers, routers, print servers, network applications (such as accounting systems) with their own password systems, ISP passwords, E-mail passwords, passwords to domain registrations, SNMP community strings, etc. Individual user passwords may not need to be documented, depending on your organization's security policies. Passwords have a tendency to get set and then forgotten, especially on services where the system remembers the password for you. However, it can be difficult to figure out what that password is, and difficult to change it.
• Network Addresses. You should have an IP map of your entire organization, including any and all statically assigned addresses. If you're using network address translation, you should document which outside address/port is mapped to which inside address.
• Network Design. If you have only a single location with a simple set of Ethernet hubs, this step can be skipped. For anything more complicated, you should draw a network layout design that will show the networks and the links between them. You should also show and document all network routing protocols being used.
• Workstation Setup. What needs to be done each time a new workstation is set up on your network? What applications are standard fare for your shop? Are there any unusual applications that need to be installed, and if so, how are they installed? Are there any special drive mappings that need to be made, or software that needs to be installed that might be non-obvious?
• Disaster Recovery Procedures. Where are the backups? Where is the software that would be needed to re-install things? In a crisis, having good documentation prepared and a checklist of items to be set up on each mission-critical server are valuable.
• Telephone Numbers. Numbers for vendors of software, ISP help lines -- anyone who might be needed to provide help in the future. Your rolodex can be an important piece of your documentation.
• Network Cabling. I can't stress this enough. Make sure all your network jacks are labelled. Tracing them down after the fact is a time-consuming project, and not what you want to do when you need to figure out which port on the patch panel goes to that wall jack in the conference room. A bit of time with a label-maker and stickers on each jack identifying which patch panel port it leads to can save hours later.
• Config Files. This especially applies to routers and firewalls. Most of them have the ability to save their configuration file to a file on a PC. Keep a copy of this safe as part of your documentation. If a router fails and has to be replaced, it's far easier to just upload the old config or refer to it than to rebuild it from scratch.
• Problem Solutions. If you've had to call tech support for a major issue, or had to spend a lot of time figuring something out, document it in your files. Someday you -- or someone else -- may be saved hours of work by this simple expedient.
• Software Licensing. When you purchase software, save the certificates of authenticity or other items that prove you made the purchase. It's important to keep track of these original documents to prove that you did, in fact, purchase the software in question.
• Custom Software. Anything that was written custom for your organization must be documented thoroughly and that documentation protected. It is irreplacable, and without full source code, database layouts, and algorithm documentation, the software can actually become useless because it cannot be changed or maintained, resulting in a huge loss of revenue and time for the organization.

One important point, however: do not store the only copy of your documentation in electronic form inside whatever you're documenting -- at least not without a good, solid backup of it. Store a copy both on the server or your local PC, or on a laptop. Make sure that someone else within the company -- usually your immediate superior -- knows where all the documentation is stored.

For pictorial or diagram information, I heartily recommend 'Visio', currently being produced by Microsoft. It's the best package out there for quickly creating attractive and organized diagrams, and changing them to keep them up to date is usually far easier than it would be with an ordinary structured drawing program.

Software license information should be kept somewhere secure, preferably in a fireproof safe or off site. It should be kept together, so that in the event of a software audit it is easily accessible. These documents form your primary information you will need to prove your ownership of these packages.

Items that will change frequently, such as IP address maps, can be kept in electronic form. This also applies to periodic backups of configuration files. These can be stored on network servers, though periodically an offline copy should be made to a CD, to floppy disks, or some other removable medium. It should then be stored in a safe place.

The most important thing about documentation is to keep it up to date. If you let it slide while concentrating on other tasks, soon the document will become obsolete, and it becomes a much more formidable task to update it -- a task you are very likely to postpone or ignore. Out-of-date documentation is often no better than no documentation.

It's important to know what your company has purchased and what is currently in use. If a piece of software is installed, then it is found in the audit and must have a license. This is one reason so many companies are so concerned about outside software being brought in: in the event of an audit, the owner of the computer (the company) can be held liable for the cost of the software license.

Software such as Microsoft's Systems Management Server and other third-party utilities can help you keep an accurate inventory. These software packages are highly useful, but can also be expesive, difficult to deploy, and can add several minutes to the boot-up time for each workstation while a full inventory of the hard drive is performed. Try to select a piece of software that will work in the background, rather than requiring a time-consuming full scan on each boot.

For small organizations, you can simply perform a periodic manual check, and update your records when you install something. When you install a copy of software, note that in your records, along with the version and which serial number was used. It will be useful not only in the event of a software audit but also for troubleshooting purposes. Periodically reconcile this with your records of how many licenses have been purchased, and make sure everything jives.

It is sometimes difficult to determine the maze of software licensing. Operating systems such as Windows 98 and Windows 95 come in 'OEM' versions which are licensed only for use on the PC with which they were sold. There are no less than ten different variations of Microsoft Office available, based on the licensing conditions and on what software packages are included. Taking some time to educate yourself about what has been purchased and what it does and does not include can save a lot of headaches, hassles, and potential expense later.