Some things in life just aren’t possible: you can’t make it so the prequels never happened, you can’t take back that time you missed out on kissing Wendy Peffercorn. And you definitely can’t keep everything straight on your network without extensive and up-to-date documentation.

Good documentation helps by:

  • Letting you offload work to someone else without having to spend a day “getting them up to speed”.
  • Giving you a solid base for troubleshooting issues more quickly.
  • Providing hard data about the current lifecycle stage of equipment.

To combat the mass amount of information you need to have on hand, you need documentation of the equipment in your network, how it’s configured and what it’s being used for.

A good starting point is to think of what you’d need for disaster recovery: if the building burned down tomorrow, what would you need to rebuild?

Tools for Sysadmin Documentation

What happens to your meticulously kept networking information on Google Drive when your ISP cuts out?

What you want is a system that’s:

  • Local
  • Searchable
  • Accessible from any device

Note Taking Apps


  • Polished Interfaces
  • Native Apps on every client


  • Probably not accessible from that one workstation in the back office that always loses connectivity.

Examples: OneNote, Evernote

Wiki Systems


  • Can easily import/export data
  • Can be updated by almost anyone in the organization.


  • Can be updated by almost anyone in the organization.

Examples: ScrewTurn Wiki, Confluence, Dokuwiki

A Folder of Plain Text Files


  • No incompatabilities
  • Can be grep’d / find’d


  • Can be difficult to integrate pictures and diagrams
  • Lacking in visual fidelity

Examples: ASCII

What to document

It’s generally best to work “outside in” – consider some common troubleshooting tasks and think about what information you’d need for each scenario. Write as if you were explaining to someone competent but new: what they would need to know to get up to speed with a system?

Your job isn’t to document the network exhaustively, but to keep enough information on hand that you can effectively work through issues and do your work.

To help you get started, we’ve created a Google Sheet which you can copy here – which is preset with the fields listed below to help you get started.

Network Checklist:

  • IP Address Setup
    – DHCP Range
    – Reserved address of Servers, Routers, Switches, Printers, etc.
  • External Providers
    – DNS
    – Internet
    – Telephony
  • Cloud Crossover
    – Azure Virtual Networks
    – AWS Virtual Private Cloud
  • Outside Connections
    – Client VPNs
    – Branch networks/VPN

Utilities to assist with Network documentation:
The Dude:

Account Credentials Checklist:

  • Access
  • Type (admin, service)

Server Checklist:

  • Roles
  • Hostname
  • Backup location
  • OS + Version
  • Asset Tag Number
  • Warranty and Support
  • Disk, Ram, Processors
  • Static IP

Utilities to assist with Server documentation

Physical Asset Inventory

In a spreadsheet, list every item, it’s serial number, date of purchase and asset tag number.

It’s not impossible to use something like the serial number of the piece of equipment in question (and many successfully have), it tends to be easier across systems, device families, and users to ask for the asset tag number than a tiny number that may be hard to read or impossible to find on the bottom of a printer.

You should decide on a purchase price – A good starting number is $100 – above which all new IT assets require tags. There are a number of vendors of these that will make custom, very hard to remove stickers with pre-printed numbers and barcodes.

You should also buy yourself a wireless barcode reader w/USB connection to speed up your data input tasks. It will pay for itself in time saved in just a few hours, even better they are all almost all under a $100 dollars so you won’t have to asset tag it.

Business Application Inventory

It’s possible that your office runs entirely on Word Documents, Microsoft Exchange and the thanks of a grateful nation. It’s much more likely, however, that you have a mishmash (technical term) of different applications for the varying specialities within your organization.

For each of these applications you should have ready:

  • Current Version
  • Server Location
  • Backup strategy
  • Internal power user
  • Test credentials
  • What is the “Sanity Check” to see if it’s working
  • Vendor Support Contact information

← Go back to the intro