Admin Documentation

[gpjt]

Do you maintain any online or written administrative documentation (e.g., a handbook or knowledge base) that includes links and details about all the connected services and websites used to manage your IT environment?

If so, I’d be interested to know how it’s structured and where it’s stored (web based/printed etc)

 

 

[3s-gtech]

I have a folder on our (on-site) file shares. It's the rundown of everything from static IPs, our main audit, and written guides to our individual setup and services. All Word docs and Excel spreadsheets. Tried to keep it as simple, non-technical and accessible as possible. It's not accessible to anyone other than IT though. If something happens to me, it's there.

 

There are still things that annoy me that I haven't documented though, because I use it constantly and expect everything there!

[pete]

We use a wiki (Dokuwiki - picked 'cos it's decent and very portable for least faffing in a DR situation - other wikis are available).

 

It's (mostly) structured as:

 

Broad trust-wide info (software, procedures, how to do stuff with specific hardware models etc).  Things like "here's a good basic config for switch model X" or "here's how MIS exchanges syncs to M365 using Salamander" or "audit policies for DCs should be set as follows".  Here's how you integrate Cloudflare + Let's Encrypt for cert renewal.  How to do things with/use the tech.

 

Device/Site/School-specific info.  How things are configured for specific schools/devices/services.  How Salamander is configured for School X.  Config backups for switch Y.  What service Z provides and depends upon at School X.

 

Our IT-facing documentation assumes a competent IT person is reading it.  They may be unfamiliar with the school, but they should know what they're doing.

[jthompson]

DokuWiki here also. Externally hosted so that it's available in case of catastrophe, and we also maintain separate backups of it also. Since DokuWiki stores pages in human-readable text files and not in a db, you can still read your documentation by opening site backups directly.

 

The markup syntax is simple but very powerful (tables and syntax-highlighted code block being good examples of that) and has some good plugins available (e.g. mermaid for diagramming).

 

Much prefer a wiki over a collection of Google/Word Docs for this sort of thing: faster to browse and linking and organising of pages becomes trivial.

 

[Synkrox]

PerfectWiki here.

Links with teams - we have 2 Wikis - One for everyone with staff guides and policies (not just IT) and one for the Ops teams, with guides for our reference and more techy stuff. Finance / Data manager etc all use it too.

The AI agent is actually really good for answering staff questions directly from our policies and guides.

[altecsole]

OneNote for draft and then dedicated SharePoint site for final documentation - mostly SharePoint pages, as easy to view on a mobile device. We also use the Document library on the site, along with a Microsoft Planner. 

[psydii]

Business Continuity / Disaster Recovery Plan has an overview of all systems and services, ips, support and owner info. This document includes charts of business processes and how data flows.

 

There are two "how things are done here" documents that are intended for new IT Service team members (or to be read by external emergency cover in the event something bad happens and we loose service and the IT team at the same time). SBM and HT PA know that nobody should touch anything without reading those first.

 

Each major service / system / process has commissioning note in a shared folder and a "Configuration Item" in our CMDB, all changes are logged through tickets against those CI's More complex changes are documented in a shared folder with the service name, CI# and ticket #. Might be a word doc, might be a pdf, might be a spreadsheet.

 

For a lot of stuff though, the configuration is the documentation. The "house style" is described in the "how things are done here" documents, and then you look at the live config to get an understanding of how a specific thing is set up.  We have backups of all the GPOs, AD Objects, Deployments etc which can be referenced/used in the event we need to rebuild from scratch without reference to the existing management plane. Where ever a system allows for configuration backups to be easily taken, we take those before making a change.

 

IT processes are documented in Standard Operating Procedures folder. (onboarding, offboarding, asset life-cyle, managing change request, escalations process, troubleshooting notes, maintenance schedules etc)

 

Every year I spend a few days improving it, pruning obsolete info, adding new info that didn't get documented properly in the rush to get it done "now!", improving that I can.

 

[gpjt]

Many thanks all! 

 

Lots to digest and lots to think about in terms of where to start with it all...we obviously have a lot of the core information and processes documented, but needs bringing all together in an easy to read format.