What documentation have you created at work?

in Off-Topic
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.
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.
Current Certifications:
* B.S. in Business Management
* Sec+ 2008
* MCSA
Currently Studying for:
* 70-293 Maintaining a Server 2003 Network
Future Plans:
* 70-294 Planning a Server 2003 AD
* 70-297 Designing a Server 2003 AD
* 70-647 Server 2008
* 70-649 MCSE to MCITP:EA
* B.S. in Business Management
* Sec+ 2008
* MCSA
Currently Studying for:
* 70-293 Maintaining a Server 2003 Network
Future Plans:
* 70-294 Planning a Server 2003 AD
* 70-297 Designing a Server 2003 AD
* 70-647 Server 2008
* 70-649 MCSE to MCITP:EA
Comments
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.
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.
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.
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.
CCNA Security | GSEC |GCFW | GCIH | GCIA
[email protected]
http://twitter.com/paul_bosworth
Blog: http://www.infosiege.net/
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.
2023 Cert Goals: SC-100, eCPTX
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.
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.
CCIE Progress - Hours reading - 15, hours labbing - 1