Planning to setup a new server? Working as a company’s technical support? Maybe you are the neighborhood’s “tech guy”. No matter the situation, technical documentation should always be part of your everyday practice.
Over the years, I have been known to record very detailed information about my home setup. This included drawing pictures of servers, VMs (virtual machines), switches and individual ports, wall outlets, and more. I would also have spreadsheets filled with IP addresses and their corresponding devices.
Conversely, I have been known for not writing down a single piece of information. This makes it very difficult for me to troubleshoot if/when something is not working correctly. Sure, I can blame the fact that I seem to change my home server/network setup way too many times per year, but that is still not a valid excuse to not record the changes.
1. Why Document?
Documenting is one of those things that a lot of us say we want to do, or should do, but never fully implement. I think we are all guilty of this at some point in our careers. The good news is there is always room for improvement and it’s never too late to start documenting.
Most commonly asked question:
Why should I document?
I always confront this with another question:
If the business were to hire a different company for their technical needs, would that company be able to quickly and easily provide the appropriate technical support?
For me, the answer should always be “Absolutely!”.
I can tell you from experience that it is very frustrating trying to provide support for a business after a previous technical support company was not diligent with maintaining an up to date documentation policy.
Within my home area here in Illinois, I know of some technical people who provide technical support for business’ and schools who do not practice documentation. Now these technical people are not just kids off the street who are tech savvy, but also business who have a technical support staff that are contracted by many business’ to provide them with contracted technical support.
This does not settle well for me for a couple of reasons:
- Flat-out unprofessional
- Techs secure their positions or contracts by being the only person that knows the information (in their head)
- When a problem arises (and it will), documentation can assist at fixing the problem quickly
2. What to Document?
To keep this article in-line with the “Server Setup” series and not get into too much detail (detail will come in future articles), here are some of different types of information I like to document for any client:
- Client’s contact information.
- My contact information.
- Previous tech support contact information.
- Client’s ISP (Internet Service Provider) contact information.
- Hardware support (switches, routers, servers, etc…).
- Software support.
The reason I include my contact information is because if I am not in town (or just not available) and the client is in need of support, whoever else they contract to come out should be able to get a hold of me if they have any questions.
If possible, I also like to have previous technician’s or company’s contact information (just in case something pops up from many years ago).
Domain Administrator Credentials
Probably one of the most important pieces of information would be knowledge of the Domain Administrator’s username and password. Location of this information will be discussed in future articles. For now, just take note we need this information documented.
This includes crendentials for things such as:
- Client’s Website
- Other Websites
- Web Filters / Proxy Servers
- Wireless APs
- Wireless SSIDs
- Printers & Other Hardware
- and more (will add to this list as time goes on)
I like to have a spreadsheet that lists all IP addresses (Depending on the company size and subnet configuration).
Since this is a new business we are setting up, we have a clean slate to work with.
If it’s an established business, then I would typically start doing some research to track down what IP address goes to what (especially statically assigned IPs) along with their hostnames.
Don’t forget to document any public facing IP addresses assigned by the client’s ISP.
Microsoft licensing comes to mind right away here. You might also have firewall and/or web filter licensing.
I’m sure there is more examples but as of this writing, that’s all that comes to mind.
Warranty and Service Contracts
Servers, desktops, printers, VOIP, and more could all be potentially covered under some sort of warranty and/or service contract. Gather up all of the warranty and service contract information you can. Make sure to include the end dates of all contracts and warranties.
Anything that is “out of the ordinary” should be documented. Things such as special software configurations, custom hardware installations, registry changes, permissions, and more. Typically, if it’s something that had to be changed because of the specific environment and it’s not a change that can be easily seen via something like Group Policy, go ahead and document it.
Whether it’s a nicely drafted Visio diagram of your network topology or just a hand-drawn diagram, get it on paper and scan it in as a pdf. Depending on your preferred method of documentation, a lot of methods allow you to scan in documents.
A lot of environments are somewhat complicated when you get into the physical connections.
I know I am forgetting some things but I will update this article as time goes on. I am getting older and my memory isn’t as good as it used to be.
3. Where to Document?
Ok, so we determined why and what to document. Now where do we document?
I have used the following in the past:
- Text files
- Word documents
- Password manager
- Web-based wiki (locally installed on my own web server)
For this video series, I have chosen to try the following:
PBWorks is more of a “collaboration” tool, but I want to mainly use it as my own wiki.
PBWorks has a free version that I am going to start with. I can also setup permissions for my clients to be able to log into PBWorks and access all of the documentation related to their business.
PBWorks free account includes:
- Up to 15 users and 5 guests
- Up to 5 workspaces
- 50 MB of storage
- Free email customer support
- No credit card required
There are a couple ways to set this up:
- Create a new account for each client.
- Create one account and setup all clients under this one.
I am leaning towards option number 1. The way I look at it, the documentation belongs to, and should be owned by, the client, regardless if I was the person to write the documentation. If I were to fall off the face of the planet, the client should have the main account credentials for their documentation.
I strongly feel that having the documentation available to the client will set us apart from a lot of the other technical support companies. Not only is it difficult to find people documenting, it’s even harder to find technical companies who have their customer’s documentation available to their customers.
The benefits outweigh the negatives (the only negative I can think of is that it can be time consuming).
Take the extra time to setup your documentation foundation. Little by little, your documentation will grow into a large knowledgbase full of valuable information for not only you, but others after you are gone.
You will not only be providing great customer service by having documentation available to your clients, but you will preceived as being professional and passionate about the services you provide. Take pride and ownership in everything you do and strive to be the best that you can be!
Question for You
Do you have a documentation system in place? If so, care to share your practices and/or thoughts? If not, are you planning on starting?
Photos found on flickrcc.net