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.
- Administrator credentials for all servers. Obviously this should be kept secure.
- IP Addresses and NetBIOS names for any node on the network with a static IP address, including servers, workstations, printers, firewalls, routers, switches, etc.
- Basic server hardware information, such as Service tags or equivalent, total disk capacity, total RAM, etc.
- Major roles of each server, such as Domain Controller, File Server, Print Server, Terminal Server, etc.
- Location of backup tapes/drives.
- Information about the account numbers and credentials for services like remote office voice and data providers.
- External DNS for websites and routing.
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.
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).
Best Answer
I assume this is a long term documentation effort, not just trying to capture a snapshot of the current configuration.
The wiki works now and might keep you sane for a while but if your environment changes quickly you will have a serious problem. You will always have to make sure the cron jobs are properly written, run in a timely fashion, get written for new services, are compatible with new versions of software, etc.
Consider using an configuration management tool like Puppet or Cfengine. At least put whatever data you collect under version control (like Mercurial, git, or Subversion).
Your configuration data is coming in from everywhere instead of being centralized. A wiki will always lag the current state of your machines. You need to centralize the configuration data; make it flow from the center out to the edges. But it is true that sometimes you have to go out and capture configuration data. Cfengine can do audits, Puppet might. Look at this Wikipedia article listing other configuration managers.