Commenting on the tooling.
We've tried online wiki's but found a number of limitations, which may be personal taste, but include document structure and most critically having to be connected to the documentation server.
Being connected is a serious problem if you are either offline or onsite (obviously you can mitigate the onsite with a secured SSL connection et. al.)
Our current documentation process is:
- static html generator
- markdown syntax
- distributed versioning system
We have a 'formal' layout for the documentation and that provides the structure for the menus (and the associated CSS for visual styling etc.)
Static HTML Generator
We use an in house static html generator based on cubictemp and a number of other tools: pygments, docutils.
The generated pages are (not?)obviously ugly looking, as most of us/our sysadmins/programmers know what is aesthetically beautiful but have a total lack of coordination into building such.
But it affords/let's us include configuration files, sample scripts, pdf, etc, without having to worry about html formatting screwing it up or worrying about where to find it on the 'server' for downloading.
If it's not HTML, just drop it in the folder and add a url link to it.
HTML provides 'potential' structure for layout, and also critically provides 'linking' between knowledge/content items (as well as base structure mechanisms, such as being able to create menus, table's of content etc.) With HTML, each user can now run a small web server on their machine whether lighttpd or something small or just go full blown with Apache or IIS.
All our machines have the grunt for basic html serving, and works well enough for us.
MARKDOWN syntax.
We use a bastardised version of MARKDOWN, Textish and or reStructuredTEXT to let our 'creative' juices write documentation without having to worry about HTML.
It also means everyone get's to use their favourite editor (I use Scintilla on Windows and *Nix) while the others here use vi/vim.
Distributed Versioning System.
We use Git to 'distribute' the documentation between users. Oh, and we use it's versioning capacity too.
The key advantage for us is that we can all work on updating the documentation without having to be connected to the server, and without having to publish 'completed' works. We can all work on the same parts of the documentation, or different parts, or just consume the information.
Personally, I hate being tied to a server to update blogs let alone wiki's. Git works well for us.
Commenting on the Workflow
Wiki's seem to be the "fashion" for knowledge dissemination / codification, but as commented elsewhere all processes become difficult to sustain, and finding the mix of tools that best supports your teams needs and is sustainable will take time.
The better solutions just end up being discovered and not mandated.
Best Answer
It depends on the size of the network, number of users, number of nodes (computers, servers, printers, etc.) and the size of your IT staff, among other things.
It also depends on your goal. Are you documenting the network for training and maintenance purposes, insurance/loss prevention, etc?
Personally, I document my networks in such a way that I know I can derive any missing information based on what is documented. From a practical stance, there is a point of diminishing returns when your documentation gets too granular.
A good rule of thumb I use is that there should be documentation in a known location that is thorough enough that if I get hit by a bus tonight, another administrator can keep the core network running while he/she fills in the missing pieces over the next few days/weeks.
Here is an overview of what I think is most important about one of my networks. For the record this is a Windows-only shop with about 100 users and 5 offices.
If there was anything strange about a setup or workflow that would not be immediately obvious to a new administrator, I would write a short "brief" about it as well.