Posey's Tips & Tricks
Network Documentation -- What's Really Important?
I recently wrote a series of articles explaining how to use tools such as Microsoft Visio, Excel, and Windows PowerShell to produce network documentation. While those techniques absolutely have their place, it's also important to consider the role that network documentation plays. In other words, why create network documentation in the first place and what role should it serve?
The answer to this question is going to vary widely from one organization to the next. However, I wanted to take the opportunity to talk about how I use network documentation in my own environment and what that documentation looks like.
Over the past couple of months, I have been working through a massive hardware refresh in which I replaced nearly all of my network hardware. While I made an effort to try to maintain my network's basic structure and architecture, the scope of my project made certain architectural changes and configuration changes unavoidable. This meant that I also had to heavily revise my network documentation.
Over the years, I have seen my share of network documentation, and they tend to vary widely. Some network documentation is extremely verbose, with written records of every seemingly insignificant detail. Conversely, I have also seen documentation that consisted solely of a couple of hand drawn diagrams. So which is the best approach? It's whatever is going to best meet your organization's requirements.
To put it another way, you shouldn't create network documentation just for the sake of being able to say that you have documented your network. The documentation should serve a purpose. I recommend starting out by asking yourself what you hope to achieve by documenting your network. The answer to that question will guide you in the types of details that you will want to include in your network documentation.
In my case, I wanted my network documentation to serve as a collection of the essential details that I would need in order to fix any sort of major problem that might occur on my network.
Although there are a number of PCs on my network, none of those PCs contain data. Therefore, my PC related documentation is extremely light on the details. For each of my PCs, I have documented the basic hardware components (CPU, memory, etc.), though this information is primarily just for insurance purposes. I have also documented serial numbers where appropriate just in case I ever have to file a warranty claim, and the Windows 11 product keys that are assigned to each machine.
The documentation pertaining to my network servers and my storage appliances is more detailed. After all, if something were to happen to a PC on my network there wouldn't be much effort or specialized knowledge required in order to replace it. None of my PCs contain data, meaning that replacing a failed PC with a new PC would involve little more than just installing Windows and a few applications.
Much like my PCs, I have documented the make, model, serial number and warranty information for each component in my network rack. I have also documented the license keys used by each component. However, the documentation does not end there.
My documentation also lists the network configuration for each of my servers and storage appliances. Each server contains six NICs, with four being actively used. My documentation lists the static IP address assigned to each of the four ports along with what each port connects to (standard network traffic, management traffic, backbone, storage link, etc.).
There is one more essential item contained within my documentation contains, and this is something that I'm sure many of you will take issue with. Even so, there is a method to the madness. That essential item is the administrative credentials associated with each piece of hardware. I have included both the manufacturer's default credentials and the credentials that I have assigned.
I will be the first to admit that long standing IT best practices state that you should never, ever write down a password. Even so, I think that it's probably safe in this situation. I work out of my home, and nobody is ever in my office except for me.
This brings up another important point. My network documentation is printed and I laminated it as a way of protecting the paper against accidental destruction. The reason why I printed my documentation is simple. As mentioned earlier, my main goal was to create documentation that would allow me to fix any sort of major problem that might occur on my network. As such, it didn't make sense to save the documentation in a digital format (though I do have a digital copy stored on a flash drive that I keep in a vault). If my network were to suffer a major failure, it's unlikely that I would be able to retrieve the network documentation from a network drive. Having a printed copy of the documentation just seemed like the most prudent option.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.