What documentation have you created at work?

SrSysAdmin

The company I work for now has little to no documentation whatsoever. I'm creating the documentation whenever I have time but I'm not sure what all documentation I should be creating (I know a lot of what I should document, but I'm really just looking for new things to document in an effort to be thorough).

So with that said...what sort of documentation have you created at your job or do you find useful that I might not have created yet? I want every part of my job documented so any and all ideas are welcome.


Thanks guys.

vCole

• Network: Servers, Ports, Switches, etc
• Licensing
• Machines with service tags/serial #/software installed/OS/hardware/etc
• Procedures (things you do repetitively)
• Things you've only done once!

mikedisd2

How-to procedures for all tasks that you perform:

Creating a new user account and mailbox and anything involving other apps;
Removal/disable plan for exiting employee accounts;
Requirements for SOE builds;
Daily backup checks;
A/V equipment setup, etc. Note your daily/weekly jobs and document them for anyone else who may do your job when you leave.

Other things I've covered:
Any app you install ought to have a build sheet (invaluable for debugging)
All group policies
Establishing a standard for PC/server hardware builds
Any special builds (the MD's laptop that has all those extra toys that makes his OS crash)
Network/system diagram (very handy to have for troubleshooting, needs to be updated constantly)
Office floor plan covering network port numbers.
All user asset allocation (sucks to do though)

I'm currently trying to configure/upgrade IBM Systems Director and I'm very greatful that the existing install has been fully documented. I know what service accounts to use, what database server is being employed, etc.

rwmidl

Emergency power down/power up procedures and what gets powered up/down. Besides being published on our internal site I have a hard copy printed and in a folder labeled "power up procedure" pinned outside my cube (I sit next to the server racks). That way if something happened and and of the sys admins aren't available anyone would know the correct order of powering up.

I also put numbers on all the servers and related those numbers in the procedure so people will know what number corresponds to which server.

tbgree00

I do the licensing audit document every quarter and created the disaster recovery plan from scratch. I've also created upgrade instructions for vSphere 4.0 and 4.1.

I plan on creating a detailed report on dealing with vendors and what I buy routinely, ordering security devices, doing access audits, and basic procedures not otherwise covered in our ticketing system.

Paul Boz

Are you talking about from a policy/procedural basis or a network documentation basis?

I think all of them are important. Policies and procedures are critical for defining acceptable behavior for IT resources. I’d draft stuff like acceptable use policies, PW policies, screen lockout policies, clean desk policy, etc. Procedures are also very important and should supplement the business continuity and disaster recovery plans. These documents should reference your internal procedural documents in the event of a disaster. Being able to say “if a hurricane wipes out our business this is specifically what we have to do to get back up and running “ is critical. I would also make sure a change management policy and supporting system is in place for any “serious” adds, moves, and changes. This should include changes to the firewall(s), infrastructure, servers (upgrades, new software, etc) and anything deemed business critical.

As far as network documentation goes, try to keep several updated topology diagrams. One should be a physical depiction of how systems are inter-connected. Another should be logical, and you should also develop a VLAN topology as well. Beyond diagrams I would create an asset spreadsheet or buy a solution if you need to. Poor and out-dated network documentation is the #1 reason why my audits have taken forever in the past.

chrisone

Like Paul Boz stated, the documentation you create will depend on your job function. Being a network guy you will obviously create network diagrams and network documents for the network, same with the servers guys and thier specific job roles. Just stick to creating documentation for your department/job role. You might be trying to be nice and help out another department but 1. You are treding on someone else's territory and you might upset someone. 2. Your efforts might goto waste and management might frown on it because your not doing your job and doing someone else's job, in other words, not focusing on what your being paid to do.

Tips for coming up with documentation. 1. Just think when you first started out with the company what you wished had documentation written up for. Then create a document about it if there isn't anything. 2. Create a document for something that another tech or techs keep bugging you about. That way when they come you can always say, in a nice way, "Did you review the documentation?" hahaha i used to love that one back in the day when i was a system support guy. It will give you more time to study/research, surf the net, whatever, instead of always re-teaching tasks to peers.

willhi1979

We have a knowledge base that can be accessed to search articles for known issues. We also have a few Sharepoints. You could set up something simple like a Sharepoint or mapped drive on a server with the documentation to make it accessible to everyone who needed it.

DevilWAH

My biggest tip is think who is going to use the documentation before you write/create it.

For example if you know the people who will read it are 3rd level network engineers, then you can wire a general over view of the set up, with lists of the specific facts they need to know. I don't want to read a detailed step by step instruction on how to set up trunk ports of instance, a simple "configure a trunk with native vlan X and and block all vlans apart from those listed below.

Switch A - Switch B - vlan 50,78,65
Switch A - Switch C Vlan 50, 78, 45
.
.
.
"

On the other hand if its instructions for entry level help desk staff you may well want step by step instructions.

Getting this right will be the difference between people reading your documentation or ignoring it. It's got to be helpful and contain everything they need to know, while not being so long and boring that no one can find the part they need or even bring them selves to read it.

My personal advice is to design it in a drill down fashion. My documentation starts with a single page of a spread sheet, this lists all the network devices grouped by the physical lay out, with there management ip's, model numbers and serial numbers. Clicking on the group header with give you a digram of that section of the network, click the switch will show you the current config it is running. other tabs and links will take documentation to configure the different areas, Vans, eigrp, managment, 802.1x, etc.

so from one overview you can drill down as far as your expertise needs. do you just need to grab the config to past to a replacement switch, or do you need the step by step instructions to go with it?

Remember no matter how good your documentation is, if it takes ages for people to find what they need then they wont use it.

stuh84

I've done some on an IPv6 overview for the techy (but scared of anything not v4) people.

Also, I'm in the middle of documenting our SSL infrastructure for my department (and in the process doing sort of an intro to encryption, authentication, public/private key exchanges etc), as at the moment I'm the only one in my department who understands it so need to pass that on to everyone else.

A lot of what we do though tend to has a lot of documentation already, it just means amending/stealing the best bits for most of it.