15

I come from a Unix background where documenting the configuration of a service (email for example) could be as simple as grabbing a few text configuration files and a paragraph or 2 of explanatory text.

Faced with documenting the configuration of a lot (50+) of Windows boxes I am dismayed to find out how difficult it is to get a view of a service configuration. I am building these machines from scratch so I am faced with the need to keep the configuration consistent across all machines. I will image all servers where practical using Ghost or similar but the actual configuration of services like AD or Exchange is such a manual point & click process that it could be easy to end up with inconsistencies.

How do people suggest I go about creating build documentation that will ensure consistency? and secondly how do you document the configuration without resorting to loads of screenshots etc? I am actually considering using Camtasia to grab a video of the configuration process which seems ridiculous.

Thanks for your help!

edit: Some of the answers below have been very helpful and I think will get me some way to where I would like to be. In particular, the use of answer files for scriptable installs will help to create consistent installations and some of the WMI tools will be very useful for documentation (LANsweeper, SYDisproject etc.)

What I really really want is to have a tool that could spit out all of the configuration into a human readable/editable format and also suck it all back in again. Unix has basically always done this with self-documenting config files so it is a great disappointment not to have the same facility in a supposedly modern OS!

John
  • 161
  • 1
  • 1
  • 6

5 Answers5

7

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).

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • That looks very helpful, thanks Evan - the automated install option could definitely help with ensuring consistency of install, I will investigate that. I will indeed use a vendor tool to create images and the hardware is identical so no difficulty there. – John Jul 22 '09 at 12:28
  • What would be ideal is a way to automatically create the installation answer file from a running machine - is this possible? Man, I don't know how you guys put up with this stuff at all ;-) – John Jul 22 '09 at 12:33
  • 1
    @John: It's not really all that bad. Once you get the hang of using command-line registry manipulation and some of the various specialty command-line tools (dnscmd.exe from the support tools, netsh.exe, etc) you can really do a *LOT* from the command-line (and, thus, from scripts) to get repeatable configurations. I started my life with "real" software in the Unix world (Xenix-- ick) and I've grown to be fine w/ the Windows way of doing things. The registry just feels like an /etc directory to me. Microsoft has gotten a *LOT* better about command-line admin the last few yeras, too. – Evan Anderson Jul 22 '09 at 15:45
  • It occurs to me that windows provides reasonable interfaces to document a running configuration and can spit out some bits of the config (like the GPO example someone mentioned) but there is no way to combine these i.e. I want the machine to spit out all of its config in a human readable/editable form that would allow me to simply transfer it to another machine with a few changes. Unix has done this forever, it's amazing that you can't do the same in Windows. Thanks for your help, at least I can get some of the way to what I want anyway! – John Jul 22 '09 at 17:38
5

One other option for "live" systems is SYDI (http://sydiproject.com/)

From the project website: "At the most basic level SYDI consists of a collection of scripts which collects information from your servers and networks, then writes the data to a report.

Documenting a network can seem like a huge project, SYDI helps you get started. Instead of manually collecting information like ip addresses, os version, hardware configuration the scripts collects this automatically it can write directly to Word (or XML)."

Marcos
  • 71
  • 1
2

We have some software that can document IIS, Windows Servers, SQL Instances, Exchange.

There is a FREE version that may cover some of your requirements.

http://centrel-solutions.com/xiaconfiguration

Thanks,

Dave

2

A lot of Windows config is actually stored in a sane and logical manner and in sane and logical places. If you're coming at it with your Unix hat firmly on, you're probably trying to take a Unix-like approach to gathering this information, which will very quickly lead you into a mess.

To take Group Policies as an example: in order to document GPO configuration you can just use the gpmc to (1) generate human-readable config documents, and (2) generate machine-usable exports of your current GPO config. These are just a matter of a few simple mouse-clicks and you'll have everything in a nice package.

For server setup you can use WMI scripts to dump out any amount of information imaginable in the precise format you want, without having to go near either AD, the filesystem or the registry. You can even use free tools like LANSweeper (http://www.lansweeper.com/) to automate the process and make the end result available on a web page for everyone to see.

Another point to be aware of, which was touched on above but bears repeating, is that in an AD environment servers do not exist in isolation from each other. Configuring AD, Exchange and GPOs is a one-time-only job. You don't need to configure GPOs separately on each Domain Controller, for example.

Maximus Minimus
  • 8,937
  • 1
  • 22
  • 36
  • There are a lot of hoops to jump through to achieve the simplest things it seems. My setup is unusual in that I have multiple similar, separate AD domains that are completely independent but need to share very similar configurations for ease of administration, hence the desire for easily documented, repeatable configurations. It seems to be easy to create a configuration document using WMI once you have a running server but not so easy to just spit out all the config in such a way that it can be quickly edited and read into another server (i.e. the way Unix has handled this stuff forever). – John Jul 22 '09 at 17:32
1

I recently started playing with Spiceworks, and I've got to admit, I suspect it works by the FM principle.

As long as your machines are domain-authenticated, it will take care of everything. At the very least, use it to create documentation in a form that you're more familiar with.

Matt Simmons
  • 20,218
  • 10
  • 67
  • 114
  • Thanks for the suggestion Matt, it looks like this would be a useful tool for creating and maintaining inventories of running networks. However, it doesn't seem to have the ability to for example, give me the full configuration of an exchange server in such a way that it could be quickly rebuilt. I must say I am amazed that this seems so difficult to do. As I mentioned, in the Unix world, a few text configuration files and you're off and running. Worried about consistency? Just diff the 2 configs! Easy. – John Jul 22 '09 at 11:49
  • @John: The configuration for Exchange, for example, is stored in Active Directory and not "on" the Exchange Server computer. When you need to "rebuild" a machine the configuration is already there in AD. Exporting and "diffing" the configuration for server-specific settings for Exchange wouldn't be too difficult. A lot of Windows admins don't look "under the hood" and realize that most of the configuration of their server computers is just a bunch of key-value pairs in either the filesystem, the registry, or the Active Directory. – Evan Anderson Jul 22 '09 at 11:56
  • Thanks Evan, it's certainly a lot more complex than pulling a config file and running a diff if the configuration can be split across the filesystem, the registry and AD. How does one go about consolidating this mess of information in a coherent and useful way? – John Jul 22 '09 at 12:03