I began writing about why a configuration or settings document is important for network troubleshooting. In this article, I’d like to try share a basic layout I use. As I’m working with my Seattle IT Consulting clients, I am teaching them how to build this type of documentation. This is just meant to be a base to get you started. You’ll want to expand on this when you apply this to your own situation.
In describing any system there are
- Hardware components,
- Software components
- Unique Settings for each hardware and software component
Get all three right and you can troubleshoot, repair and even replace any system. Get it wrong and as your team of experts grows, they begin “Stepping” on each others change. Technician 1 makes a change to fix a problem. This change crops up later because it causes a new problem. Technician 2, unaware of the change that technician 1 made, fixes the new problem by changing the system back to the way it was. Now the new problem is fixed, but strangely the old problem crops up again. Without understanding these configuration changes, technician 3, 4 and 5 start making more and more changes until everyone is confused. Every engineering team I’ve ever read about over the last 100 years has run into this same problem. The way the problem is fixed is with centralized change control documents or Settings documents. Without the settings, fixing the problem is a series of educated guesses.
Let’s start thinking about a network. Every system and object on a network must have some settings that are unique, so that it can be found. A MAC address, Active Directory object and IP address all are ways of uniquely identifying an object on a network.
Section 1 of your document starts here. In this first section each component (hardware or software) needs to be described (Name, location, role etc.). Then describe the settings that are association with that object.
Remember: Each object has a set of expected settings When building a system in a standard way, the setting should be the same on each system, with the exception of the custom settings.
Section 2 In this section describe the setting and the purpose of object. Include the input and output and how the settings affect the output. Settings documents will be used by troubleshooters for comparison to identify what has changed on the network. The mistakes many technicians make when describing settings, is assuming the reader understands the standards and does things the same way they do. Often forgetting to define the standard settings on the network. There is no problem tying these documents together with other documents. I’ll often connect my topology documents with my custom setting by referencing the information for the specific device in the topology document (see topology document for the device)
Section 3 I will used this section for the raw information that describes the setting in detail.
- Settings: <Object Name>
- Object Type: <Virtual/Logical>
- Object Role: <Object Role>
- Object Description: <define purpose and reason for the object>
- Standard Settings: <describe standard setting for the Object type across the network>
- Unique/customer settings: <Describe the unique settings of the <Object Name> >
(Note: These include naming conventions, security settings, etc.)
When troubleshooting, the technician may be seeing the object for the first time. Without having memorized the settings in the past, the technician can review the custom setting and know if something has changed. By reviewing the settings document, the technician knows what the system looked like when everything was working. This expedites the troubleshooting process.
I’m sure as you are reading my documentation; you’ll be able to see mistakes in the way I’ve presented it. The purpose of this document is a starting point. Take this document and change it to support your environment. If you have a cool update let me know. Check out this site for layouts you can copy to document your own network. If you need someone to create a knowledge base for you check out, www.irrevo.com. I am creating a list of document descriptions you’ll need to document your systems including, How to…, Settings, Topology and other documents you’ll want for your network.