Documentation...?

[Koldov]

One (of the many) things I know I am pretty bad at, is documentation...

 

I've got loads of Word documents and Excel spreadsheets detailing various parts of the network or services we use, but I know that it would be pretty tough (actually impossible) for someone else to come in and have a clue about where a specific piece of information is!

 

Unfortunately I think I'm going to have to start from the ground up and have no idea where to start or what to document (or actually how to pull it all together in the first place)...

 

Also, what is the best format to have all this in, how to secure it and how much detail do I need to include?

 

Does it need to go into things like what GPOs are configured and why, or should it just state the Admin password to the server is X and the new IT person should be able to work it all out from there (extrapolate this for all other variables too numerous to list)...

 

I know this is a pretty open question and everyone is going to have their own ideas, but I need to start somewhere.

[LukeRowberry]

We use onenote but there are much better systems out there. I tend to document everything including 'little tweaks' and half finished projects. It's everything I would want if I went somewhere new and needed to hit the ground running on day 1.

[korifugi]

I have a onenote for most of my MECM/SCCM stuff - to track image version changelogs, task sequence contents & config, processes and process flowcharts. An excel document for my asset list, and a shed load of other docs for providers, how to's and general setups.

[TechMonkey]

Yeah, OneNote here too, with links to files in our IT Admin area.

[hallb15]

Think about what you would want if you were starting at a new place. In an ideal world you'd document EVERYTHING but there will always be some forgotten systems that have worked autonomously for so long you don't remember them.

You should include as much relevant info as possible, but it doesn't need to be an idiots guide. For example I wouldn't list the contents of every GPO but give enough info to show which server to look for them on.

 

Below is the contents page of my school IT documentation - I'm sure it's by no means an exhaustive list but hopefully it will give you a starting point. This was designed to give a third-party support company enough info to cover in my absence.

Looking at it now, I can see parts that need updating - I think we're all a little bit guilty of that.

 

Table of Contents

Contents 2

ICT Summary 3

School Map, identifying locations of I.T. infrastructure and Servers. 4

Main Building 4

Annex 6

Network infrastructure, with diagram, IP addressing, reservations 7

IP Addressing 8

Reservations 8

Hardware information and warranties. 10

Servers 10

Desktops 11

Server roles. 12

User accounts, Groups. 12

Staff list 13

Contacts for support and 3rd party. 14

School improvement plan – I.T., I.T. development 15

Asset list or access to the asset management. 16

Remote access, VPN. 16

Anti-Virus, Malware protection. 16

Licensing 16

Backup regime. 17

Websites 18

Daily Routine 21

[Jamman960]

Currently using OneNote for most things along with Snipeit for asset management but I'm thinking about going towards a full on service desk to organise projects, change requests, configuration items, purchase orders, contracts etc to create a fuller picture

[Mako]

The goal is to make it so that an IT person of relevant experience can quickly pick it up. An admin password written down would naturally help, but if they need to spend hours figuring out which server does what, or where the physical network connections go, then the documentation is inadequate.

 

Format is subjective. Some people like SharePoint sites, OneNote has already been mentioned. There's nothing fundamentally wrong with Word documents and spreadsheets as long as it's clear as to what document gives what information. If you are using an on-premises solution (i.e locally stored word docs) then these should be available as a hard copy and updated accordingly. Documentation is irrelevant if you can't access it in the event of a system failure. The important thing is that the information is there.

 

I would aim to have, at least:

 

Network topology diagram

Physical map of the site (where are the cabs? etc)

Details of anything acting as a server - Phys or VM? / Make / Model / Warranty / Network config / OS info / NETBIOS and/or hostname / Roles & Features / VLAN(s) / What ports (and/or WIFI) is it connected to / Backup configs

Details of Switches - The config of the switch itself and where backup configs are located / Port configs (any access policies, tagged/untagged VLANs etc) / Any uplinks or trunk ports etc

AD overview - A quick guide to the hierarchy of your AD structure for logical deductions of where things are

GPOs - GPO names and their associated settings

Backup plan and schedule - Details of backup infrastructure / what backs up to where / any schedules / on-site/off-site?

Software details - What software is used on site, associated licenses, and whether there are any:

Service accounts - List of accounts (AD or otherwise) used, and their associated usernames and passwords. This may or may not include any admin passwords because you might have them written separately in your:

Disaster recovery - This is a whole subset of documentation but is absolutely vital.

 

All of these things should have associated changelogs so anyone picking up your documentation can see the route it went through to reach its current state. A random example might be:

 

You leave the position. The incoming IT person finds an ethernet cable connected from Switch A to Switch B, but it looks out of place and hastily done. Why is it here, what does it do? If the switch documentation says that the Big Red Cable was plugged in on 30/11/21 as a stop-gap measure to resolve a fibre failure, at least they know why it's there and could possibly plan to fix it and integrate it appropriately.

 

Now that sounds like a lot and I know you're not sure where to start, so pick one of the above and work from there. I would prioritise disaster recovery if you don't have that documentation in place, and then topology, followed by server details and switch details. That's just my opinion, though.

 

As Ron Swanson famously said - don't half-ass two things. Whole-ass one thing. Pick one thing and document it through then move on. You may find there's overlaps and you can use information from one thing in another.

[jthompson]

Using an externally hosted DokuWiki site here. Not reliant on having any domain systems working and works just as well on mobile. You might find that if you're starting [almost] from scratch, a wiki tool may lend itself to well to leaving yourself markers for fleshing things out in future.

 

I refer to our documentation every day, as it includes lots of code snippets, command examples and workflows. It's one of my always tabs. I think a wiki site lends itself well to that sort of stuff as it'll be conducive to speedier navigation than just about anything else, without the risk of any accidental edits.

[psydii]

We have a Business Continuity and Disaster Recovery plan document. It is a spreadsheet.

 

Overview (including brief notes on backup/recovery)-> Contacts ->Key systems and where they reside->Server details -> Network Switch Details ->Lights out management-> Firewalls and ACLS->VLANS and DHCP Scopes->Static IPs-> More detailed services page -> Service recovery plans (bare-metal vs limited scope), and pointers on how to prioritise.

 

Each section links out to relevant more detailed documents stored in a folder (a folder that if looked at directly would overwhelm an outsourced emergency admin)

 

Process documents (how to set up a Team, how to add a printer, how to rename a phone, how to recall an email, how to do a compliance search, how to meet and great support requests etc etc) are all in a single folder, and I'd expect a new hire/competent emergency admin to find them via the BC/DR plan and then skim read them so they have some idea of how things get done, and can find them when asked specific questions. @hallb15's one-stop document is sounds better approach for documenting processes, procedures and 'local knowledge' as it has a table of contents!

 

 

The plan and the documents are all stored in an online folder, with a copy held on the server that sites outside the on prem VM infrastructure. The Business manager has a copy of the BC/DR plan linked in their personal folder.

[mdrabble]

I'm currently using SharePoint with the Wiki plugin - only IT Support have access and require MFA as it contains password etc.

[Aprice]

I'm now using Netbox for infrastructure documentation, with some documents in Sharepoint.

 

My previous method was excel spreadsheets and supporting word docs to provide some guidance as to how things are setup. However I still get phone calls months after I left, as nobody reads the documentation:mad: