What do i use to hold the server documentation

document-managementdocumentationwindows-server-2008

I had to document the servers i use and i don't know what to use to hold the data. Could you sugest the best way to keep the server documentation? Do i create a data base that holds the harware and software documentation, or do i use wiki pages or SVN? Or if ther is a tool that holds the documentation could you please provide the link.

Best Answer

I personally use a little program called The Guide, which I find a lot faster than using a wiki (which I also use). You can even embed Excel files right into the pages, as well as many other file types.

There is a portable version, so you can take it everywhere you go on a USB flash drive. I just wish there was a Linux client which could read the same files.

A wiki or Google Docs is better for collaboration though.

The Guide

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.

Windows – How to document windows server configurations

You say you're building the sytems from scratch, so it sounds like you're more interested in the automated setup than you are grabbing configuration from a "live" system.

The installation of every version of Windows since Windows 2000 has been fairly straightforward to automate via "answer files".

The installation of Active Directory (dcpromo.exe) can be performed from an answer file.

Objects can be imported into Active Directory from CSV/LDIF files, or added programmatically via script. If you're creating a single domain those objects will only need to be imported once and CSV/LDIF import will probably be fine. If you're creating multiple domains or multiple forests then you'll probably be best served by writing a script (since distinguished names of objects will be different on a domain-for-domain, forest-for-forest basis).

The installation of every version of Exchange since Exchange 2000 can be automated with an answer file.

In an Active Directory environment a lot of configuration consistency can be had by using Group Policy to enforce settings on computers. I shoot for a goal of having all non-stock configuration settings re: the OS set by group policy such that when I deploy a new server I'm not hand-ticking configuration items (allowing 'Remote Desktop', running 'Add/Remove Windows Components' / SYSOCMGR to change the loaded Windows components, applying local filesystem and registry permissions, etc).

Beyond the initial installation of the products, knowledge about where each product stores its configuration will take you a long way toward consistency. Scripting to manipulate the filesystem and registry isn't a whole lot different on Windows than manipulating configuration files on a *nix machine. Where registry manipulation isn't appropriate there are typically command-line utilities to perform most other configuration tasks (netsh, the "net" command, resource kit tools, etc). I'd be fairly certain that most configuration tasks you're going to run up against have already been automated and made scriptable by somebody if you look hard enough.

re: disk imaging - If you have identical hardware you can get away with disk imaging after using the SYSPREP tool to reset the computer's security ID (SID) and prepare it for imaging. If you hardware isn't consistent, though, I'd recommend against disk imaging. Your server vendor, assuming it's a name brand, should have a "story" for automated OS deployment that includes provisioning the drivers for the hardware (OpenManage Server Assistant, SmartStart, etc).